I’ve managed (small and large) teams for some well known companies (including a couple of my own companies.) And through this experience, I’ve learned that mixing “Performance and Appraisals” is like mixing “Drinking and Driving.” In layman’s terms, it’s a stupid idea.
Sounds strange? May I suggest the following video from Daniel Pink, which takes a peak into what motivates individuals and what actually leads to poor performance.
I’m sure you’ve heard these stories before and deep down even agree with it. Yet, everyday we go out of our way to measure the performance of individuals and teams in our organization to decide their salary appraisal at the end of the year.
I’ve yet to meet a single individual how understands how to effectively measure performance. For a creative, problem solving field like software product development, how do you even measure such a thing? Remember output (code, features, bugs, products, etc.) is a lame measure of performance. Outcome and Impact is what matters. But that is hard to measure, so we simply measure what we can, output. And in most cases, output that someone else decided on your behalf.
Unfortunately this a very broadly used management philosophy that kills employee’s motivation everyday. To make matters worse, the employee feedback process is also tightly coupled with the appraisal process.
Why just drink and drive, let’s drink, smoke and fly!
At the beginning of my career, many times my manager would give me some feedback during the appraisal process and this would be the first time I was hearing about it. Indeed an excellent way to motivate and improve employees!
And I still remember the horrors of “Goal/Target setting” at the beginning of the year. My salary appraisal would be based on how well I met my targets. And guess what, I flunked every single time. I’m the only unfortunate person who does not possess a third-eye to see the future and decide what targets would be important. I kept blaming myself until I read Goals Gone Wild.
So what’s the alternative?
Its simple: Don’t mix performance, feedback and salary appraisals. This is what I’ve successfully implemented in a few companies.
So how does it work?
If someone is not performing, they are simply not meant for the job at hand. We can help them by mentoring and guiding them. We can let them select a different project. But after the best of our efforts, if they can’t cut it, they should leave. Its best for both; the organization and the individual. I really mean the last sentence.
At some companies, I was responsible for firing the largest number of employees in the history of the company. By now you must have made up your mind that I’m this evil guy who goes around firing people. Here is the best part, most of the guys I fired, still keep in touch with me and look up to me for advice. I’m really happy seeing them grow in their new organizations. In our organization, they were stagnating and probably feeling an inferiority-complex by high performances around them. So it was best for them to leave and find a place where they can really shine.
In fact, on many highly collaborative teams (like Agile teams) poor performances can’t find a place to hide. They very quickly realize they can’t survive in such an environment. Even before anyone does anything, they are gone.
So once we’ve got rid of the employees who don’t fit into the team/organization from a performance point of view. We are left with a bunch of high performers. Remember there will always be a range in terms of performance. But the range should be too small to be worried about it.
Given that we have a team of high performers, we set up a 360 degree feedback process in the teams, which ensures that every individual is constantly getting feedback to improve. Nothing discussed in a feedback meeting with your reporting manager should be a surprise. It should be something that was discussed on the shop-floor with folks working closing with you on the floor. I call this the “Rule of least Surprise“.
Lastly we need to handle salary appraisals. To me there are 2 parts to salary appraisals:
Market Correction – inflation, job market, demand, etc. decides this portion.
Profit your product/service is making – Out of the profit, a pre-determined percentage is fixed, which would be shared with the employees. Each team decides how they want to split this percentage amongst themselves. Some teams I’ve worked with, rate each other and then based on the rating the percentages for each person is decided. Some teams just want to equally distribute the profit. Note: The distribution is based on a percentage of their current salary. Which means not everyone gets the same net amount. Employees with higher current salary will get larger amount.
One thing I learned early in my career, when it comes to vitamin M, no matter what you do, you can never make everyone (sometimes none) happy. So instead of you deciding the numbers, fix the high-level numbers based on a transparent process and let the employees take care of how they are going to split the amount.
Last, but the most important learning for me has been around tying salaries with product/service’s profit. This goes a long way in empowering the team to take total ownership and responsibility of what they are working on.
Both Mary and Tom are well known writers and speakers and probably need no introduction. Mary will be soon launching her new book ‘The Lean Mindset’ and will be sharing her some of her learnings during the course of this workshop.
We recently caught up with Mary and Tom and asked them a few questions to get a deeper understanding of what their workshop is about.
What does the title of your workshop ‘The Fastest Learner Wins’ mean?
Speed matters. Learning matters. Design matters. Speed, learning, and design – correctly balanced – are unbeatable.
Once upon a time, a company could hold on to its markets by doing what it had always done well. But today, a small group of smart people with a good idea can start up a new business anywhere in the world; they can leverage the internet and cloud computing to enter a market with a minimum amount of capital in a surprisingly short time. At first, these small upstarts are not seen as a threat by companies already in the market. But over time, the successful newcomers learn quickly and surprisingly often they have taken over whole markets with better, faster, cheaper offerings. The incumbents, caught in their successful past, usually find it’s too late to react.
What are the main ingredients that allow large companies to be able to sustain growth over time?
The average lifespan of a successful US company is about 15 years – much shorter than a career. This amazing fact might cause you to ask yourself: How can my company thrive over the long term? The answer is: Expect change and adapt to it. Our current organizations are strongly incentivized to continue doing whatever they have been doing in the past. But as companies grow large and the world changes, the only real path to sustained growth is innovation. The most innovative companies have learned to change their focus:
From productivity to impact
From predictability to experimentation
From scalability to decentralization
From making money to making a difference
What will be the key take away for the workshop attendees?
Attendees will learn strategies for improving their companies in the areas of:
1. Innovation
In a world where natural disasters and economic shocks have become routine, only the fast and flexible survive. Wise organizations devolve decision-making to the people who deliver value, sparking initiative and fostering innovation.
2. Design
If there is one thing we know, it’s that the consumer experience matters. Savvy organizations focus on the whole product and care deeply about the consumer experience. They balance empathy with data to deliver the WOW factor.
3. Learning
It is difficult for companies to innovate at the pace and scale of the market. Learning organizations run lots of experiments and keep what works. They leverage disciplined speed, system-level feedback, and validated learning.
4. Mastery
Great organizations set out to make a difference. They seek challenge rather than predictability. They foster effort over entitlement, mastery over success. They are disciplined, determined, and honest. And they keep on getting better.
Target Audience for workshop:
Managers, team leads, product owners, product managers, coaches – anyone who would like to rethink how to create winning products.
Recently I facilitated a workshop at the Agile Goa 2012 Conference titled – “Agile Way of Dealing with Uncertainty in a Complex Adaptive World“.
Abstract: It is human nature to look for patterns while solving new problems. We have a dangerous tendency to reuse what we already know to solve the next problem. We rarely discard what we’ve learned; we simply build on top of it. Sometimes this is a useful tactic, but often new problems and their context are slightly (if not vastly) different than the previous ones. And applying our previous way of doing things, will not be best suited for tackling the new problem.
In the software world, we’ve seen a similar desire to find the “one true way”, “the BEST method”, “the silver bullet” to solve all software development problems. Alas, after decades of trying we’ve not found one.
In this workshop, I’ll let you discover why this is not possible and possibly explain how best to deal with this problem. This ideas in this workshop are based on my experience backed by latest research from Cognitive Science, Complex Adaptive System’s Theory and Evolutionary Psychology.
Identifying the right pilot project is an extremely important first step towards your Agile transformation journey.
While selecting a pilot project, I generally look for the following characteristics:
Importance: We don’t want to start with a project, which could shut down your business if things went wild. Nor do we want to pick a small pet project. Even if we proved Agile works well, it won’t appeal to the organization as it won’t be representative nor credible. A critical project with high-enough stakes is ideal.
Dependencies: Fairly self-contained projects with minimum external dependencies are relatively easier for introducing change. If the team does not have the necessary skill or authority to take decision or if most of the project’s attributes are outside the organization’s control, it would be a very difficult pilot project.
Stakeholder Engagement: Access to all the stakeholders is critical. Their involvement and buy-in is extremely important to make any sustainable change.
Top-Management Support: During the transition, the team will run into many roadblocks and challenges. Having a good management support and backing will motivate the team to creatively solve those problems.
Duration: To effectively capitalize on the learning and excitement, it’s important for the pilot project to be between 4-9 months.
Size: A single collocated team with less than 10 members is an ideal size to coach. Gradually we can grow this team to large multi-site geographically distributed team/s.
Stage: If the project was already in a fire-fighting mode, the team members would be under too much pressure to try anything different. If it’s a laid-back large maintenance project, team members might not have the motivation to change large legacy system. Project in its early stages with most of its team members on-board, seems to be a good stage to introduce Agile and Lean thinking.
Team Composition: Most successful organizations have strong (vocal) leaders or connectors at the grass-root level. If we can influence these folks early on, they can be our internal change-agents. Hence while picking a pilot project, we consider their density in the pilot team.
Identifying a project with all these characteristics would be ideal, but is rarely the case. A good coach knows how to make reasonable trade-offs.
In today’s complex and dynamic environment, where companies are mercilessly eliminating waste and optimizing their processes to lower costs and improve operational efficiency, the term “slack” conjures up a host of negative perceptions.
Time and again, we run into companies that focus way too much on capacity utilization and ignore turn-around time and throughput. I’ve worked for companies who would hire more people, so work can be parallelized and done faster. But when that does not happen, they create work to keep everyone busy. Work expands to fill the available time and to keep everyone perpetually occupied.
Over and over again, we see companies batching work into large chunks, introducing all kinds of specialization, fancy workflows, layers of indirection and integrations in the name of better efficiencies. They might get better output, but are they achieving better outcomes?
Efficiency is the enemy of Effectiveness – Tom DeMarco, Slack
Let me share a story about Slack:
Yesterday I was invited to share my experience on “Enterprise Agile Adoption” to the entire Sr. Management @ big fortune 500 company.
During my talk, I describe my job at a company, which adopted Agile across the board. I said:
My job was to do nothing! I was not leading any team. The founder of the company (who hired me) did not set any targets or goals for me to chase. Basically I was there to do nothing.
People in the room, started laughing accusing the founder to be stupid and naive.
Don’t jump the gun yet. I discovered something magical.
Since I was not running around like a headless chicken, more people would stop by to have an informal chat. Like the one you have at a water-cooler or a coffee machine (think of serendipity & its implications on creativity for knowledge workers.) Many times we would end up in a spontaneous discussion/debate, shaping each other’s perspectives. Some times people would come to me with a specific questions/issues. Some times they would ask me to lend an ear for their rants. At times, when they were completely swamped, they would ask me to roll-up my sleeves and help.
Because I was not as smart as most of those guys, I would simply connect them with someone else in the company who could help. We also did a lot of random events to ignite their thirst for learning.
All of this led to a great bonding with the teams. In some sense, I was playing the role of a connector. I won their trust. And soon, in a couple of months, I was the go-to person (at least start-with person) in the company.
Team members would compliment me saying:
Many deep-routed, hard organizational problems are being silently solved without anyone making a bid deal about it.
Which I thought was profound. And frankly I never felt this kind of satisfaction or sense of accomplishment before. This was by far, one of the best Agile transformations I’ve experienced.
Let’s step back and see what was going on there?
By bringing me in and not assigning me to any specific tasks, the founder introduced Slack into the organization. (I don’t think it was all planned, but the end result far exceeded our expectations.)
I experienced both kinds of slack:
Time Slack – Since I didn’t commit to a task list nor was I being measure on how occupied I was (busy-ness metrics), I had a lot of flexibility. I had extra cycles, over and above the time required to finish the current work at hand. Which allowed me to be creative, experiment with new ideas, learn new stuff, adapt to changing priorities and be available to help anyone at a very short notice. Sounds like your grandmother’s advice “Work smarter not harder!”
Control Slack – I wasn’t running to the founder for every little thing. I could take many decisions on my own. I even had a flexi-budget to invest/spend on things. In general, the company’s culture was very flat. Employees would make a lot of on-field decision. The company had a very decentralized decision making approach which lead to quick turn-around on issues. People were free to choose which projects to work on. It was perfectly fine to make some mistakes while learning new skills or attempting new projects. They massively leveraged the knowledge of people on ground to make well informed decisions. Even if the decisions were wrong, it took a small amount of time to fix them. Things would just happen at this company.
Exciting right? Slack sounds like common-sense right?
But for many years, there has been an ongoing debate among organizational researchers on the role slack plays in organizational adaptation (Bourgeois, 1981). Some argue that slack provides resources for innovation and change, thereby enhancing a firm’s ability to adapt to environmental shifts and improve long-term performance (Cyert & March 1963; Carter 1971; Mohr, 1969). Others argue that slack is an analog for inefficiency – a buffer which shields the firm and, in some cases, blinds it from changes which are needed to meet external demands (Litschert & Bonham, 1978; Thompson, 1967; Yasai-Ardekani, 1986; Williamson, 1963; Liebenstein, 1969; Migué and Belanger, 1974).
Nohria & Gulati (1997) took an intermediate position and argued that there may be an optimal amount of organizational slack because limited slack inhibits innovation by discouraging any experimentation whose success is uncertain while an abundance of slack also may inhibits slack by fostering complacency and lax controls.
Based on my experience with organizations, which rely on knowledge workers, I tend to agree with Nohria and Gulati. You can think of slack like a rubber band. A rubber band works best when it’s tight but not too much tension, and it doesn’t work at all when there’s absolutely no tension.
For example, 3M is legendary for providing it’s scientists with semi-structured time to work on their own projects of interest.
Google encourages its engineers to spend 20% of their time on projects that interest them, and the VP of Search Products and User Experience found that 50% of new product launches originated from the 20% time. Notable products from time off include Gmail and Google News.
In his book, Tom DeMarco compares slack to an open space in an 8-tile puzzle.
Organizations without the slack, are like a 9-tile puzzle with no open space. The result is highly efficient, but change becomes impossible: People are just too busy with operational work to think about the future.
eXtreme Programming has a practice called Sustainable pace. But unfortunately this practice is often forgotten or companies struggle to put it in practice. The idea is that productivity does not increase with hours worked. Tired programmers are less productive than well-rested ones.
Tom suggests that businesses that build in sensible amounts of time and control slack enjoy four specific competitive advantages:
At the Agile India 2010 conference, Sandeep and I ran a workshop to shed some light on the kind of aping that’s taking place in the software companies trying to be Agile.
Clearly we don’t have all the answers. Nor do we know the best way to build software in the right way (if there was one.) But we do know one thing:
The right way doesn’t involve mindlessly following practices just because some “expert” says you need to.
In this workshop we took a critical look at various “agile” practices and tried to highlight the dogma and ceremony that has creeped in. We also questioned if the practices defined a decade ago are still applicable? If yes, have they evolved since? What are some of the original creators of these processes practicing today?
This is an introductory presentation on the essence of Being Agile vs. Following Agile. And why being Agile is important? I’ve also tried to show an evolution of Agile methods over the last 11 years and the future of Agile. Also take a sneak preview into what challenges an organizations may face when trying to be agile?
How do you measure or know the effectiveness of a Scrum Master?
IMHO on a given team, in less than 6 months, an effective Scrum Master will:
make themselves redundant
make process second-nature for the team
That would be the true test for their effectiveness.
In the mean time, I would look for:
Has the SM been able to win the team’s trust and build credibility with the team? Does the team see the SM as an integral part of the team?
Apart from effectively facilitating (not enforcing) the Scrum ceremonies, is the SM helping the team understand the rationale behind those ceremonies?
Is the SM creating a culture of safe-fail experimentation where the team can experiment, learn and grow beyond the standard Scrum ceremonies? If the team is not evolving their practices and work culture, is the SM really doing their job?
Does the SM encourage System’s Thinking and uses techniques like Value Stream Maps, Five Whys, A3, etc. to identify & highlighting bottlenecks in the team?
Has the SM been successful at creating Self-Organized Empowered Team? Or is the team waiting for directions from the SM?
Is the SM able to emerge as a leaders and be the voice of the team, shielding the team from external interferences, yet creating a healthy collaborative culture?
Is the SM able to motivate the team and steer them towards excellence?
Is the SM abel to put a framework in place for the team to record and surface important and relevant data about the team’s performance? Using techniques like information radiators to build informative workspaces. Basically enabling the team to get food for improvement.
Is the SM proactive (instead of reactive) about resolving issues?
Is the SM approachable? Believes in servant-leadership?
Does your SM have first-hand experience working in Scrum teams? Extremely knowledgeable about processes?
Is the SM up-to-date with the latest trends in the industry? Keen learner and open-minded?
Can come up with a product vision which motivates, inspires and drives the team
Aligns the product vision with company’s vision or mission
Passionate Problem Solver
Should have a knack of identifying real problems and ability to visualize a simple solution to those problems.
Has good analytical & problem solving skills
Subject Matter Expert
Understands the domain well enough to envision a product to solve crux of the problem
Able to answer questions regarding the domain for those creating the product
End User Advocate
Empathetic to end-users problems and needs
Able to describe the product from an end-user’s perspective. Requires a deep understanding of users and use
Is passionate about great user experience
Customer Advocate
Understands the needs of the business buying the product
Ability to select a mix of features valuable to various different customers
Business Advocate
Can identify the business value and synthesize the business strategy as measurable product goals
Has a good grasp of various business/revenue models and pricing strategies
Capable of segmenting the market, sizing it and positioning a product (articulate the Unique Selling Proposition)
Is good at competitive analysis and competitor profiling
Able to create a product launch strategy
Communicator
Capable of communicating vision and intent – deferring detailed feature and design decisions to be made just in time
Decision Maker
Given a variety of conflicting goals and opinions, be the final decision maker for hard product decisions
Designer
Possess a deep understanding of (product) design thinking
Able to work effectively with an evolving product design
Planner
Given the vision, should be able to work with the team to break it down into an iterative and incremental product plan
Capable of creating a release roadmap with meaningful release goals
Is feedback driven .i.e. very keen to inspect and adapt based on feedback
Collaborator
Able to work collaboratively with different roles to fulfill the product vision. Be inclusive and empathetic to the difficulties faced by the members of the cross-functional team
Given all the different stakeholders should be able to balance their needs and priorities
Empowers the team and encourages everyone to try new ideas and innovate
Disclaimer: This list is based on my personal experience but originally inspired by discussions with Jeff Patton.
In my experience its hard (not impossible) to find someone who possess all these skills. It requires years of hands-on experience.
Some companies form a Product Ownership team, comprising of different people, who can collectively bring these skills to the table. Personally I prefer supporting one person to gradually build these skills.
I amazed how easily companies get convinced that they can send their employees to a 2-day class on Product Ownership and acquire all these skills to be a certified Product Owner.
