How Long To Dig A Posthole?
Some days ago at work I asked a friend what he'd done over the weekend. "Dig a posthole," he replied.
That seems an odd answer since there's quite a bit of time in a weekend. He followed with, "How long does it take to dig a posthole?"
When my wife and I moved into our first home, we had two young kids and no fence around our yard. After we'd saved the money, one of the first purchases we made was to buy materials to build a fence, which included some 40 or so fence posts if I remember correctly. Each of these needed to be set a good two to three feet deep in a posthole and set with concrete.
I say this so it is clear that, while I'm no expert, I do have some experience with postholes. If you have a good shovel and a good posthole digger, even someone of average fitness like myself can dig one in fairly short order. "Oh, maybe 20 minutes," I replied.
"I spent three or four hours digging a posthole on Saturday," my friend countered.
Ah, yes. I forgot that digging a posthole takes 20 minutes, except when it DOESN'T take 20 minutes. You might be digging in clay, which is much heavier and will wear you out faster. You might hit bedrock or caliche. You might encounter a rattlesnake den. Or, like my friend did, you might simply run into a series of large, flat rocks, one on top of the other, right where you need the post to go.
So, a posthole takes 20 minutes to dig, unless it takes an hour, or half a day, or longer. A shovel and a posthole digger are the right tools for the job, except when they aren't. And when they aren't, you might need a backhoe-mounted auger, or dynamite.
The point is, you can't ever tell for sure if your posthole will be quick or slow until after the digging has begun. Unless you are an accomplished geologist, you don't know just by looking at the ground where you want the post to go whether this posthole will be quick or slow.
Writing software is much like this. The very nature of our job means that most of the time we are, to use the metaphor, digging where nobody has dug before. We're always inventing new things. Given any development task, we can give our best estimate as to how long the task will take based on our past experience and our understanding of the nature of the task. But this estimate is much like the estimate of how long it takes to dig a posthole: You don't know what you are going to uncover until you start digging.
Unfortunately, sometimes software management misunderstands this. There's sometimes a belief that the estimates are much more accurate than they really are, and that missing an estimate is an inexcusable offense. But this would be like getting upset with my friend because there were rocks in the ground where the posthole was supposed to go.
Failing to know that there are rocks underneath the ground shouldn't be a sin. Ultimately, my friend got the posthole dug anyway. That's what we do, too: We encounter the rocks, we figure out how to get them out of the way, and we continue to deliver. Hitting all your estimates all the time isn't the important part. Delivering useful software is the important part.
Partial Baskets Are Still Worth 0 Points
In the 2010-2011 NCAA basketball season, Butler University built atop an improbably successful basketball season the previous year by repeating their run to the NCAA title game. There was a lot of hype leading into the game. Could mid-sized Butler really topple a mighty basketball powerhouse like UConn and win a national championship?
Butler came into the game full of quiet confidence, but for whatever reason they were never able to find a shooting rhythm like they'd had in previous games. In the biggest game of the year they managed to make only a pitiful 18.75% of their shots from the field. They fought hard, executed their offense and played excellent defense, but were not able to overcome such woeful shooting numbers. UConn won the title, and Butler got to head home, in the words of Jerry Seinfeld, as "the best loser."
It's not my intent to pick on Butler — I often cheer for the underdog so I was hoping they would win. My heart broke for them as they continued to try in vain. The point is to drive home the title of this post: Partial baskets are still worth 0 points. Butler had so many partial baskets, shots that nearly went in, that they may have won the game if those counted for something. Unfortunately, a partial basket is worth the same as a turnover: Nothing.
It's funny how obvious this is in sports, but when it comes to business we pretend like it doesn't apply.
Let's suppose you are working on a software product, and you have exactly one primary competitor. You both ship your next release at the same time. Your competitor's product has 10 key features that customers want. Your product has 8 of those same features. You also know you were working on the other two features, plus five others, but those seven features did not get into the product.
Imagine your sales rep going into one of your big customer accounts:
Sales Rep: "Check out the new version of our product. It has 8 new features that are important to you!"
Customer: "Yes, but your competitor's product has those features plus two others. Why should I choose your product instead of theirs?"
Sales Rep: "That may be true, but we almost completed those two features, plus five others! We have seven other features almost in the product!"
Of course, the customer doesn't care about those other partially completed features. Partial baskets are still worth 0 points. So if the customer doesn't care about partially completed features, why do you?
Why do you track and report a "percentage complete" metric for your tasks? Why do you go into a status meeting and report that your project is 50% done? You cannot sell a feature, or a project, or a task that is less than 100% complete, so why do you measure for it?
One of my most prized learnings from Peter Drucker's "Management" book was this basic principle: Performance measurement should be focused on measuring things that matter to the customer. That's why I try to stay away from recognizing partial completion, and why you should too.
Organizations that can focus around this line of thinking will find that they become more in tune with their customers because they are continually thinking about their offering from the customer's point of view. Thinking about a feature as 80% complete is thinking about it from the individual contributor's point of view. On a 10-week project, the individual contributor has done 8 weeks of work so they are 80% complete. They want those 8 weeks to matter; of course they do. But those 8 weeks don't matter to your customer unless the other two weeks of work are also complete and the project is actually finished and shipped. Customers don't care about partial completion; they think in binary, even if they don't understand it. Complete. Not complete. Those are the only two states that matter to a customer.
Those are the only two states that should matter to you, too.
Grading on a Scale – I Mean, a Curve
Miguel de Icaza tweeted this today:
Performance Review Season at Novell is easy when your entire team is made of 100% super-awesome hackers.
It's a very nice thing for Miguel to say about his team, something I have no reason to doubt. I don't know Miguel too well, but I have been in a handful of meetings with him back in my Novell days. He doesn't strike me as the type of person to be disingenuous, and regardless of how you feel about .NET on non-Windows platforms, you have to be impressed with the impact and effectiveness of Mono, so I figure his team probably is pretty awesome.
I guess when you are among the privileged at Novell, you can do things your way. I know when I was at Novell, having a team full of awesome people didn't make performance reviews any more straightforward. Novell is by no means unique in this; I can personally attest to this fact.
At most big companies I've been at, how performance is measured depends on what time of year it is. If you are measuring performance during any other time of the year, you do this by comparing a person's efforts against a published definition of their job description and level. For example, on your company's intranet somewhere there is a document that describes the expected level of performance for a mid-level software engineer. If you are a mid-level software engineer, you can compare your performance against the published standard and determine if your performance is currently on track or ahead of or lagging expectations.
This is true at any time of year except during performance review time. During performance review time, suddenly your performance is measured by how you compare to your peers. So now, if you are a mid-level software engineer, your performance is based on how your performance and contributions compare to the other mid-level software engineers in your organization.
For some reason this seems to be a pretty common way to measure employee performance, and yet it makes absolutely no sense to me. In casual conversations with peers (and, frankly, also with a number of managers who will remain unnamed here), I think I can confidently say that it makes no sense to most other people either.
Imagine you are attending college and you sign up to take a calculus class. On the first day of class, the instructor hands out a syllabus which clearly explains how you will be graded, which boils down to this: If you get 95% of all the questions right on homework and tests, you will get an A, and the scale breaks down from there. As the semester proceeds, you monitor your performance on homework and tests, studying to meet that magical 95% mark. On the last day of class, you enter confidently knowing you have a 96%-97% average which gives you a little bit of a buffer on the final. You leave the final feeling pleased with yourself, sure that you got at least 19 of the 20 questions right.
Then the grades come out, and you have a B-.
You go and ask the professor, and he says, "Well, I changed the grading from a scale to a curve. See, everyone was getting As, and we can't have that. So I graded on a curve instead. You got a B-."
This is effectively how most employee performance measurement techniques work. Your performance is graded on an objective, defined scale all year long. Then comes performance review time, and suddenly you are now being graded on a curve, not a scale. Before you knew where you stood; now, you have no idea.
A normal distribution curve makes sense when applied to a statistically average sample. The question is, does your employee population comprise a statistically average sample? In order to do that, you'd pretty much have to be willing to hire anyone who walks in the door asking for a job. You probably don't do that; you are probably very selective in who you hire and keep. You probably try to hire only the best talent you can find. You probably take the approach of preferring to sometimes pass on talented people that you aren't sure of, rather than give the benefit of doubt, and so you've probably rejected some talented candidates.
That means your employee population is not statistically average. So why is it that during performance review time you try to make this anomalous sample conform to a normal distribution curve?
I've worked for companies where they say that, organization-wide, some percentage of the population of any given job function MUST be underperforming, some percentage MUST be overperforming, and the rest MUST be performing at around average, within about a standard deviation or so. This isn't just a belief. It is enforced through policy. Essentially the policy says it is not possible to have an organization with 100 employees that are all high performers. Instead, you might mandate through policy that 10 of them must be underperforming, 10 must be overperforming, and the remaining 80 are average or near-average. Yet when you hire, you insist that you hire only the best.
This doesn't make any sense, and in my opinion it is a dangerous practice.
First off, you aren't fooling anyone, especially not the intelligent, highly-educated type of thought worker that tends to be evaluated this way. You wanted smart people, you hired smart people, and now you have to pay the consequences: You can't implement obviously flawed policy like this. They will pick up on it and it will cause them to lose faith in your organization.
Second, it encourages exactly the wrong type of behavior. Once they realize that their actual performance measurement has less to do with their evaluation against an objective metric than it does against their peers, employees will be incentivized to game the system. This may manifest itself in many ways: refusing to help teammates or to work well as a team; manipulating the assignments given to them and others to maximize their relative performance; taking opportunities to point out to you (the manager) how excellent they are in comparison to others or how rotten the others are in comparison to themselves; attempting to make others look poorly or to make themselves look good in public, e.g. meetings; trying to hire people who they know to be less competent than they are; avoiding promotions (and thus responsibility) for the sake of cherrypicking in a job function that they can excel in; etc. None of these helps your organization to become better.
Third, it encourages employees to leave. Good employees. Employees that passed your interview process. Employees that are exceeding the objective metrics, but don't rank at the right of the curve. They know they can choose a different company with lower hiring standards and at least perform at the top. If you are really hiring only the best, then this person is among the best, and they will be hard to replace.
Fourth, this system encourages sucking up. By definition, it is an entirely subjective measurement. As a manager, you are likely to be persuaded by those who have perfected the art of sucking up and give them better evaluations. You might do this without even realizing it.
So, what should you do about it?
Well, if you are empowered to do something about it, I think you should avoid doing it altogether. Evaluate your employees based on an objective scale. Period. Hire great people, expect greatness from them, and then stop doing dumb things that encourage them to not be great. Just get out of the way and revel in the greatness.
The main argument I've heard in favor of the curve is budgetary. "We budget 10% of employee salary for annual bonus. High performers get 18%-20%, low performers get 0%-2%, and the rest get from 5%-15%. The average is 10% so we meet budget." The corollary argument is that the bonuses should not be spread evenly across the team. More money for the high performers.
That's fine, but didn't you try to hire ALL high performers? If so, wouldn't you say you expect ALL of them to be in the 18%-20% range? Why not instead budget your bonus pool for the high performance amount across the board? You should still evaluate each employee's performance, but now you aren't being constrained by budget, so you can do it objectively and fairly against a published metric, the one you've been using in one-on-one's all year long. If an employee underperforms, you can still give a 2% bonus or none at all. Take the money you saved and use it next year or something.
If you aren't really empowered to do anything about it, my suggestion is to press onward anyway. Be excellent anyway. Don't let the system cause you to be non-excellent. Be a good team player. Try to surround yourself with the best people. Take the assignments you are given and do your best with them. Discuss with your manager any concerns you have about whether you are getting the opportunity to show what you've got, but move forward and do the job right even if the system doesn't reward you. I believe good things come about from good works, sooner or later. If that doesn't work, I guess you can always go work for someone else who's a bit more reasonable.
You can also blog about it.
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.
Guest Post: How to Neglect a Product to Death
By: Dan Reese
My friend and former co-worker Matt Ryan recently commented on the impending death of Novell Forge. A message on the Novell Forge site confirms that Novell will be shutting things down soon. I can corroborate some of Matt's story as I was on the Forge team for about a year during its heyday.
But what really interests me about the situation are the implied instructions on how to neglect a successful product into a slow death that can be blamed on the product itself.
- Avoid rewarding or recognizing any of the people involved. Even better, reward someone else.
- Do not feed its success. Withhold funding, staffing and career growth opportunities.
- Provide poor support. Delay fixing problems.
- Set unrealistic goals and expectations. Blame the product or team for failure.
- Find excuses to kill the project. Focus on the negative in all meetings with executives.
This was a particular worry at Mozy when it was acquired by EMC. They promised that EMC did not want to be the lumbering elephant that accidentally squashed its shiny new purchase. And it was true. But we worried about accidental squashing anyway.
It has been two years, and I have seen projects and executives come and go. Though I do not believe it was intentional, at times it felt like Mozy was being neglected. But the core of Mozy has remained strong and continues to grow.
Based on my experience, here is what to do to keep a successful product moving forward:
- Execute anyway. Deliver a quality product in the face of neglect.
There is precious little a neglected production team can do other than produce. I heard something once I have always remembered: nothing succeeds like success. It is much harder to produce in the face of neglect, but it is also nearly impossible to ignore or argue with.
Mozy is clearly not perfect, but despite occasional neglect it continues to provides a valuable, profitable service. Working with smart people helps. Working for smart people helps. Working with people you like helps. Working on something you care about helps. Working with cool technology helps. But over time, delivering a useful, profitable product is what matters.
(This guest post is originally authored by Dan Reese and reprinted by permission. It is subject to the copyright terms at the original location.)
Interview Process Too Rigid? Ye Shall Know It By The Fruits
I don’t suppose that every company gets concerned that their hiring process is too rigid. For example, McDonald’s.
Most software companies that I know of, however, at least claim to hire only the very best, at least claim to be very selective and rigorous in their hiring process. I was fairly heavily involved in the hiring at Mozy where we had this philosophy.
When you apply a high standard to your hiring decision, I figure invariably there will be times when you wonder if you are setting your standard too high. In your attempt to select only the best, are you actually turning away good candidates that would actually do great work for you, yet failed the interview for some reason?
I know we felt this way sometimes at Mozy. We’re asking ourselves this question now also, at Microsoft’s Utah site. Not real seriously, mind you, but I think it is only natural to take a critical look at your interview process from time to time to see if it is really helping you select the people you want.
So how do you know whether your process is too strict? As my boss and I tossed this around today, I suggested that perhaps you can measure it by evaluating the team you currently have.
Suppose you have a team of eight people. Knowing what you now know about each member of your team, would you still choose to hire them? Or are there one or two in the team that you wouldn’t choose to hire again?
I suggest that if you find yourself in this situation, perhaps this is the best indicator of all about the strength of your interview process – namely, that you might need to strengthen your process a bit. You’ve got some great information on how to do this, also. What changes, if you’d had them in your interview processes back in the day, would have filtered out the employees you wish you didn’t have? Maybe those changes are some candidates for your modified interview process.
On the other hand, sometimes you might look across your team and feel like you have strength in every position, and if given the opportunity, you’d rehire every person on the team in a heartbeat. Wouldn’t this seem to indicate that your process is working? I’d argue it is.
Today you might find yourself worried that your process is so strict that you are turning good talent away. But you might have done that in your last hiring round. Yet you ended up with a solid team, strong at every position. That’s a great situation to be in, and there’s not much need to fix what seems to be working.
