I. M. Wright’s “Hard Code”

Evil assumptions

ericbrec — Wed, 01 May 2013 06:00:00 GMT

You work on big, important projects that involve many moving parts and many different teams. You work hard to deliver your piece on time and with high quality. No one can claim that you’re the one who held things up. No, it’s always those clueless, slow, self-centered, self-righteous, uncooperative, bureaucratic, unresponsive, opaque, evasive, reckless, late, unaccountable, passive-aggressive jackasses you depend upon who slip the schedule and screw up the project.

Why are evil people still employed when they constantly cause calamities? I mean, who hires these scoundrels? How do they keep their jobs? The workplace seems to be full of them. You can’t get through a meeting without idiocy exposed. What is going on?

There are two possibilities: the world is an evil place with evil people out to sabotage your work, or miscommunication and misunderstandings are rampant. Which one is it? Obviously, misunderstandings are rampant, but I’ll bet you thought long and hard about assuming evil.

The bright side of life

Does evil exist in the world? Of course it does. Psychopathy is a well-documented condition, and objectification of others based on prejudice and ignorance is as old as society itself. However, it’s a stretch to say that evil explains common collaboration concerns.

What about stupidity and selfishness—surely they explain the bulk of irrational interpersonal interactions? Certainly people can be stupid and self-serving. However, the Microsoft hiring process screens primarily for intellect, capability, and passion. While coworkers may say and do stupid or selfish things at times, those people aren’t likely to be truly stupid and selfish. Ignorant and misinformed are far more probable explanations.

Eric Aside

You could assume coworkers are evil or dumb anyway. It certainly would make you feel superior. You’d also feel triumphant when you manage to complete your work alone. However, a short-term solo gain is almost always vastly exceeded by the broad impact of a winning collaboration.

Do the right thing

Time to look in the mirror. How long has it been since you did or said something stupid? Days? Hours? Minutes? Yeah, we’re all quite capable of cluelessness.

Do you care about making a difference in people’s lives, delivering great products and experiences that change the world? Yeah, you probably do, and so do your imperfect coworkers.

The point is that the people you work with are smart and try to do the right thing—just like you. The trick isn’t to avoid or work around them. The trick is to understand their perspective and help them understand yours. Then you can be smart and do the right thing together.

Eric Aside

I discuss dealing with difficult dudes in You're no bargain either. And yes, gals can be dudes.

Failure to communicate

When a partner team is late, ask about the problem—with curiosity. Instead of assuming the team members are evil, assume they have real problems and tradeoffs, just like you. Seek to understand what’s happening, and try to learn from it.

If a partner team’s priorities don’t match your own, recognize what’s driving their team’s priorities, and then discuss the ways in which yours are different and why. Appreciate differences in expectations about quality, timelines, milestones, and commitment. There isn’t one right answer—work out the right middle ground together.

Eric Aside

I talk about strong communication in “You talking to me?” (chapter 8). I cover negotiation and dealing with dependencies in “My way or the highway” (chapter 8) and You can depend on me.

On the same page

Once people have a common understanding of each other, they work far better together. Even when people agree to disagree or decide to work apart, the agreement is made with appreciation and respect.

So next time people sound dumb or uncooperative, don’t assume the worst. Instead, assume either you or they are misinformed or have misunderstood. Ask questions with real curiosity. Shed light on what’s different or missing. Come to a shared viewpoint, and then move forward together. If you think the best of others, they may even think the best of you.

Eric Aside

You might think this column evokes Hanlon’s Razor, “Never attribute to malice that which is adequately explained by stupidity.” However, as I mention earlier, stupidity is also not the common cause. The real culprit is usually misunderstanding.

A more detailed and apropos analysis can be found in the fifth habit of Stephen Covey’s The 7 Habits of Highly Effective People, “Seek first to understand, then to be understood.”

You can't have it all

ericbrec — Mon, 01 Apr 2013 06:00:00 GMT

There are two executive planning strategies: go for it all (cut later), and do a few things well (add later). Executives follow the strategy that best reflects their belief system. They use that planning strategy to drive work throughout the product cycle.

Executives who go for it all believe their staffs produce the most when they are under pressure and overloaded. “Expect little and you’ll get little,” would be their motto. Thus, they expect the impossible and are often rewarded for it. Their staffs work incredibly hard, frequently ending the product cycle with a prolonged engineering “death march.” They show their pride during raucous ship parties, at which they boldly proclaim, “They said it couldn’t be done, but here we are!” Everyone cheers and then regroups.

Executives who do a few things well believe the best quality and customer experience are the result of delivering a few critical scenarios seamlessly and brilliantly. They provide their staffs with focus—setting the expectation that the key scenarios must sing and that everything else is extra credit. Their staffs work at sustainable levels, but rally around integration periods, blocking issues, and exciting innovation extras. Their ship parties are less raucous, but show no less a source of pride in the remarkable experiences delivered.

Clearly, the executives who go for it all are getting more work out of their staffs and more alcohol at their ship parties. That’s better, right? Wrong. The executives who do a few things well may not work their staffs as hard, but they actually ship more high-quality features on time that result in a better customer experience. Why? Because you can’t have it all.

Eric Aside

I’ve heard go-for-it executives use the “Art of War” to justify putting their people through hell. “Throw your soldiers into positions whence there is no escape.… If they will face death, there is nothing they may not achieve.” People who’ve read Sun Tzu carefully know that this is a tactic of last resort for when you are cornered. The preferred approach is to set yourself up for success in advance. “Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”

What’s the matter here?

It’s been proven over and over again that an engineering staff that does a few things well produces more features with higher quality than an engineering staff that goes for it all—even if the go-for-it staff works extreme amounts of overtime and slips its schedule (which staffs like this usually do). How can that be? The math seems wrong, unless you remember to subtract.

The go-for-it staff starts work on many more features than the few-things-well staff. However, software development isn’t an assembly line with predictable timing. It’s a learning process, discovering issues along the way. The few-things-well staff is aligned on features, swarming to solve issues as they arise. The go-for-it staff is charging ahead at breakneck speed without clear priorities, so issues fester and eventually cause features to collapse. Features are left incomplete, inconsistent, or cut.

To customers, incomplete, inconsistent, and cut features don’t count. As far as they’re concerned, that work never happened. Thus, all the time spent on them gets subtracted from the tally of time worked. What’s even worse, all those incomplete, inconsistent, and cut features create work for end-to-end testing, usability, user-research, integration testing, design, localization, security, and a host of other supporting teams. That time gets subtracted too.

The end game for go-for-it teams is typically a death march (often prolonged), a horror that I cover in detail in “Marching to death” (chapter 1). During death marches, people don’t have much time to think. They come up with quick patches that often regress and are poorly designed. The result is significant bug counts and significant rework. That rework time also gets subtracted from the staff total, as well as the supporting staff total.

Of course, the few-things-well staff also ends up cutting features and doing rework, just far less. People are focused and aligned with clear priorities, so what’s planned to ship typically does. They also have more time to think during the end game, so designs and fixes are better, resulting in less rework. The net tally of time worked minus time wasted puts the few-things-well staff well ahead and better positioned to adjust to changing requirements and markets.

Well, how did I get here?

If the strategy is always worse, why would an executive ever choose to go for it all? I think there are a few reasons.

Going for it all does work. I never said it didn’t. I only said doing a few things well works far better.
Going for it all is more macho. Microsoft still has a hero culture. Why be a wimp and do a few things well, when you can be a hero and go for it all? The answer: It takes an entire team to build a product, not just a few heroes. Just because you code your piece doesn’t mean the feature ships and is used by customers.
Going for it all defers making tough tradeoffs. Who knows what customers will really like? Careful planning is hard and risks making the wrong choices. If you work on everything, you can delay making decisions about what matters most. Fractures in the engineering process will usually decide for you.
Going for it all gives the appearance of productivity. Everyone is super busy on a go-for-it team. The fact that much of that time is wasted isn’t apparent until the end, when you can never get the time back.
Going for it all creates commitment. The more trouble you go through to achieve something, the more value you ascribe to it. This is how fraternities and military units create attachment. Anyone who makes it through “hell week” or basic training will be deeply committed to the group. Going for it all commits the staff to the end. Alternatively, doing a few things well relies more on respect and trust.

While I can easily understand why executives choose to go for it all, I have greater respect and trust for those who choose to do a few things well.

Eric Aside

Our hero culture also leads to poor work-life balance, attrition, and sometimes divorce and health issues. Being committed to shipping a great experience on time is fantastic, but it can be done without sacrificing clear thinking and a balanced life.

I just can’t get enough

I can hear naysayers saying, “But what if I want my team to deliver more than a few things?” No one said you had to stop at a few things, only that those few things were the top priority and must be delivered with quality and on time.

We hire great engineers. They want to excel. They want to overachieve. They will attack the few key things and complete them on time if it means they can then add more innovative features and experiences. They’ll also find ways to make those few things really shine and surprise. It’s amazing what creative and motivated people can do.

Naturally, adding more features is risky, just as when you go for it all. However, when you do a few things well, the extra features aren’t critical. You can cut them without compromising critical deliverables and initiating a death march. That lack of pressure creates space to think, design, and deliver solid enhancements instead of panicked patches.

So, did your team meet expectations by delivering a few things well, or did they exceed expectations by making those experiences pop and adding even more value on top? People take pride in their work. Trust them to exceed.

Eric Aside

I also covered this question in “Continued contention over dev schedules” (chapter 1).

Weird science

“But what about breakthroughs in natural user interface, search, or other research areas? Those are 99% perspiration.” Yes, engineering is hard. This is not news. If your development plan includes new technologies, you’ll want to do tons of prototyping and iteration. You’ll want to measure and track your progress and have realistic goals. You’ll want to fail fast and call it when your work is good enough.

Knowing when your work is good enough is like doing a few things well. You plan for it. You achieve the seamless compelling experience, and then you try to do even better. If even better isn’t achievable, at least you’re still delivering value that customers can appreciate.

I’ll drink to that

As a manager, lead, or individual contributor, how do you handle working for an executive who chooses to go for it all? Set priorities for yourself and your team, and gather “air cover.”

Your priorities should be based on the business and customer. Confer with your manager, colleagues, and team, and then make the call. Use those priorities along with lean software development methods to complete the most important and urgent work first. That will keep you a step ahead of the cuts.
Your “air cover” is gained by being transparent about your priorities with your manager. You’re not revolting against your executive. You’re prioritizing your work in a way that mitigates risk and drives quality and predictability. Everyone likes that—even macho types.

Of course, you’ll want to get credit for being productive with high quality—you don’t want to be upstaged by careless cowboys. So report your completed feature counts and remaining bug counts regularly. Happily help cowboys clean up their messes and get credit for that too, or work on additional features while everyone else is scrambling. It’s tempting to be self-righteous about your superior productivity and quality, but being humble and helpful, while regularly reporting results, will get you much farther.

Regardless of which planning strategy your executive chooses, what matters is delivering high-quality, innovative, and compelling experiences to our customers. You can achieve that for yourself and your team by always doing a few things well at any given time. While ideally the entire organization is aligned with that approach, we each play an important role in bringing our customers true value they can appreciate. I’ll raise a glass to that every time.

Fixing five fundamental flaws

ericbrec — Fri, 01 Mar 2013 07:00:00 GMT

After decades as a professional software engineer, working for six different firms (large and small), I can honestly say that Microsoft is by far the best. I can also honestly say that Microsoft is far from perfect.

My monthly rants typically focus on problems that individual engineers or managers can change by being better individual engineers and managers, by using different approaches or tools, or by altering the way they think about issues. However, Microsoft also has system-wide issues. I know how to solve them, but Microsoft executives and engineers may not like my solutions.

Too bad. I’m throwing my ideas out there this month. Don’t like them? Come up with something better. No company is perfect, but we owe it to ourselves to never be satisfied with the status quo.

Eric Aside

All opinions expressed in this column (and every Hard Code column) are my own and do not represent Microsoft in any official or unofficial capacity.

There is something terribly wrong

What’s wrong with Microsoft? I’ve narrowed it down to five fundamental flaws.

We’re top-heavy. We’ve up-leveled lead and group manager roles. Nearly 80 percent of development leads have been at Microsoft for six years or more, with roughly 50 percent here for 10 years or more. This up-leveling clogs career advancement, reduces the influx of new thinking, and drives the use of outdated practices. Up-leveling was supposed to deliver better and fewer managers, but opportunities for growth and innovation need to balance that goal.
We’re overstaffed and overfunded. Having lots of engineers and money enables Microsoft to accomplish big, bold breakthroughs. It also enables Microsoft to isolate divisions, duplicate infrastructure and services, fail slowly, and generally throw money and people at problems instead of thinking and simplifying.
Our reward system fails. The time we spend debating and marginally improving the review system is only exceeded by the time we spend in calibration, assessment, and the rest of the review process. Even so, we insult and drive away people we value, and we don’t promote people promptly when they are demonstrably ready.
We disregard previous experience. Microsoft culture places little value on what you’ve done before—the value is in what you’ll do next. That’s really nice in theory, but in practice we ignore skills developed previously, don’t build upon gained knowledge, and repeat past mistakes. This destroys industry hires, slows innovation, stifles reuse, lowers productivity due to constant restarts, and demoralizes the engineering staff.
We replicate infrastructure. Divisions, and often individual teams, reinvent their own build systems, deployment systems, test systems, localization procedures, monitoring, and engineering analytics. We end up with wasted effort, poor systems, and difficulty working across teams that use different tools and methods.

A great Microsoft cultural edict is, “No whining. Accept it and move on, or come up with a better solution.” Let’s talk about why these five issues exist and what can be done about them.

Why? Why?

Being top-heavy is partially a result of being a successful, mature company. People move up, plateau eventually, and stay put. The company isn’t doubling its staff anymore, so the percentage of new blood declines. To fix this, we must grow much faster or make room somehow (org design or attrition).

Being overstaffed and overfunded is a direct result of success. We could trim, but that’s painful. We could change, but that’s hard and scary. The solution is to trim and change anyway.

Our reward system pays for individual performance based on a curve, and not everyone will be happy. The steady performers have trouble being promoted because they don’t stand out. Those who stumble get a disproportionate punishment. Even those who do a great job keeping up with their peers feel jilted by an average review. Only those who receive a well-deserved promotion (or expulsion) feel a sense of fairness. The solution is staring at us—it’s so obvious that it’s easy to dismiss (more below).

We disregard previous experience because, at first, it wasn’t important. All that mattered in Microsoft’s early days was “Can you code all day and night, loving every minute of it?” Now history matters. We’re in an established industry, with legacy codebases, huge projects, and billions on the line. We should still focus on the future, but we should also place people in roles where their past experience is most beneficial.

We replicate infrastructure when we don’t have a supported solution to turn to that operates well at the large scale of Microsoft projects. We do share Source Depot, Active Directory, Product Studio, SharePoint, Office, Exchange, and Windows Server. These are commercial products we build and use ourselves or internal products (not tools—products) that were designed and intended to be shared (though internal products don’t get as much love). Build systems, deployment systems, test systems, localization procedures, monitoring, and engineering analytics will need to be well-supported and scalable products if we hope to share them.

Eric Aside

Source Depot is our internal source control system. Product Studio is our internal bug tracking system.

You got a better idea?

What should we do? Let’s start with people issues. Please keep in mind, I speak for no one but myself.

At the start of every major product cycle, like a new major revision of Office, high-level planning already focuses on direction, key scenarios, and tenets. Part of that planning should also specify the number and kind of engineering triads needed based on what the high-level plan specifically requires—not based on current staffing.

There aren’t that many types of triads in engineering: UI (heavy on designers, light on architects), kernel (heavy on architects, light on designers), and midlayer (average number of architects, some API design). These triads come in small, medium, and large sizes. Thus, staff planning comes down to selecting the number and size of each type of triad necessary to build the product planned.

To break down each triad type, we can use statistical values from our people data to determine the small, medium, and large makeup (how many in each discipline and level band). Microsoft is big enough to give us a valid sample size. These breakdowns should be reviewed as a sanity check and also to balance growth and new hires.

Eric Aside

I did this triad breakdown exercise six years ago. It only took a day or two, and the data wasn’t that surprising or diverse (most triads of the same kind were roughly the same size). The biggest variances were in sustained engineering teams, due to basic differences in approach.

I’m focused on engineering product group triads in this column, but the same staff planning approach can be used in sales, finance, HR, consulting, operations, and anywhere else in a large, mature company like ours.

I've got a job to do

The next step is to place people into the key leadership roles, both individual contributors and managers. New triads need leaders that are good at building teams. People and architectural turnaround cases require leaders who’ve revamped teams before. There may be special technology requirements too.

To find the right leaders for these roles, midyear career discussion can include identifying skillsets (validated by managers) that are later used to place people. These key leaders are told why they were chosen to take their specific roles—making it clear that their special skillsets are valued and needed.

Once the key leaders have been placed, the teams can be built from existing and new staff. While many folks will continue to fit well in their current areas, no job is a given—everyone has a chance to change positions or look elsewhere. Internal candidates can’t fill entry-level-hire spots. Higher-level people can’t fill lower-level roles. However, people can get promoted into positions if they are ready. Those who can’t find a role that fits are given a few months to find a position elsewhere at the company or accept a severance package.

A variation of the solution I describe above has been used in large part by Office and Windows for years. I’ve added recording skillsets during midyear career discussion, emphasizing people’s past experience, preventing higher-level people from filling lower-level roles (avoids job inflation), and enforcing layoffs of extra people. My plan is harsh, but it ensures that we get balanced, smaller, and more efficient based on the people we need in order to build our software.

Eric Aside

You might be worried about losing high-potential employees during this process. Chances are good that they’d find positions during org shuffles, but we could use HR’s existing tracking of high-potential employees to catch any unfortunate exceptions. Those exceptions could be put on special projects until new positions open elsewhere at the company.

You also might be worried about staffing shifts to handle unforeseen issues or opportunities. Those plan changes happen all the time today. The purpose of high-level planning isn’t to create a perfect, immutable plan; it’s to think ahead about what you really want to achieve and how you’d like to achieve it, including how to best staff the project.

Just rewards

As for the review curve, we kill it. Period. Microsoft has slathered lipstick on our pig of a review model three different times (adding lip gloss tweaks annually). It doesn’t work—the review curve is still a pig.

Instead, we should replace the annual review with a second career discussion. Outrageous and unacceptable, right? Wrong. The three states of employee performance—doing well, moving up, and moving out—can all be addressed in a career discussion:

We already focus on moving out poor performers. Career discussions and one-on-ones with managers let people know in advance when they are falling behind. While people can be (and are) dismissed at any time, retaining only the employees we need to build each major revision of our software keeps everyone honest about who is meeting or exceeding expectations.
Today it takes too long to move people up, and we lose many as a result. Instead, we can focus semiannual career discussions and calibrations on promotions (and problems). We can design our triads to have an appropriate number of positions at each level, and we can reject candidates above the target level to prevent job inflation. We can make room for promotions at the desired rate and promote proven people promptly. That’s what they want—it’s the ultimate pay for performance.
Everyone else is performing well, working in roles we determined are essential for shipping our products and services. They all get paid the same generous salaries, taking into account their level and current market compensation. We can even give bonuses based on division results, encouraging collaboration and focusing on collective success.

In other words, we make the review system about growth, effectively filling essential roles, and promotions. A forced, abstract, insulting curve has no place in the system.

Eat it. EAT IT. Eat it.

Fixing the final fundamental flaw of Microsoft, replicating infrastructure, is just as obvious as the review system fix. We need our internal build systems, deployment systems, test systems, localization procedures, monitoring, and engineering analytics to be supported and scalable products (preferably commercial products that get proper attention).

There are a few different ways to make our internal systems commercial products.

We could take our existing internal systems and productize them. This strategy isn’t likely to work because the systems weren’t designed for commercial use. They are effective, but often fragile, difficult to maintain, poorly documented, and tightly coupled to individual division business practices. Plus, every division has its own.
We could use existing commercial products (including open source) to replace our internal systems. This strategy isn’t likely to work either. Microsoft produces many of the largest and most complex software products in the world. Handling that scale and complexity is beyond the capacity of commercially available engineering systems that cover the full software lifecycle.
We could exclusively use our existing commercial products—Azure, Visual Studio, and Team Foundation Server—for our own infrastructure. At Microsoft, we call using our own products “eating our own dog food,” or “dogfood” for short. We dogfood all our products except build systems, deployment systems, test systems, localization procedures, monitoring, and engineering analytics. Clearly, it’s time we start dogfooding these as well.

Many Microsoft teams do use Azure, Visual Studio, and Team Foundation Server for their infrastructure, but not exclusively. The build, deployment, test, localization, monitoring, and engineering analytics in these products are still relatively young. It would be painful to switch to them before they fully mature, and most of our customers don’t operate at Microsoft’s scale.

But it was painful to switch to Exchange. It was taxing to switch to Windows Server, SharePoint, Outlook, and Active Directory. It’s always unpleasant—that’s why we call it dogfood. However, going through that pain has led to successful products that scale to meet the demands of any enterprise. Scaling Visual Studio and Team Foundation Server to build Windows, or scaling Azure to deploy, monitor, and operate Bing, won’t happen overnight. However, right now that’s not even our stated goal. It’s time Microsoft made the commitment to dogfood Azure, Visual Studio, and Team Foundation Server.

Eric Aside

Wonder what it would take potentially to re-architect Azure, Visual Studio, and Team Foundation Server so that they scale to the largest workloads? Look no further than the dozens of full-scale teams that design, develop, operate, and maintain each division’s solutions today. Don’t think it’s worth it? Look again.

Tough love

I love Microsoft, but we’re getting top-heavy, overstaffed, and inefficient. Our review system is broken, past experience is disregarded, and money and effort are wasted on incongruent infrastructure.

We can fix these flaws. It’s not that complicated, and it’s not that radical. We can switch from a seemingly arbitrary and insulting curve to a thoughtful people plan. We can switch from division-specific “not invented here” to our own proudly invented and used superstructure.

Don’t like my solutions? Write to me and suggest something better. Wish my ideas were implemented? Use your network within Microsoft to spread them around. Transformation starts with people like us.

It will take time. It will be painful. It will be difficult. But when has Microsoft shied away from a challenge? We have a chance to be the first technology company to remain a market leader from the birth of an industry through to its full maturity. Ford couldn’t do it. Phillips and RCA couldn’t do it. IBM couldn’t do it. Apple is getting there. Microsoft can do it. Let’s beat the odds and make changes that will keep us on top for generations to come.

Is it important?

ericbrec — Fri, 01 Feb 2013 07:00:00 GMT

We’re getting into the midyear career discussion period at Microsoft. People do appreciate a career discussion with their manager, but most folks have another topic on their mind—how am I doing? Look, it’s not a mystery—you should already know. If you don’t know, you’re clueless about more than just your performance. Six months from now, that could be a problem.

“Hey, that’s not fair!” say the clueless. “My reviews are truly random. I work hard all year, every year, yet my review score is like a slot machine.” Oh please—wake up! How you’re evaluated isn’t complicated or random, but understanding your review score does require you to occasionally unglue your eyes from your screen, take a step back, and evaluate your actual situation.

How do you (and your manager) evaluate your efforts? By considering four attributes of your work: is it level-appropriate, high quality, plentiful, and important? The trick is to understand how those attributes are defined at your current career stage and within your current team. Don’t know? I’ll define them for you, with special attention paid to the one that’s most important.

The secret to my success

Let’s quickly define each of the four attributes of your work.

Level-appropriate. Work that’s commensurate with peers at your level. Is your work of equivalent scope, complexity, and independence? (Remember, you are judged relative to your division peers.) As you grow, what’s considered level-appropriate work changes. That’s why you don’t get the same review for the same work after a promotion.
High quality. Work that meets the expectations of your leadership team. Quality is not an absolute. Ask. Observe. Adjust. Don’t let pride in perfection prevent your progress. And remember, quality is not just about your outcomes—it’s also about how you achieve them (efficiently, collaboratively).
Plentiful. Work that showcases three to five memorable accomplishments. More than that may cause you to lose focus, delivering mediocre instead of memorable results. Less than that shows a less complete and consistent effort. You want the five minutes that your management focuses on you during calibration meetings to be compelling—three to five big contributions, backed by lots of little day-to-day stuff. What’s critical is the nature of those three to five big accomplishments, which leads us to the last and most significant attribute.
Important. What qualifies work as important? Ay, there’s the rub.

Eric Aside

For more on those five minutes in calibration, read Out of calibration.

Who moved my cheese?

Definitions of the first three attributes that characterize your work are clear to most people if they are honest with themselves and notice how their co-workers behave. It’s the fourth attribute that people struggle to understand—what work is important?

Clearly, the customer and the business are what’s important. However, most engineers think about customers and business concerns at a fairly concrete and detailed level. When you’re talking about just three to five big things for a whole year, you need to understand importance at a much higher level of abstraction.

It’s easy to tell what’s not important. Canceled projects and cut features aren’t as important. Bragging about your great work that never shipped doesn’t get you very far. You want to distinguish importance before your project or feature is cut.

Who cancels projects? Who cuts features? Management does. Individual contributors influence those decisions and often make the recommendations, but it’s typically people in the management chain that make the final call. Thus, your management chain determines what’s important. Unfortunately, management often provides confusing and even contradictory messages, and its priorities often change. To determine what’s important, you must understand the two buckets of work.

Eric Aside

If you are in the principal or partner band, being part of a canceled project is a real concern. After all, you were probably accountable for that entire project. If you are in the senior band or below, it’s not as much of a concern since your work relates to parts of the larger whole. If those parts were done well and were important pieces, then the only impact of the cancellation on you may be having to join a new team.

Just the two of us

There are two buckets of substantial work: work that’s critical to the business and self-indulgent “pet” projects.

Work that’s critical to the business is what your division’s leadership talks about at group meetings and describes in vision documents and planning memos. Work that’s directly derived from the disseminated direction for your division is clearly important. No one doubts its importance to the division since everyone got the same message. This work includes core systems like build, deployment, and setup—the pieces necessary to deliver the goods (not sexy, but essential).
The substantial work that’s left over is made up of pet projects (including pet features). The pet projects could be your own, your manager’s, your friend’s, your director’s, or even something requested by your division president. The key difference between pet projects and work in support of broadly stated business direction is that pet projects aren’t acknowledged as being business critical. In other words, different people may view their importance quite differently.

Sure, there’s also day-to-day busy work, mostly consisting of email and small requests, but you don’t want that work overwhelming your more substantial work.

Eric Aside

For more on managing email, read Your World. Easier.

You can go with this or you can go with that

It might seem obvious to focus your work on three to five big projects from the first bucket. After all, wouldn’t you want them all to be business critical? However, it’s easy to be fooled, you do want to keep your management (and yourself) happy, and sometimes real game changers come from pet projects.

How do you find the right balance of work?

Read the vision documents and planning memos. Attend the big group meetings where executives talk about direction and priorities. Understand what leadership thinks is important.
Keep a critical eye open. Sometimes people masquerade pet projects as being business critical. Ask questions about how the work relates to the vision document or planning memo. You might still choose to do the project, but you should do so knowingly.
Consider your current career situation and how much risk it can bear. For example, if you just got promoted, you can take more risk. If you’re pining for a promotion, you can’t afford as much risk. Business-critical projects are less risky.
Honestly evaluate who’d be happy if you did a pet project. If it’s the president’s pet project and you think you can pull it off, why not go for it? If it’s your own pet project, perhaps you should hedge with a few business critical projects as well. If it’s somewhere in between, consider the risk and reward and act accordingly.
Don’t rely solely on pet projects or features. They often get cut or canceled.
If you’re ever in a pinch and need some business-critical projects to balance your risk, you can always grab some needed core-system work (build, deployment, or setup). Most folks hate that work, yet those improvements are force multipliers with broad and critical impact to the business.

Eric Aside

How do you get appropriate visibility and credit for doing mundane, yet essential, core-system work (build, deployment, or setup)? There are two ways—either one works.

People don’t typically work on core systems unless an improvement is vital. So, measure the current state before you start (if builds are taking too long, measure the build time), perform the improvement, measure the improved state (the shorter build time), then send mail to everyone announcing the improvement and its impact.
Widen your perspective and make improvements to core systems that surprise people. Office 2013 did this recently with its dramatically shortened setup time. Nothing tells a better story than taking something folks think is mundane and shocking them with its newfound sexiness.

Doing it well

How are you doing? Well, if you are working on projects with the same scope and complexity as your level peers, and you’re meeting your team’s expectations of quality work (both what and how), and you complete at least three to five big tasks that are important to the business, then you are doing very well!

Just don’t kid yourself about what’s actually level-appropriate, what’s actually expected in terms of quality, and what’s actually important to the business. And don’t think that you can make up for undervalued work by doing it in larger quantities. Take the work you’re given (or better yet, the work you propose or select), and focus on doing a few business- critical tasks well with high quality.

It’s still worth regularly asking your manager for feedback on your performance, but her answer shouldn’t surprise you. People, even managers, think in stories. The story of your performance should be clear, concise, and compelling. It should illuminate the dramatic difference you are making for our business and our customers. It should be a story you, and your manager, are proud to tell.

Taking over

ericbrec — Tue, 01 Jan 2013 07:00:00 GMT

There are many books and lecture series about creating high-performing teams that work well together, work hard for each other, and produce tremendous results. That’s nice. In real life, you, the manager, don’t get to create high-performing teams. You inherit low- to average-performing teams and are expected to transform them while delivering everything your predecessors overpromised without slipping the schedule. Yeah, good luck with that.

In fairyland, you’re granted a compelling charter, plenty of headcount, and a reasonable timeline to build a cohesive team of strong talent. Back on earth, you’re hired to manage an existing team with an existing charter and a boatload of existing issues. After all, if everything were perfect, the management position wouldn’t be open.

How do you transform an existing team without seeming like the flavor of the month? How do you build identity, trust, and camaraderie when you appear to be a hulking, hideous, hairball of change? How do you maintain momentum and ship on schedule while swapping out charters, people, and approaches as you go? Read on—this is going to be fun.

What’s going on?

There are two types of elite sports coaches: the ones with an innovative system that they foist onto whoever their players are, and the ones that develop an innovative system based on the players that they have that season. Both types can be competitive at an elite level, but it’s the coaches who adapt their systems to their talent that consistently win championships. The same is true for managers.

Your first step as a new manager of an existing team is to learn who you have and what their strengths and weaknesses are. How do you do this when everyone expects you to lead the moment you arrive?

Talk to your boss, peers, and team members about your new team before you start. What are the concerns and hopes? What are some short-term wins and long-term expectations? It’s the same approach I described in The new guy, but in the context of a whole team, not just your role. Before you can effectively makes changes, you must first listen and understand the current situation.
Bring your new team members together and introduce them to who you are, what’s important to you, and how you view the success of the team. The key concerns of anyone with a new boss are “Who is she?” “How do I avoid pissing her off?” and “Can I succeed on her team?” By providing your background (just facts, no hubris), your management philosophy (short and sweet), and your vision of success, you answer these questions immediately.
Reassure your team members that nothing is changing immediately or without their input. Change is the last big concern your team will have. By telling your team to continue doing what they’re doing, everyone feels reassured. By telling team members that they’ll be consulted, they’ll feel respected and acknowledged—the building blocks of trust. Sure, you’ll probably make changes eventually, but first you must learn what you have.

Eric Aside

Here’s how I describe my expectations when I take on a new team:

Meet your commitments (the daily ones).
Never compromise the quality bar. (This implies we have one.)
Win as a team (no cowboys or cowgirls).
Love your customers and partners. (We can’t succeed without them.)
Attend team meetings and one-on-ones.
Do a few things well.
Deliver bad news early. (I save this one for last so I can spend time emphasizing it.)

Who are we and why are we here?

For your team members to function as a team, they must know who they are and why they are here. As soon as you’ve spoken to enough people to understand the team dynamics, it’s time to establish your new team’s identity and aspirations. Ideally, you’d introduce these at that first team meeting. However, often you need to brainstorm your vision and mission as a team or leadership triad after you’ve already joined it.

Your vision is a short description of how the future will be when your team is successful (“landing a man on the moon and returning him safely to the earth”). Your team will likely only play a role in achieving that vision. That role is described in your team’s mission (“develop alternate liquid and solid fuel boosters”). Your vision and mission help your team members prioritize, make decisions, and get themselves out of bed each morning excited to make progress.

While your team’s vision and mission provide the team’s objectives and help define its identity, you also need more tangible ways to reinforce a sense of team. Regular team meetings and morale events are easy and essential for this purpose (read One to one and many to many). You can also decorate your space, and even occasionally your people, with symbols of the team’s identity. Don’t just get t-shirts—assign a special day or morale event when everyone wears the same shirt. Put banners on the walls. Select fun team names. Celebrate being a unit that succeeds together and looks out for each other.

Who do we have?

The next aspects of your new team to examine are:

The people and organizational structure
The approach and toolset
The current and planned work

There is no right order to review these—it depends on where the team is struggling most. Remember, your boss and overall group unreasonably expect immediate results, so go for the most impactful and quick wins first. For now, let’s start with people and org structure.

Once you’ve had a chance to talk one-on-one with all your team members (at least your direct reports and your skip-level reports, if any) and ask them about their current challenges, it will be obvious if there are personnel issues. People usually aren’t shy with the new guy.

If the people situation is of primary concern on the team, act quickly. Don’t kid yourself if someone clearly isn’t a fit. You’ll find that the easiest time to deliver tough messages is during your first few months on the job (no strong ties yet, fewer hard feelings).

However, personality and performance issues aren’t usually the dominant people concerns. The more common problem is not having the right people to achieve your mission. Sometimes you have too many thinkers and not enough doers. Sometimes it’s the opposite. Sometimes your org structure isn’t matched to your mission. Once you understand who you have and what you are trying to accomplish, it’s much easier to slot the right people into the right places (including onto other teams), and then write job descriptions for the roles that are vacant.

Eric Aside

If you were promoted from within your team into your leadership role, it may become difficult to deal with your former peers as their manager. The biggest help I’ve found is clearly differentiating your roles as you’re talking: “As your peer, I’d say …, but as your manager I’d say ….” That way, you remind people that you’re the same person, but now have a different role.

What are we doing?

Often the biggest issues involve your team’s approach and toolset. You’ve got good people targeting the right work, but they are dysfunctional and inefficient. People are fixing issues or fighting fires instead of innovating and enhancing products. When they are working on features, there is too much talking and meeting and not enough doing. The tools don’t help, or actually make things worse, by treating symptoms instead of addressing the root cause. Ugh.

To address these issues, focus your team on three things:

Define “done.” Ensure your team knows what “done” means. No shortcuts. Have a realistic quality bar and stick to it. It’s your best means to corral the cowboys and cowgirls and reward doing things correctly.
Think. Expect your team to prioritize, perform root cause analysis, and constantly improve. (One of the reasons why folks like Scrum and Kanban is that they enforce this behavior.) Expect team members to discuss their designs and design changes in advance—proceeding with confidence instead of reckless abandon. Sure, reckless abandon is fun and romantic, but that’s for prototyping time, not the production implementation. Most importantly, give your team time to think by building a schedule based on past success, not fantasy.
Shorten cycle time. The less time it takes your team to go from feature spec’ing to feature “done” the higher your feature quality will be, the more responsive you’ll be to customers (and plan changes), and the more productive your team will become. So, determine the length of your feature cycle, find what steps are taking too long, and fix them. Common culprits are long build times (shoot for under 30 minutes for partial builds), long test times (shoot for under 10 minutes for BVTs), too many environments (dev and prod are all you need), too many manual steps (automate everything possible), people sitting too far apart, or teams using outdated methods (instead of feature crews or other lean methods that work on one feature at a time until it’s done).

As I said in Don't be a tool, tools serve us, not the other way around. Focus on people and what they are actually trying to accomplish (delivering value to customers), and then streamline everything around that work.

Key point: People are limited in how much change they can handle. Ideally, you only change one major tool or method at a time—certainly no more than three at once. Any more than that, and people will get confused and fail. What’s worse is that they’ll associate their failure with the whole package of changes, poisoning chances for future improvement. Always go one step at a time, focusing on the area of biggest impact.

Eric Aside

For more on reducing cycle time, read Cycle time—the soothsayer of productivity. For more on reducing your environments, read There's no place like production. As for my favorite approach to software development, read Too much of a good thing? Enter Kanban.

Where are we?

The biggest issues with your new team may not involve people or approach. Your team could be focused on the wrong work or stuck chasing the emergency du jour. You need to review current and planned work.

You’ll get a sense of your team’s current work from your initial meetings with team members. If it sounds truly discombobulated, then you’ll need a quick fix. The easiest way is to focus on your customers. Bring in marketing, product planning, customer support, and/or user research, and have them discuss the customer and market at a team meeting. If you can bring in real customers too, that’s even better. Have your team write ideas for improvement areas on post-it notes during the discussion. Then brainstorm and prioritize the improvement areas with an affinity exercise. Now you’ve got a basic plan that your team helped construct.

However, a basic plan won’t give you the full picture—for that you’ll need deep dives. Schedule an hour or two to review each area your team covers. Don’t have your folks spend time preparing presentations. Instead, have your team experts describe their areas in detail at the whiteboard while you and other team members ask questions (the meetings should be open for anyone to attend, but only the experts and triad are required). Take pictures of the whiteboard and post them in the team OneNote notebook. Now you know where you are.

Where are we going?

Once you know where you are, it’s easier to discuss where you’re going. For that you need strategic planning. The problem with planning is that plans change. The problem with no planning is that you have no idea where you’re headed. A nice compromise is lightweight planning.

Have each of your teams brainstorm a list of improvement areas (based on customer information, as before). Then have the teams place those items in a table according to each improvement’s dimensions of execution and market risk. The less confidence the team has that it can ship the improvement, the further toward the top it goes. The less confidence the team has that customers will like the improvement, the further toward the right it goes. You end up with a table like this.

Items in the lower left are your core business—you know how to ship them and you know customers like them. Items in the upper right are big bets and game changers—high risk, but high potential reward. You want your plans to be balanced. Not enough focus on the core and you lose your current business; not enough risk and you lose your future business.

Schedule an hour for each area your team covers, and have folks in that area present their plan (just a filled out table). Provide feedback and discuss priorities. Then go over a combined plan with the entire team. Now you know where you’re headed with a plan that can be easily adjusted as situations change.

Eric Aside

I learned about the execution and market uncertainty strategic planning table from Ian MacMillan. You can find it in Ian MacMillan and Rita McGrath's book, The Entrepreneurial Mindset: Strategies for Continuously Creating Opportunity in an Age of Uncertainty.

Are we there yet?

That’s it. You’ve listened to your boss, peers, and team. You’ve established a team identity and aspiration. You’ve resolved people issues and aligned your org structure to your mission. Your team is using an efficient approach and productive tools. You know where you are and where you’re going. Most importantly, you’ve made these improvements by involving all your team members, building trust with you and with each other. Guess what? You’ve got a high-performing team.

Some of these team areas may have been fine from the start. Maybe you started with good people who were properly organized. Maybe they’ve been using lean methods for years. Maybe your organization’s planning was already clearly laid out for you. The key is to understand what you have, see the biggest opportunities for improvement, and then address them patiently at a rate people can handle, a step at a time.

Because you focused on your team’s biggest needs and didn’t change too much at once, your team sees the improvement and feels part of that success. You aren’t a randomizer—you’re a leader and part-time miracle worker. As a leader, it is your job to serve your team. There is no better way to serve your team than by being a thoughtful leader who listens, addresses the team’s most pressing needs, and provides a smooth transition.

Eric Aside

For the basics on being a good day-to-day manager, read “I can manage” (chapter 9).

Collaboration cache—colocation

ericbrec — Sat, 01 Dec 2012 07:00:00 GMT

Software geeks know that registers fetch data roughly 10 times faster than the L2 cache, 100 times faster than main memory, and more than a million times faster than hard drives. Smart software engineers work hard to keep all the data for their inner loops in registers or at worst the L2 cache. They keep the rest of their time-critical data in main memory, and they only go to the hard drive when absolutely necessary.

Continually fetching data from main memory or the hard drive while in the inner loop of your most time-critical functions would be madness. I mean, why would anyone in the computer industry be so breathtakingly boneheaded as to deliberately distance data for the most common critical functions? Wouldn’t you want to shake such a person and scream, “What the heck are you thinking?!?”

What is the inner loop of software development? It’s a developer writing code. Placing developers’ keyboards and screens on a different floor from their desks would be absurd. What is the next most inner loop of software development? It’s collaborating with your cross-discipline feature team (Scrum team or feature crew). Yet cross-discipline feature teams are commonly separated by long hallways and entire floors. It makes me want to shake the managers and executives who arranged such seating and scream, “What the heck are you thinking?!?”

It was the best of times

“Yeah, but I sat in a shared space once, and I couldn’t get anything done.” You are absolutely correct.

The worst place for productivity is a shared space amongst people working on unrelated feature areas. The chatter around you is noise—irrelevant, distracting, concentration-killing noise. Sitting in a closed office would be a big improvement—you’re isolated from your feature team, but at least it’s quiet.

The best place for productivity is a shared space amongst people working on the same feature area (typically three to 12 people). The talk around you is pertinent and essential—it’s the relevant information you need to avoid issues, save time, and arrive at the best design and code. That’s why after I created team rooms my development leads (who had individual closed offices) voluntarily chose to move into the team spaces—that’s where all the action was.

Eric Aside

If you have developers in a team room who need quiet to get into a flow, have them wear headphones. Establish rules around interrupting people who are wearing headphones, and have focus rooms where people can make calls, do interviews, and otherwise make noise unrelated to feature work.

As for the ideal team room setup, I let the feature teams configure their own space. It gives the teams more buy-in and lets them arrange the room to their preferences. The only essential is to restrict the space to feature team members. Even one outsider is enough to be a distraction and introduce noise instead of value.

Eight days a week

What difference does colocation of cross-discipline feature teams make to the inner loop of software development? I’ve come across many studies that indicate the benefit is substantial, but none from Microsoft. So when my group was scheduled for an office defrag a couple of years ago, I started collecting data for the six teams reporting to me. I compared the per-week average of feature work completed for the few months before the move (when people worked in offices or cubicles arranged by discipline or office availability) to the average completed for the few months after the move (when cross-discipline teams worked together in team spaces).

One of the six teams was stabilizing for a release and thus doing very little feature work. Even so, that team completed 10 percent more feature work per week on average than before the move. Three of the teams were 20–26 percent more productive than before. One team was 55 percent more productive, and the sixth team was 62 percent more productive.

So let’s recap my little experiment. The five cross-discipline teams of five to 10 people each that were actively working on feature development gained a minimum of 20 percent productivity just by sitting together. In other words, they gained an extra day of a development each week. One team got three extra days per week—and still had two days off for weekends. The teams have maintained those output levels ever since.

Eric Aside

How did one team gain three extra days per week? The members broke down their work into smaller chunks, assigned work to team members on demand instead of in advance, and used the team space to stop and gather together to solve serious design issues whenever they came up.

Tradition…tradition!

Given the overwhelming advantage of locating cross-discipline feature teams together, why would any manager or executive be so boneheaded as to sit them apart? These are software managers and executives—people with intimate knowledge of computers, caches, and latency penalties for fetches to disk. Why would they deliberately place the data sources for the inner loop of product development so far from each other? Rather than claim these managers are imbeciles, I’d claim their reasoning is simply misguided by obsolete practice and out-of-place priorities.

The lean approach to software development—specifying, implementing, and validating a feature before taking on the next feature—is only a decade old at Microsoft. That may sound like a long time, but it’s recent enough to have missed when many upper-level managers were still actively developing software. Some parts of Microsoft still use a pure waterfall model instead of feature crews, improvement teams, Scrum, or Kanban.

Managers and executives without lean experience may think, “Developers mostly work with other developers—therefore, they must sit together to be productive.” That’s true for pure waterfall teams, but team members using any modern and efficient form of software development spend most of their time engaging with their feature team colleagues, independent of discipline.

Managers and executives may also think that engineers should sit with their discipline group for career growth. That’s a great reason, but career mentorship and guidance is part of the outer loop of software development. The inner loop is developing the product—feature teams. Feature team colocation takes priority. Feature teams go in the registers and L2 cache of the team room. Discipline teams can be in main memory down the hall or on a different floor.

You’re so far away from me

If having feature team members separated by a hallway or floor slows you down like pulling data from main memory, then splitting your feature team across cities and time zones is like fetching that same time-critical data from the hard drive. What a disaster! Managers who organize feature teams with members across continents really should be forced to use US mail for all of their communications.

Distributed development is great, and it can be done well, as I describe in So far away: Distributed development. You just shouldn’t split the inner loop of software development across locations. Separate the work across multiple feature teams, and then locate those feature teams together in their local team rooms.

I can’t do this anymore

“Yeah, but what happens when the features or feature teams change? Now I’ve got to move people constantly!” No, you don’t. The best thing to do is keep feature teams together. Like any team, they get to know each other and work better together over time.

Of course, sometimes people come and go, and sometimes you need particular people on particular features. In those cases, keep most of the feature team intact, but alter a couple of the team members as needed. A healthy team will gladly absorb the new viewpoints and talents.

Eric Aside

Over the years, I’ve gradually turned over the membership of multiple feature teams an individual or two at a time. People are happy to join teams that work well together—the team’s positive culture is contagious. My supervisors have always remarked on how my teams maintain their productivity, even when changing key members.

Happy together

People aren’t computers with CPUs, caches, and hard drives. However, people’s productivity does depend on fast and easy communication with the folks they work with most. Microsoft managers and executives have long known this, which is why after every reorg, there’s an equal and aligned office reshuffle. However, those office reshuffles often focus on discipline and reporting structure, rather than on placing people closest to those they work with most—their feature team.

Yes, your discipline team helps you grow, but your feature team helps you ship. Mentoring is important, but it’s not the minute-by-minute central activity of your day. That activity is doing your individual work and working with your feature team.

Easy, cross-team communication dramatically increases productivity. I’ve personally seen it add the equivalent of one to three extra days per week—days we all could really use. There’s no excuse in this modern age of devices and services not get the most out of your time and teammates. Be together to ship together—make your team room the place where magic happens.

Data-driven decisions

ericbrec — Thu, 01 Nov 2012 07:00:00 GMT

You’re working on a feature and think there’s an obvious customer improvement to be made. The tester thinks you’re in obvious need of medical attention from a psychiatric professional. She believes the shipped design was fine from the start. The PM insists that your suggestion doesn’t fit the design language (?). He wants to make some overblown artistic statement. Your manager believes it’s the feature’s performance that’s the real problem. She wants you to stop arguing over design minutiae and start being a developer. Who is right? None of you. All of you. But most of all—the customer.

Customers can’t design the product for you. They don’t know what they want. However, they do know the good stuff when they see it. They vote with their money and their mouse (or their fingers and fortune; Windows 8, baby!). Your job is not to read customers’ minds. You can’t. Neither can your boss, your PM, or your tester. Each of you, particularly the PM, should be able to construct a good initial guess, but it’s only an educated guess. Your job is to ship feature improvements, measure customer reactions, and then iterate. I repeat: you can’t read customers’ minds. You aren’t correct—customers are. Ship, measure, repeat.

It used to be that the ship-measure-repeat cycle took a year or more per iteration. With cloud services, that cycle can be measured in weeks or even days. However, to take full advantage of shorter iterations and faster convergence to customer nirvana, you must change your coding and design habits, as well as your attitude. Or you can think you know better than customers and everyone else. You know, like a loser.

Getting to know you

As with any iteration scheme, you need an initial guess. Usually, that’s the currently shipping design, but sometimes you’re starting fresh in a new area or changing the game against a competitor. You can’t afford to try every combination of every feature—the permutations are far too great. You must start with a well-educated guess and only test those aspects that are the most controversial or experimental.

Your initial guess is determined by traditional market research and product planning—business development, customer and technology research, competitive analysis, focus groups, brainstorming, and prototyping. (A great framework for this is called scenario-focused engineering.)

The outcome of this market research and product planning should be a set of prototypes. Old-school Microsoft thinking would advocate shipping a single product with the best attributes of the different prototypes. Actually, real-old-school Microsoft thinking would support just shipping the first prototype. (The horror! The horror!)

Eric Aside

You can read more about proper prototyping in My experiment worked!

You can go with this or you can go with that

With today’s cloud services, you don’t ship a single product with the best attributes of the different prototypes. You ship all the best ideas from all the prototypes and let customers’ mice and money (or fingers and fortune) tell you which ideas drive the best results.

Trying different ideas on real customers is known as A/B testing or multivariate testing. The idea is simple. You send a known percentage of real customers to one version of a feature and a different known percentage to different version. You measure desired end results (more purchases, deeper engagement, and/or greater discovery) and then choose to send future customers to the version that got better results. Even packaged products can take advantage of A/B testing for their service-connected and/or frequently updated features.

Eric Aside

For more on measuring desired end results, read How do you measure yourself?

As with any statistical method, you must be careful in your analysis. For example, those mathematically inclined will enjoy Simpson’s Paradox, which has a way of twisting A/B test results when you mix them with audience segmentation. There are many such gotchas, so read a good A/B testing primer and follow its links if you’re serious.

You know it sounds so nice

So how on earth do you ship two (or more) versions of the same feature at the same time? Easy—code it twice.

“Code it twice?! Heck, I don’t have enough time to code it once!” Calm yourself. Teams typically don’t have design arguments over whether the feature is an air freshener or a surface-to-air missile. Their design arguments are over very specific elements, like the layout and sequence for UI or the calling pattern for an API. And for those specific design decisions, the vast majority of the feature’s code is the same, and often one version is the one already written and deployed in production.

Coding the same feature two different ways is particularly easy with a model-view-controller (MVC) design pattern. With MVC, or similar design patterns, the model (the code that really does something) is separate from the UI (the view) and the actions (the controller). To ship the same feature two different ways, you share the same model, but invoke different views and/or controllers based on the customer. You can do this for web services as easily as for web UI.

Naturally, you must add instrumentation that records which version was invoked and what results followed. The infrastructure and instrumentation to support A/B testing and experimentation should be built into Azure and other cloud systems, but for now you’ll have to rely on shared code within your division. (Just like you do for the continuous deployment and exposure control technologies that I described in There's no place like production.)

Eric Aside

If your team isn’t doing A/B testing already, check with long-term services teams within your division. Chances are they have an experimentation or instrumentation system you can share. If not, check with established services around the company (like Bing). Please don’t reinvent your own.

Decisions, decisions, decisions

Once you realize that arguments over design are silly (just ship both and see), you quickly get addicted to data-driven decision making. It takes all the drama, politics, and chest-pounding out of arguments and puts the control firmly in the hands of our business results as determined by the people who drive those results—customers.

Pretty soon you’ll want to inform all your decisions with data. How many branches should we have? What features must we cut? What teams are in trouble? There are endless real business questions that data can help resolve.

Please note two pitfalls:

I haven’t mentioned a single fancy chart or report. Data-driven decision making isn’t about graphs—it’s about informing business decisions with actual data instead of guesswork. Next time someone shows you a fancy dashboard, ask them what business questions it helps answer and how. Show me someone who doesn’t know or can only say that the chart shows the information on the chart, and I’ll show you someone who’s available for reassignment.
Data can only inform decisions, it can’t make them. There’s always a broader context to consider. Use data to remove ignorance and provide clarity, but keep your brain engaged. Your best judgment based on all the facts available should make the call. Data should enhance your brain, not replace it.

Wrap it up, I’ll take it

As I mentioned in Cycle time—the soothsayer of productivity, shorter cycle times for products and their supporting services have all kinds of benefits. Being able to make data-driven decisions is one of the biggest.

Start with a great initial design based on deep customer research. Have a bunch of solutions in mind for the key design problems and ship all the main alternatives. Select the desired business results you seek, instrument your alternatives accordingly, and let the results from real customers inform your decisions about which refinements to make.

It’s easy to do once you’ve tried it a few times, and it’s really addictive. Why guess and argue when you can know and decide? Knowledge is powerful. Go get powerful.

The new Microsoft

ericbrec — Mon, 01 Oct 2012 06:00:00 GMT

The Microsoft Company Meeting was a few weeks ago. If you love the tech status quo inside or outside of Microsoft, seek shelter. How the company operates and how it engages with customers and the markets is about to change. All the signs were there in the Seattle Key Arena for anyone to notice.

All the products looked like they came from the same company. Honestly, this is the first time I can say that with a straight face. The Windows 8 interface look and feel was pervasive from PCs to slates to phones to office and business applications—even into the living room on the Xbox. But the change is more than superficial. If you write an app for the PC or slate, you can easily put that app on the phone. Bing will help you find whatever you need on any device, whether it’s a stock quote on your PC, news on your slate, a restaurant on your phone, or a TV show on your Xbox. You can do real work on your PC, show it on your slate, and update it on your phone without effort because the devices are all tied together with shared cloud services.

Look, I know I’m sounding like a bad commercial for Microsoft here, but there’s a point. The days of Microsoft having isolated products are over. I believe this has huge implications not only for our customers and partners, but for people, like me, who work at Microsoft. Our lives are about to get both better and worse. You can embrace this change and succeed, or fight it and perish. I could be wrong, but I know I’m right.

Eric Aside

Why did it take so long for Microsoft to blur the lines between its products? I think the company finally learned its lesson from Apple with the iPhone. Microsoft thought smartphones (and their shared services) were supposed to be for business, but the market slapped us into sanity. The gloves came off: we built Windows Phone, threw social into Office, threw Office on the web, bought Skype, and the race was on.

As always, the content and asides in these columns are my own opinions and do not represent Microsoft in any official or unofficial capacity.

I love this company

First, a confession: I love the annual Microsoft Company Meeting. I’ve only missed it once in 17 years, the year Dana Carvey hosted, and I deeply regret that. However, I don’t watch for the host or even the demos—though I love the demos. I watch for the first and last speeches.

The first speech is always the money guy talking about the past year’s performance. My favorite money guy was Bob Herbold, because he was straight, dry, and hysterical. However, Kevin Turner has done a terrific job the past several years. The money guy doesn’t tell you everything Microsoft did, only the things executive leadership cares about. That’s gold-plated information. I find out how executives see our market position, what areas are likely to get attention, and how my division and what I’m working on rate. In other words, how I should focus my efforts.

The last speech is always Steve Ballmer talking about vision and direction. Kevin looks backward, Steve looks forward. From Steve, I learn what’s changing, how to think about it, what the challenges will be, and how I should respond. In other words, what I should be doing next.

Eric Aside

This year’s company meeting was terrific—perhaps my second favorite. There was so much momentum and optimism. We’ll see how Windows 8 and the wave of server, business, phone, developer, home, and office products do, but they sure feel strong. (My first company meeting in 1995 was terrific too.)

My favorite company meeting was in the fall of 2000. Microsoft was in the dumps. The Justice Department was deciding how to tear the company apart, growth was down, the stock was down, customer satisfaction was down, Linux was on the rise—we were being hit from all sides. Steve Ballmer’s speech that year acknowledged our situation head-on. He used the Ali-Foreman fight as an allegory for our predicament and how we’d overcome it. We’d take all those punches, bide our time, and then come out swinging. The speech was moving and inspiring. It was a turning point. We released Office XP and Windows XP later that year and haven’t looked back.

There can be only one

If the days of Microsoft having isolated products are truly over, what does that mean?

Certainly it should mean a simpler and better experience for customers, developers, and partners. One look and feel. One relationship with the company. One sign-in. One billing account. One marketplace. One search. One communications platform. One development platform. One run-time. Each using the same shared services. Far less confusion and fragmentation.
For employees, it means one look and feel, one sign-in, one marketplace, one search, one communications platform, one development platform, and one run-time. So, if you are currently working on one of our several different marketplaces, guess what? There can be only one.
It also means a much bigger emphasis on services. As employees, we’ve been hearing this a long time, and it’s been building a long time. Now, services are here, for real, across all our platforms.
It further means more dependencies and more sharing of infrastructure internally. You thought cross-group work within the same org was tough? Try it across divisions that are on different ship schedules.

I’m not saying all this change will happen at once. Much has already happened. Some is happening now. Some I expect to happen over the next several years.

I’m saying you should prepare. Get used to the idea of having your team merge with another that is providing the same service or platform. Get used to the idea of continuous deployment of services. Get used to the idea of sharing infrastructure and working across divisions. If those changes haven’t already arrived, they’re coming.

Change is the only constant

If you don’t already know about continuous deployment of services, start reading up on it. A sampling of my articles on services includes:

At your service (service scenarios)
It starts with shipping (shipping services)
There's no place like production (why and how you test in production)
Cycle time—the soothsayer of productivity (shipping daily and weekly)
Quality is in the eye of the customer (service testing)
Production is a mixed blessing (service compatibility)

To summarize the shift to services, I’d say you ship continuously, you test in production, and you rely on aggregate customer data to make your decisions. I’d also say it’s awesome!

Inherent in the system

Consolidating our services and platforms into one of each and sharing them across products might be difficult, but it’s an obvious course to take. Consolidating our infrastructure into one of each and sharing it across divisions isn’t as obvious.

However, sharing services and platforms without sharing infrastructure is like trying to build a British-units car using metric tools. You can create adapters, recreate tools, and put the car together with duct tape and baling wire, but are you really going to take that thing on the highway?

There are two major engineering infrastructure systems at Microsoft: the Windows build system (aka Razzle) and the Team Foundation Server (TFS) Team Build system. Both use TFS for work item and bug tracking, and both build just about everything, though Razzle primarily builds native code and operating systems, and TFS primarily builds managed code and services. My guess is that the entire company will be using one or the other for builds five years from now. (Yes, I think the third major system, CoreXT, will perish.)

Sharing infrastructure is painful and scary. You don’t control your own destiny because you must rely on others for build, the most basic heartbeat of your product development. What’s the upside, aside from losing the duct tape and baling wire?

You vastly reduce your engineering costs for infrastructure (people, hardware, labs, and custom software). Instead, your infrastructure becomes consolidated and shared.
You benefit from existing and future shared advances (build parallelization, test management, improved dependency tracking, automation, risk assessment, better IP protection, and, eventually, lightning-fast cloud builds).

If you haven’t already, start learning and thinking about which system you should use and how you can transition to it. Yes, the change will be painful, but you can drive the steamroller of change or be run over by it. Either way it’s coming.

Eric Aside

Will the Office division use TFS Team Build or Razzle? Right now it uses a customized mix of a bunch of technologies, as it has for decades. Office may be the last division to switch over. My guess is that it will go with TFS. Office has already used TFS for work items tracking. Its future lies with modern apps on Windows, and the natural build system for them is TFS. However, Office does use a great deal of native code. I guess we’ll see.

We're in this together

How do you minimize the pain of sharing services, platforms, and infrastructure across divisions that have different ship cycles? A few things will help.

Shorten ship cycles. The shorter the ship cycle, the higher the quality (by necessity), the faster the response to needs, and the lesser the impact on dependent teams.
Improve communication. You should have strong relationships and agreements across dependencies—that’s good practice in general. The fact that you’ll be sharing infrastructure helps with understanding and transparency.
Focus on adding value. Don’t try to replicate what the other division is already doing. Focus on adding and sharing unique value. This reduces conflicts, improves relationships, and moves everyone forward.

Eric Aside

I talk about managing dependencies in You can depend on me and “My way or the highway” (chapter 8).

Brave new world

Yes, Microsoft is changing. Teams will likely merge; services, platforms, and infrastructure will be shared; and we’ll have to work more often across divisions that don’t have synchronized schedules. Change is good. Change is necessary. Change is inevitable.

Not feeling the change? Think your area is immune?

More than ever, Windows is the core OS for all our products and thus must support them all.
The lines of customer experience between social media, Office, Dynamics, Windows Live, SharePoint, Lync, and Skype are all getting blurred.
Search, the cloud, and big data are permeating nearly every experience across PCs, slates, phones, and living rooms, as well as our internal systems.

If you aren’t feeling the change then you aren’t paying attention.

It’s easy to feel out of control during change. However, you can control how you manage and respond to that change. Anticipate it. Prepare for it. And then embrace it when it arrives. Not only will you do far better, but our business, our partners, and our customers will too.

It’s not going to be okay

ericbrec — Sat, 01 Sep 2012 06:00:00 GMT

Eric Aside

This month I cover a touchy subject—getting a 4 or 5 review rating. Please know that all opinions expressed in this column (and every Hard Code column) are my own and do not represent Microsoft in any official or unofficial capacity.

Also know that plenty of employees improve their review ratings by 2 values over the previous review period. Getting a 4 or 5 rating is far from hopeless, but you can’t just ignore it. Take action to significantly improve your situation, and you’ll do fine.

Reviews are communicated between mid-August and mid-September at Microsoft. For employees this year who receive ratings between 1 and 3, the review message will be fine—perhaps a little disappointing for the insatiable among us, but fine. For employees who receive a 4 rating, the review message will be discouraging. For employees who receive a 5 rating, the review message will be harsh.

There’s a tendency for managers, friends, and peers to say to those getting a 4 or 5 rating, “It’s going to be okay.” Maybe they said that earlier in the year, after a serious misstep or string of bad decisions. Maybe they said that recently, after the tough review. Regardless of when it was said, or who said it, let me cut through the caring crud and give you the straight scoop—it’s not going to be okay unless you act to make it better.

Some folks just have an off year or one too many different managers. However, when you are regularly chastised for behaving badly (bad work, bad interactions, or bad decisions), it’s not going to be okay. When you fail to achieve a high-profile deliverable on time or with high quality, it’s not going to be okay. When you deeply embarrass your team, your manager, or the company, it’s not going to be okay. And when one or more of those incidents results in your performance being rated 4 or 5, guess what? It’s not going to be okay—it’s going to be hard. You must take significant action, and since others are too afraid to be blunt, I’m laying it out for you now.

Eric Aside

Microsoft’s 1 – 5 review ratings correspond to the following percentages of folks within the same discipline and level band: the top 20 percent, the next 20 percent, the middle 45 percent, the next lower 10 percent, and the lowest 5 percent.

I describe how managers should handle the most serious of performance issues in “The toughest job—Poor performers” (chapter 9).

Sisyphus is us

Here’s what often happens when your performance is rated 4 or 5 among peers in your division. You refocus your efforts, work a lot harder, improve in a few areas, and really have a better year.

At next year’s review calibration, your manager goes in thinking you’ve moved up to the middle 45 percent (a 3 rating). However, it turns out everyone has too many people in the top 20 percent, so some of them get moved down into the second 20 percent. Of course, now there’s far too many in the second 20 percent, so they get moved down into the middle 45 percent.

Before you know it, you’re falling toward the bottom of that middle 45 percent. No one at calibration wants to move his or her folks from the middle 45 percent to next 10 percent (a 4 rating), but there are too many in the middle, so someone has to move. Your peers didn’t start from a deficit like you did, so they’re ahead of you now. The result? Your rating is back to a 4. So what can you do to change the cycle?

Eric Aside

If Microsoft’s review system wasn’t based on percentages (“a curve”), then people who did a solid job (according to their managers and/or peers) would receive at least average rewards. However, Microsoft fundamentally believes in differentiated rewards based on how employees perform relative to their discipline peers in the same level band. Thus, it’s possible for employees to do solid work and yet end up with a 4 rating, as I describe above.

A change would do you good

When your performance is rated 4 or 5, it takes more than doing better to break out of your slump—you need to do much better.

How do you do much better? There are a few options:

You can stay in the same job on the same team, but experience a fundamental change in your environment. Maybe your situation at home has dramatically improved. Maybe your personal or spiritual health has rebounded substantially. Maybe you’ve finished that degree or otherwise removed a significant distraction in your life. Don’t kid yourself—the change needs to be big for you to gain a big improvement.
You can switch to a job that aligns far better with your talents and passion and/or significantly expands your opportunity to grow and excel. You can do this on the same team, with the help of your manager, or move to a different team. However, don’t leave your current team thinking that alone will do the trick. Find a better environment in which to achieve. In other words, don’t leave someplace—go someplace.
You can switch disciplines or otherwise dramatically change your role. This might involve dropping a few levels to give yourself a chance to adjust to your new responsibilities. Being in the right role can make all the difference.
You can find a new job outside Microsoft, possibly in a new field or discipline.

The point is, you can’t simply work weekends and expect a better review next time. You must change things up dramatically to jump forward.

Eric Aside

For advice on changing groups, read Get a job: Finding new roles and A change would do you good. If you’re starting a new role, read The new guy. Note that Microsoft limits your ability to switch roles if you receive a 5 rating. (I talk about this more below.)

If you do have a home or health situation impacting your performance, you should definitely talk to your HR person and/or manager about it. Microsoft provides many options to help you get back on track.

You have special talent

If you decide to switch roles or disciplines, how do you pick the right direction? Focus on your talents and passion. Too many people worry about chasing their weaknesses instead of building on their strengths.

Yes, you must mitigate your weaknesses to prevent them from inhibiting your growth. That’s what those review improvement areas are about—not getting blocked by bad habits. For example, I have trouble listening; I can’t remember dates, times, facts, and figures; and I’m dyslexic and make tons of typos. So, I lock my screen and scratch down notes to clear distractions during conversations, I carry a smart device (my first was the Palm 100), I’m cautious when I quote facts (I hedge verbally), and I ask peers to review and proof my key emails and writing. What I don’t do is blow my free time on memory or grammar classes.

Working hard on areas or in roles where you’re lousy is a colossal waste of time. Yeah, I know your pride won’t let you be a failure in anything, but you’re never going to be world class in your weaknesses—the best you’ll become is average. Yet your peers are among the best in the industry.

So, swallow your pride and be honest with yourself about your skills and what you love. Talk to your friends about what they do and where you might best fit. Get excited. Let it show. Chase after the work that makes you sing.

Eric Aside

It’s possible for your manager to independently recognize that your skills and passion aren’t being fully utilized and to realign your current job in your favor. That manager would be a keeper. But you shouldn’t count on such luck. Recognize your own limitations, talk to your manager about opportunities that make better use of you, and put your manager in a position to help.

The exception that proves the rule

There is an exception to blowing your free time on improvement classes: dealing with serious interpersonal issues. If you are a star in the current job that you love, yet you are an enormous jackass, switching groups won’t help. After all, you are already playing to your strengths and passion. You’re just a jackass. In this case, taking classes on interpersonal skills and actively practicing good behavior is essential.

First impressions matter, so you may not want to switch teams until you’ve clearly overcome your social deficits—when you’re no worse than the rest of us. Then you could get a fresh start on a new team or even stay put, assuming there haven’t been death threats.

If l was in your shoes

If your performance is ranked in the bottom 5 percent (a 5 rating), then Microsoft HR restrictions limit your ability to switch roles. Maybe you saw this review coming and switched teams a few months in advance. Maybe you’re the exception that proves the rule. Otherwise, your options are a bit limited. What should you do? You should consider leaving the company—not necessarily leave, but consider it.

“But wait, I can do better! My manager says I just need to pick it up. I’m totally capable of being in the middle 45 percent or even the top 40 percent. Lisa [Brummel, the head of HR,] says every year is a fresh start.” All of that is true—you can do better, your manager meant what he said, you are capable, and Lisa was sincere. It’s just that circumstances are not in your favor, and your chances of success may be far better if you leave the company.

All companies need to make space for people to move up. That space comes from attrition or growth. Microsoft is still a growing company, but the ratio of open positions to filled positions is nothing like it used to be. That means the company must make room through attrition. Being placed in the bottom 5 percent may be the company’s way of saying, “Perhaps you’d do better elsewhere at this point in your career.”

I know the US economy is terrible, but software engineers are in high demand, and you are probably sharp and capable. It may be time to step away from Microsoft and join an exciting new enterprise, or you could change things up completely and pursue that other career you had put on hold. Regardless, this is an opportunity to reassess your goals and find a new situation in which you can be happy and successful.

Eric Aside

Over my career, I’ve seen many talented individuals leave Microsoft at a time that wasn’t of their choosing. In every case, I’ve seen the same outcome. At first they were confused and upset. Then they thought through what they wanted to do and pursued it. Within a year, they had found a new career inside or outside the software industry and were visibly happier than before, when they were struggling in their old jobs.

Don't let yourself be lulled into inaction

The worst thing you can do when you receive a 4 or 5 rating is nothing—believing it’s going to be okay and telling yourself that you just need to work harder. Just working harder probably isn’t the solution. It might even stress you out and mess up your personal life, which causes more problems and even worse performance.

Instead, be honest with yourself. Are you changing something significantly about your environment at work or at home? Or are you finding a new assignment or switching to a new discipline that better aligns with your strengths and passions? Are you making that big change to gain the big improvement you seek?

If you don’t think such a change is possible for you at Microsoft, have you thought about changing your career? Maybe going back to your roots or starting fresh somewhere new? Maybe re-centering yourself around what truly matters to you?

Yes, in the short term, things aren’t okay—but long term they can be if you don’t let your pride or fear get in the way. Open your mind and your heart, seek out your passion, and make tomorrow a better day.

Too much of a good thing? Enter Kanban

ericbrec — Wed, 01 Aug 2012 06:00:00 GMT

Last month, I wrote about the value of good program managers (PMs). Some people liked the column (mostly PMs). Some people hated it (folks with bad PMs). However, the most common response was that Microsoft has too many PMs. Can you have too much of a good thing? Heck yeah!

Why is having too many PMs a bad thing?

Because PMs are useless? No, PMs are our secret weapon. Read last month’s column, PM: Secret weapon or wasted headcount?
Because there is a magic ratio of PMs to developers (12:1, as some suggested)? No, this isn’t a theme park. Magic is for fantasy novels and Las Vegas shows.
Because PMs spend their time creating work for others? Yup, that’s it exactly. PMs orchestrate work for their teams. Having too many PMs yields too much work.

Having too many PMs will facilitate too many ideas, too many meetings, and too many designs and scenarios. The same is true for other roles. Having too many developers will lead to unaligned, untested, and unnecessary features. Having too many testers will generate unsupported, unexpected, and unreliable tests, or worse yet, more test harnesses. How do you right-size your team roles? It’s time for a little TOC—theory of constraints.

The weakest link

As I mentioned in De-optimization, the Theory of Constraints (TOC) tells us that the fastest way a project team can accomplish anything is constrained by the slowest step. Say your PM team can spec an average of six features in a month, your development team can code two features in a month, and your test team can validate three features in a month. There's not much point in your PM team going full speed, is there?

Of course, you can speed up the dev team by removing interruptions, doing pragmatic implementation design, and driving quality upstream (all of which I’ve covered in prior columns). However, at the end of the day, you’ve got to pace the PM and test teams to the dev team. Sure, you want buffers (like extra specs) to account for variability between features and different phases of the project, but you never want the PM and test teams to outpace the dev team.

The TOC strategy of controlling pace to match the slowest step is called Drum-Buffer-Rope.

Dev is the drum beat that paces the work, because in this case dev is the slowest step.
Buffer is the extra work (like specs) available for dev in case implementing a feature happens to be easier than usual. You always want the drum beating.
Rope is the constraint on PM and test to keep them on pace. Without the rope, developers are flooded with work and requests, causing them take short cuts, drop quality, and actually lower overall productivity with the subsequent rework, bug fixing, and discarded work. Watch Lucy and Ethel in the candy factory for a quick demonstration.

I know we’re not a factory—many aspects of software development are creative in nature. Of course, we’re not artists either. We have schedules, deadlines, dependencies, and sync points. People do get overwhelmed, take short cuts, lower quality, and throw away unused specs, code, and tests. That’s wasted effort and time that we can’t get back at the end of projects when we desperately need extra effort and time. With too much rope, we hang ourselves.

Fire away

Do we just start firing PMs and testers? In my example, that would certainly constrain PM and test to not flood dev with extra work and requests. However, we do need PM and test at some level (see “Undisciplined” in chapter 4). How many PMs and testers do we need? How do we avoid wasting time and effort?

At the time you are writing specs, code, or tests, it’s not obvious which ones will never ship; at least it isn’t when using traditional Microsoft methods and multiyear ship cycles. Even an annual ship cycle is too long to know what features will be shipped in advance using a waterfall-ish software development model.

The Feature Crew lean approach from Office helps avoid unused work. In Feature Crews, PM, dev, and test team members tie themselves to one feature at a time until it's completely tested and integrated. They can't get far ahead of each other. Versions of Scrum and Extreme Programming (XP) work the same way.

However, Feature Crews and Agile methods like Scrum and XP don’t explicitly tell you how many PMs and testers you need (if any). They also don’t tell you how to avoid waiting on your discipline peers or avoid going to excessive planning meetings. Isn’t there a simple approach that embraces traditional roles and doesn’t rely on magic or dogma? Glad you asked.

There’s a signpost up ahead

Over a year ago, I started introducing my teams to Kanban. Four of them are currently using it. Two teams switched from Scrum, and two teams switched from a variety of Microsoft methods. All of them are happy they changed.

Kanban tells you how many of each role you need and shows your whole team exactly where and when folks are waiting or stuck. Kanban translates roughly from Japanese as “signboard.” You post all your work items on a board near where your team sits. Here’s a photo of one of my team’s boards.

The board has columns for each step a feature goes through, left to right. Typical steps, like the ones in the photo, are breakdown, implement, and validate. (I know it’s hard to read, but that’s intentional given this is a public blog.) Each step has two columns (active and done) and a work-in-progress (WIP) limit. There’s also a column on the far left which holds the backlog of work items in rough priority order from top to bottom.

As you can see in the photo, the work items are simply post-it notes (you could use index cards or whatever). Team members move the notes from left to right at a daily 10- to 15-minute standup, based on each step’s completion rules at the bottom. (The PM updates the work-item tracking system to match the Kanban at the end of each day.) To see a simplified Kanban in action, click here.

The slogans at the top state Kanban’s core values: 1. Visualize your work. 2. Limit WIP. Visualizing work helps everyone see progress and blockages without planning meetings or retrospectives. Limiting WIP, well, there’s the rope.

Eric Aside

Many Scrum and XP teams use signboards with post-it notes. Kanban differs in three important ways:

Steps are divided into active and done columns. This keeps items from flooding the next step. Instead, they are held in the done column of their current step as a buffer.
There are posted completion rules for each step. Some Scrum and XP teams also define done, but Kanban clearly denotes and defines each step’s transition from active to done.
There are limits on the number of items that may be in each step. These limits act as the rope, as described in the next section. The rope regulates flow and identifies blockages without requiring planning meetings or retrospectives.

Together, these differences make Kanban a so-called “pull model.” Work is pulled from the right when needed, rather than pushed from the left, as is the case with many Scrum and XP boards. Pull models are generally more efficient because you only produce what you need.

WIP it good

Each post-it note represents work in progress until it makes its way to the final done column. Imagine you had far too many PMs and didn’t employ a drum-buffer-rope strategy. Developers would be overwhelmed with specs for unimplemented features.

If you had a post-it note for each feature, the Kanban would be loaded with yellow notes waiting for the implementation step. There’s no way the dev team would ever implement them all. Likewise, if you had too many developers or too few testers, the Kanban would be overflowing with post-it notes in the implementation-done column waiting for validation.

Unfinished features overloading the Kanban represent waste—work that is waiting and will likely never be finished. It’s visual and obvious. The trick to limiting waste is to limit the work in progress—you need WIP limits for each step. The WIP limits constrain the number of items that can be in any step (active or done). The limits form the rope that aligns all the steps to the pace of the drum (the slowest step). The done columns are the buffers which ensure the drum always has work to do.

As a glorious byproduct, reducing WIP reduces cycle time—the time it takes to complete features from start to finish. As I described in Cycle time—the soothsayer of productivity, this means you can react more quickly to changes in plan or competition (less lead time required) and have a shorter feedback and improvement loop with people using or testing your products.

Eric Aside

You can also track bugs on the Kanban if you wish. Typically, they are tracked in a separate big row apart from the main flow (a separate swim lane), often with their own separate WIP limits. Of course, you can also simply track bugs in your bug tracking system. Those systems are fairly similar to Kanban, especially when you limit the number of active bugs people or teams are allowed.

I’ve seen both approaches for bugs work. For tiny bugs that take an hour to fix, leaving them in the bug tracking system is fine. For larger bugs, it’s good to see their impact and flow visually on the Kanban.

With either approach, the key is that bugs take precedence over new work items. After all, bugs represent rework. Since you work in priority order, fixing prior work must be more important than any new work. The message to developers is that you’ve got to get it right before you get to move on.

When something’s going wrong

To see WIP limits in action, let’s say you’ve got too many PMs. They quickly take features from the backlog and break them down into spec’d work items. The breakdown step quickly reaches its WIP limit (six in the photo). Now the PMs aren’t allowed to break down more features. What do they do? They can analyze blocking issues and resolve them, help implement features, do customer research or prototyping, work on a different project, find another job, or whatever. What they can’t do is overwhelm developers.

Let’s say you’ve got too many testers. They quickly take completed features from the implementation-done column and validate them. Soon the implementation-done column is empty. What do they do? They can analyze blocking issues and resolve them, help implement features, work on improving automation or tools, work on a different project, find another job, or whatever. What they can’t do is overwhelm developers.

Notice this works for any step or role, since the slowest step can vary by feature. Problems are visual and obvious immediately, not after a retrospective. Replanning can be done continuously, without requiring special meetings (using whatever estimation method you prefer—my favorite is planning poker). It’s all made possible by limiting work in progress in a way everyone can see at all times.

Eric Aside

We still do formal retrospectives on demand with Kanban. We use them to analyze and take action on particularly troubling issues or recurring problems.

Something in your size

How do you set the right WIP limits? How do you know the right number of PMs, developers, and testers? Easy—start with the drum, the slowest step. Typically, it’s development.

You always want the drum beating, so make the WIP limit for implementation equal to the number of developers plus one or two for a buffer. How many developers should you have? Take the number of features you need to deliver and divide it by the number of features per month each developer can write (based on past average performance). Then divide by the number of months you have for development. That gives you the number of developers you need and the corresponding implementation WIP limit.

You then set the WIP limits for the PM and test steps to match their throughput to the dev throughput. Let’s use the hypothetical average rates in my original example, but make them per person: a PM specs six features per month, a developer implements two features per month, and a tester validates three features per month. (Actual averages depend on your approach and the type and size of your typical features.)

Say you need three developers to implement all your features on time. Dev throughput would be six features per month. To make PM throughput match, you need one PM and two testers. The WIP limits should be two for specs, four for implementation, and three for validation (the number of folks plus one for a buffer). Since you replan continuously, you can adjust your WIP limits as needed. Just don’t increase limits over and over again to avoid being blocked—that’s cheating. Analyze and fix the problem instead.

Eric Aside

In the Kanban photo above, the breakdown WIP limit is six. That’s because that team doesn’t use many hefty PM specs. Instead, the team is co-located and uses real-time design discussions, white boards, and iteration as they go. As a result, the breakdown step is simply to break down backlog items into small work items—a quick operation. The WIP limit of six ensures there are always six items ready for the implementation.

The team’s one PM does write specs for particularly large or tricky areas that span a bunch of work items. He also updates the work items in TFS daily to match the Kanban, facilitates design, meets constantly with customers, and does others things great PMs do.

Doing it well

You could match PM and test throughput to dev throughput without WIP limits or Kanban. Good teams do this intuitively to avoid wasted effort. They “right-size” their teams and work collaboratively to succeed together. Kanban just makes this process visual, simple to arrange, and easy to track. It also makes blockages and problem areas readily apparent.

Kanban is no substitute for high-level planning, release management, and syncing milestones across teams and divisions. It doesn’t replace cross-team scenario-focused engineering or the need for senior PMs to drive key cross-team scenarios.

What Kanban does do is tell you at the team level how many people you need and how best to use their time on a daily basis. It makes the flow of value to the customer continuous and minimizes time and effort lost to team planning, waiting, or work that doesn’t ship.

Making the most of the time you have is often the difference between a panicked product you’re ashamed to ship, but too exhausted to block, and a timely product customers love. Too much of a good thing can cause tremendous trouble. Stay focused, set the right pace at the right size, and reap the benefits of a team in flow.

Eric Aside

Many problems can disrupt the flow of a team. Kanban makes those problems visible. Some tips that solve common issues:

If one step is constantly slowing down other steps, increase the number of people on it, try new approaches to make the step faster, or decrease the WIP limits for the other steps.
If one step commonly has items in its done column for more than a day, lower the WIP limit for that step.
If you’ve got two or more steps in a row that the same people always do on the same items, combine those steps and simplify your Kanban. You don’t need lots of steps in order for Kanban to work.

For more information on Kanban, check out the Lean-Kanban Library.