Incentive Programs and Professional Motivation
I recall some years ago having read this Joel Spolsky post entitled "Incentive Pay Considered Harmful." In typical Spolsky fashion, he made a very compelling case that I had a very hard time coming to grips with. At the time I'd just recently made a series of contributions to Novell, outside of the scope of my job description, that I felt had an obvious positive impact on the company, but I had not received any sort of recognition at all for this.
Joel's article strongly disagreed with me. I felt I should have been recognized for my efforts; why else would I take the personal risk that comes with extending one's self in that fashion? Instead, nothing had been done.
I've been pretty interested in this topic and so I've been observing and evaluating ever since. What I've seen is that, for the most part, incentive programs tend to have the opposite effect of their purpose; namely, they tend to demotivate rather than motivate.
Outlined below are some reasons why.
People Get Rewarded Just For Doing Their Job
Maybe you've seen this too: You attend a quarterly all-hands meeting when an individual you know and work with is asked to come to the front. They announce, "Tom did a really great job running our beta program last release, and so we are giving him the quarterly Mega-Smiley-Face award, with a free dinner for two and a new iPod Touch." You sit there and stare, clapping insincerely. Sure, Tom did a great job running the beta program. But Tom is the beta program coordinator! It is his job to run the beta program! You did great work with your assigned responsibilities last quarter also. Why aren't you getting an award?
One problem with this scenario is that the rewards program now seems arbitrary. Tom was rewarded this quarter for doing his job. Who will be next? Who knows? Everyone is doing their job, but not everyone gets rewarded. The rest of the people feel discouraged. The recognition seems to be something worth earning, but they don't know how to earn it.
Another problem with this scenario is that it sends the wrong message to the team. Nobody should be rewarded just for completing their assignment — or everybody should be. Tom gets paid a salary for him to do his job. He's expected to do it well. If he gets rewarded just for doing his job, it tells the rest of the team that some jobs matter more than others. How do I get an assignment that matters? they wonder. And why am I wasting my time doing work that isn't important?
Luck and Timing Often Play a Bigger Role Than Excellence
In my nearly 15-year career I've delivered a lot of software to customers. I've invented things, learned difficult technology, solved complex problems, led and motivated teams, and proposed key strategic decisions that have helped the companies I've worked with become more successful. How many trophies do I have on my shelf? One. It is a beautiful blue piece of plastic that I got last summer when the Microsoft division we belong to eclipsed the $1 billion revenue mark for the first time. I'd been with Microsoft about six weeks at the time.
Earning that award (using that word very loosely, by the way) required nothing of me other than accepting a job at Microsoft at the right time. I hadn't written a line of production code yet, and certainly did not contribute to that revenue. I figure it replaces many others I should have earned but didn't.
I'm proud of the award, but I'm the first to admit that I earned it primarily due to fortuitous timing.
Positive Effects Are Usually Short-Lived
I remember one time being on a software team when we realized one morning that we had a serious bug. A problem had been reported by our released product that was having a significant customer impact. One member of the team stepped up to the task of digging into the issue and finding the problem. When he found and fixed the problem later in the day, he was genuinely thanked and given a gift certificate as a show of gratitude from the company.
The following day, our team was in a team meeting when the topic of the previous day's bug came up. We were being asked to identify what we were going to do differently in the future to avoid this problem. The same team member that had saved the team the day before took this as a personal offense. He muttered something to himself under his breath, slammed the lid of his laptop shut, picked it up and stormed out of the conference room.
Clearly, the special effort the company had made to thank him had been completely forgotten in less than 24 hours.
Abuse Makes The Programs Become Meaningless
I've frequently seen well-intentioned incentive programs become so abused that they become a laughing stock. One is almost embarrassed to truly earn an award because so many others have been similarly recognized for awards they acquired through dubious means.
Novell's Employee of the Year kind of took on this sentiment for me after I first saw one person get the award after taking full credit for something I knew full well he did not do (because I did it). Later I saw a colleague, the proven highest contributor on his team, get passed over for this award when his manager instead gave it to the lowest contributor in an effort to motivate him.
Probably the strangest of all of these though is for a company I've heard of with a very generous patent award program. One of their employees has learned to double his annual compensation by filing patent after patent through the company's patent program. Of course, filing all of these patents doesn't leave much time for him to do his regular job, and the patents being filed may not have anything at all to do with the company's products or strategy. But he's so innovative and valuable to their inconsistent patent portfolio that they've had no choice but to promote him over and over.
They Encourage Individualism Over Teamwork
Through a trusted source I heard about a support department for a software company years ago. They had instituted an incentive program called "55 Stay Alive". This great program with such a catchy name was very simple to understand: Each employee had to close 55 incidents each month or they were fired.
Awesome, huh.
One employee made a pitch to management, explaining that the incentive program was very negative and instead suggested they rearrange things to have a single goal that the whole team could work toward together. Management was hesitant but the team was willing to put it to a test.
So they did, with amazing results. Every month the team closed far more incidents working as a group than they ever had working as individuals before.
Logically, management was very unhappy about this insubordinate behavior so they fired the guy.
This might be an extreme example, but you've probably seen lots of examples of this. Many incentive programs reward people for behavior that leads them to focus on individual achievement at the expense of team achievement, which would be much better for the company.
So What Does Work Then?
One of the best incentive programs I've ever participated in was at Novell, working for a manager who ironically was really not that great of a manager. Novell being a Linux company, he had been given a small 6-inch figurine in the likeness of a Linux penguin which we called the Tuxen.
Every so often, in a team meeting, he would recognize someone for a specific assignment they'd done well. Then they would be awarded the Tuxen for a week. Each winner was expected to proudly display the Tuxen and take it places and publish photos of their adventures on the team wiki.
One week I was awarded the Tuxen for work I had done to help start the Eclipse Linux Tools project. I proudly took the Tuxen home with me, took photographs of the Tuxen with my family, and brought it along on a trip with my son to the Las Vegas Supercross. I gave it back a week later, but it was one of the most rewarding recognitions I'd ever had.
When I first read Joel's blog post, I immediately e-mailed him with my concerned, contrary opinion. "So how DO you reward people and make sure they know they've done well?" I asked.
"Just thank them," Joel said.
Maybe you're wondering, could it really be that simple? Instead I'd ask, why does it have to be more complicated?
Good Technical Interviews Require Good Technical Interview Questions
We're hiring at Microsoft UDC and interviewing a lot of people. Which is why this recent article on Coding Horror stood out to me, on the surprising fact that many software engineers struggle when it comes to actually writing code.
I haven't actually interviewed any of the people coming in yet, so I'm not really talking about any candidates that we've looked at because I have no experience with them. It was a timely article, though, and I am familiar with the struggle of the interviewer, having done it a lot at Mozy.
It's clear from the article, if you aren't already convinced, that asking interviewees to code as a part of the selection process is an absolute must. I'd also say, as a sidenote, it's also an indication of a serious software company. If you are interviewing with a company who doesn't test your programming skills, wouldn't you wonder how many people are on your team who can't code?
Anyway, coming up with good questions can seem hard, though. Some things to avoid:
- Complex problems that require even good engineers a lot of time to solve. You probably only have about 20 minutes for this question, which probably really only leaves the candidate about five to figure out how to solve the problem, and another fifteen of implementation and discussion. "Implement an ORM framework" is probably too complex or big.
- However, slightly complex problems can be good questions, if you provide enough background to cut the question down to the time you have.
- Domain-specific problems aren't that good at figuring out if someone can generally code. An outstanding C programmer who doesn't know C++ won't know how to implement their own insertion operator, even though they might be awesome and could easily learn it if they needed to. Even a great developer who has spent his whole life optimizing 3D rendering engines for computer games may have never once connected to a database, so he might not know anything about how to write a SQL query.
- Know the problem well enough to determine if any proposed solution will work; don't shut down a candidate just because he solves the problem differently than how you would do it.
The great thing is, apparently even simple problems can be good enough to find out if someone knows how to code. I wouldn't recommend you rely solely on the simplest, but coming up with a decent set of problems isn't too tough if you give it some thought. Here's some suggestions:
- Consider the source of your technical question and how long it took you to solve it. If you dredged it up out of your past experience, it might be a pretty good question because it obviously has some practical application. If you were able to come up with a solution to the problem after thinking about it for just a few minutes, and additionally if one of your colleagues is able to do the same, the problem is not too difficult for an interview question.
- This doesn't mean your candidates will easily get it, however. Don't get discouraged. If people on your team can solve this problem but your candidate cannot, that means the candidate is not of the same caliber as people on your team. That's not a good fit.
- It IS true that some people don’t think as well under pressure as they do on their own, or that your problem might just be in an area that they aren’t familiar with. It’s good to have a set of simpler questions on hand to ask them in case they stumble on the harder one. If they don’t get one of your hard questions but they can solve a simple one, at least you know they can solve SOME coding questions.
- Practice your questions with your colleagues. This will help you with clarifying the context and purpose of your question, make sure you structure it so there's enough time to answer the question, and make sure the question isn't too hard, too easy, or unclear.
- Choose questions that help you evaluate core competencies: algorithm and class design, proper use and understanding of data structures, pointer math, modulus math, understanding of data types, string manipulation, threading and thread safety, etc. Be sure your questions are designed to help you select the kind of people you want.
- For this reason, I don't like to ask really deep language-specific questions anymore (although if a candidate claims to be an expert in a specific language, these are fair game) or API-specific questions. Even if I use C++ and WxWidgets this year, I may not next year. What I want is someone who knows how to program. It doesn't take long at all for a good programmer to learn a new language; probably much less time than it takes to manage a bad programmer out of your team.
What really surprised me when I started interviewing at Mozy was that I'd heard all this stuff before, but had a hard time believing it. That is, until I experienced it firsthand during interviews there. I remember interviewing a candidate who had several years of experience in game development. Game development! These guys are the super-elite of developers, right? So I wondered if asking him to reverse a string might be too easy for him.
It wasn't.
Not a complex string reverse. Not a unicode string. Not in some obscure language he wasn't strong in. Just a basic string reverse in C, with a null-terminated char* argument containing the string to reverse. I even gave him the flexibility to reverse it in-line or to make a copy. I was surprised when he really struggled with this.
He wasn't the only one. String reverse is not a hard function, but I was surprised how many people struggled with it. So don't be surprised if people struggle with questions you think they should be able to answer. The numbers seem incredulous, but apparently it is really hard to find a good developer. So don't give up, my son.
Trusting Teams
We all know how it feels to be trusted. That's a big part of our profession as software engineers. Our job is not just to solve a problem, but to do it in a way that is highly performant, easily maintained, efficient, extensible, secure, resilient, and correct. We have to understand what customers need, not what they say they need. And before we even solve the problem, we have to estimate how long it will take us to solve it, and make and keep commitments for when we will deliver.
It is a tough job, but we're pretty good at it. Like Michael Jordan in the NBA Finals, we know we can step up and perform. We enjoy that feeling of coming through and delivering.
Because we are good at what we do, we like feeling like our employers trust us. We don't want to work for employers that don't. It bugs us when our boss tries to tell us how to do our job or doesn't believe us when we declare that we will be done on time. The satisfaction that comes from keeping your word is diminished if someone is breathing down your neck every step of the way.
This is what true delegation is about, and I'm a big fan. I'm a Covey disciple and not afraid to admit it. In fact, when I once interviewed for a job, I was pushed on the concept of delegation, and I declared, "Why do they work for you if you don't believe they will do what they say they will do?" There's a great amount of job satisfaction that comes from filling a stewardship that is truly yours.
The problem is, it isn't quite like that in teams — at least, not good ones.
We had a rather interesting team status meeting this past week at UDC. I won't go into details, but as I thought about it over the rest of the week, I could see a clear issue near the heart: People not feeling trusted in their stewardships.
After thinking about this a lot, discussing it with team members, and re-reading "The Five Dysfunctions of a Team" by Patrick Lencioni, I hit upon a bit of an epiphony for myself that helped me understand the issue better.
The most basic team dysfunction he identifies is an absence of trust. Toward the end of Lencioni's book, he explains this further:
In the context of building a team, trust is the confidence among team members that their peers' intentions are good, and that there is no reason to be protective or careful around the group. In essence, teammates must get comfortable being vulnerable with one another. This description stands in contrast to a more standard definition of trust, one that centers around the ability to predict a person's behavior based on past experience.... As desirable as this may be, it is not enough to represent the kind of trust that is characteristic of a great team. It requires team members to make themselves vulnerable to one another, and be confident that their respective vulnerabilities will not be used against them.
Upon reading this, I realized instantly how this related to our team.
Suppose you are the lead of a team of six engineers. Your team is working in a one-month milestone, and you've got about six person-months of work to be done in that milestone. How do you go about getting it done?
Well, you could try running the whole show by yourself. After all, you are the lead. So you could go among the team members all day long, telling them what to do. You could tell them what class hierarchy to use, what data structure to use, what design pattern to use. You could critique their naming conventions or even tell them what character to type when.
You might make your milestone, if those engineers are still working with you at the end of a month. But even if they stay, you've lost the opportunity to get them to buy in.
Of course, we all know that strategy is flawed, so you try delegating instead. You trust your team. If they say they will do it, they will. So you give them each assignments, or you let them choose their assignments. They each have their own area of stewardship, and they each commit to be done at the end of the milestone. So, I guess you can just go golfing for the rest of the month, right? Then come back at the end of the month and everything should be done.
They said they would be done, so they'll be done, right? That's what it means to trust. Unless something came up, of course. But even if they all did make it, they missed out on a great opportunity: The opportunity to be a team.
See, teams do trust each other. They rely on each other and believe in each other. But they work together anyway. They meet together. They hold each other accountable. They win and lose together.
In the previous scenario, if five of your six engineers had completed their work, does that mean success or failure? Does that mean you were 83% successful? Do you just round up and say you were generally on target?
Great teams don't do that. They succeed and fail together. In a great team, five out of six people being successful is a failure on two fronts. First, they failed because they didn't accomplish the team goal. Second, they failed to pull together as a team.
So let's go back a month. How does that team pull together?
The team has to care about each member. It has to hold itself accountable for a common goal, and commit to win together or not at all. Because of this, the team must ask each other hard questions.
When this happens to you, as a member of that team, you might feel like you aren't being trusted. This is when you have to do what Lencioni suggests: You have to trust your team enough that they can ask. You have to trust them enough that you believe they have the right intentions at heart. You have to trust that when they dig on you and question you, they won't hold it against you if they find a flaw in you. You have to trust that when you question them, they won't take it personally either.
The questioning is part of the deal if you want people who are passionate and care and want to win. What do you do when someone you care about comes home? You ask them questions. You ask about their day, who they saw, how things went, what they learned, how did their presentation go, etc.
You don't ask these questions because you don't trust them (er, usually, anyway). You ask because you care. Asking questions is how we express interest, concern, and buy-in.
When you work for a company that cares, questions are part of the deal. Microsoft cares. We are passionate about technology. We want to win. We want our teams to win. We want to create great products and delight customers. Everyone in my management chain has this passion. So, I can expect this kind of questioning from everyone in my management chain.
I've worked for other companies that don't have this passion. It shows because nobody asks, about anything.
The same holds true for teams. Teams ask each other. They are honest with each other. They are open with each other. They rely and depend upon each other. And they win and lose together.
I've been on teams like this. They are AWESOME. As great as it feels individually to fulfill a stewardship, it feels even better to be a part of a team that works together and helps each other and wins. The cost of entry? Humility. Vulnerability. You have to be willing to let your team ask you about your approach and technique and decisions, and be willing to let them dig and dig. They do this because, like you, they want to win. They want to win WITH you, not OVER you. And they depend on you to question them so you can win with them also.
When your team does this, when you really trust each other and open up to each other, you'll find weaknesses, problems, and concerns. Each time you do this, it is an opportunity to pull together as a team and win together. Your strengths compensate for my weaknesses. Instead of six people individually trying to deliver six distinct units of work of about one person-month of effort each, you have six people working together to deliver six person-months of work. My weakness may have been my downfall when I worked alone, but now that we work together your strength can compensate for my weakness, and mine can compensate for yours. We can do more together.
Kum-ba-yah. Even though I believe this, I think I'm going to be sick with all this syrupy feel-goodness if I don't stop soon. But that doesn't mean it isn't real. Be passionate enough about success as a team that you are willing to learn from each other and challenge each other to grow together. Care enough about your team to respectfully question your teammates, and trust that they care about the team when they question you. If you do this, you'll find that working on that kind of a team is an experience you'll remember your whole career.
Getting Coders to Code
Think back over the last project you worked on and the time it took to complete it. How was that time spent?
At first glance you might come up with a list like this (in no particular order):
- Gathering requirements
- Designing
- Implementing
- Testing
Think about it harder, though, and you might come up with a number of additional things:
- Sitting in meetings
- Waiting for people to review and approve your documents
- Waiting for people to finish reviewing your code
- Reviewing other people's code and documents
- Setting up dev and test environments
- Dividing your logical tasks into smaller, sometimes illogical units for the purpose of tracking
- Entering tasks into an issue tracking system
- Documenting and updating status on assignments
- Reporting status to management
- Branching and merging
- Fixing bugs
- Reading e-mail
- Administrative and red-tape
Now, go through the list you have. Which one item are the customers actually paying for?
That's pretty easy — the implementation. Ultimately, what the customer is paying for is for you to write code.
This begs the following question: If writing code is what customers are paying for, why is so much time spent doing the other stuff?
Your knee-jerk reaction would probably be that all the other stuff helps you to do your job better. Generally, I'd agree that most of those other items CAN help you do your job better, but I'm going to challenge the reason why you are doing them.
Writing code is the primary activity of a software development team. To be more specific, writing correct code should be the primary activity of a software development team. Given a specific feature that customers will pay for, every correct line of code written for that feature directly contributes to revenue.
Therefore, in order to maximize revenue, your goals should be to:
- Maximize the amount of time that your developers can be writing code
- Optimize that time by improving the likelihood of each line of code being correct
Seems pretty simple, right?
Now, take a look at the way you conduct your work. Ask yourself this question: How would your work change if the focus was to spend as much time coding as possible, and to improve the correctness of each line of code?
Would you change the way you do your work? If so, why are you working that way?
