I. M. Wright’s “Hard Code”

Spontaneous combustion of rancid management

ericbrec — Sun, 01 Nov 2009 06:00:00 GMT

What's good for you isn't always good for your group. Obvious, right? You can call it local versus global optimization. You can get geek philosophical about it and say, "The needs of the many outweigh the needs of the few…or the one." Or you can simply notice the difference you feel between zany ideas from the intern (cool) versus zany ideas from your general manager (scary).

For example, spontaneity in an individual is a good thing and unvarying predictability makes Jack a dull boy. But when Jack is running a large enterprise, unpredictability can wreak havoc. There are managers who grow up and learn this lesson, and there are managers who are Randomizing Ambiguous Nimrods Causing Incessant Distraction, or rancid for short.

I despise rancid managers. They think they are responsive and flexible when in reality they are the fastest means to team dysfunction and failure. If you are a manager and you tell your team, "Hey, I've got a great idea," and they look back at you seemingly saying, "Does it involve tying yourself to a tractor and driving off a bridge?", then you might be rancid.

It's not that bad

What's so bad about being a rancid manager? Isn't consistency and predictability boring? The answer lies in Brownian motion, which describes the movement of particles under random bombardment. Particle movement in Brownian motion could best be described as erratic.

Consider a large team of engineers who are constantly being pushed in different directions at random intervals by their general manager. You'd expect the same erratic movement from that team. Their chances of actually accomplishing anything as an organization are negligible.

Alternatively, if the team is consistently pushed in the same direction they will gather momentum and make significant progress toward their goal. Therefore, a successful manager sets a clear direction, points the team in that direction, and consistently pushes in that same direction until their goal is achieved. Course corrections that naturally come along should translate to gradual team nudges, until the correction is made. Only severe circumstances should prompt major changes in course.

I’m talking about high-level direction, not the day-to-day details which require more agility and flexibility. The key is aligning the day-to-day detailed decisions to the high-level direction. You can’t do that if your high-level direction constantly changes.

Do I look all rancid and clotted?

If teams run by rancid managers are erratic and make little progress, why are there so many rancid managers? Here are three reasons:

§ Being rancid seems responsive. Instead of always pushing in the same direction, rancid managers respond quickly to outside influences, giving their management a nice warm phony feeling of agility.

§ Being rancid means never having to achieve anything. Since the world of a rancid manager's team is always changing, there's a self-fulfilling excuse for why nothing gets accomplished ("Hey, a bunch of stuff happened!"). If these managers weren't rancid they'd risk being accountable. They'd have to do the hard work of setting an achievable vision and direction for their team and then achieve it.

§ Being rancid keeps you occupied. Where's the fun in consistency? What do you do all day to stay busy? What value do you bring to the team if you're always saying the same things? Making a call and sticking to it is difficult. It's scary and you might need to do real work to support it.

Of course, rancid upper management breeds rancid middle management. It's hard to escape. Often people don't even know how good consistent management can be until they finally experience it.

It's a path made of principle

When managers stop being rancid and start being consistent, a number of wonderful things happen. First and foremost, teams start achieving results. Managers move from creating havoc to preventing havoc. And team members actually understand what they are supposed to do each day, and know they have to do it because it won't be different tomorrow.

All this leads to a higher sense of purpose and higher morale. At first, the team may struggle to get fully aligned, but soon the job of a manager becomes easier. You're not always changing your story. Once the team is aligned there are fewer problems to resolve. It's easier to track and show progress.

What challenges does this leave for managers? The biggest is to paint the picture of where the team is going. You need to be clear and understand it deeply in order to describe it consistently and repeatedly to the team. Once you have your story of the future, the challenge is to stay on course at a high level as team members and external factors change. You must discover and communicate adjustments as needed, and prevent upper management from inappropriately disrupting your course.

It's not easy. You need confidence in your convictions and strong thinking behind your direction. It helps to have principles you follow and communicate. They let people know what you expect and how you make decisions. Doing so helps them align their decisions with yours and gets the whole team behind you.

Eric Aside

Upper management edicts can sometimes be hard to discern. Are they appropriate customer or business driven changes worth disrupting your team’s course, or are they inappropriate distractions you should filter from randomizing your team? The best way to find out is to ask your manager or a trusted mentor within your organization. Be direct. Find out the background and thinking behind the change. Even if the change is distasteful it might be the right thing to do. Even if the change is alluring it might be wrong to follow.

Picking your battles is a critical skill to master if you hope for a long and prosperous career. Understand the context. Learn who you’d have to fight, how tough it would be, and how much you’d stand to gain or lose. Then make an informed decision about whether the battle is worth engaging. Discretion can add years to your valor.

Oh, the noise! Noise! Noise! Noise!

"But things change!" protest the rancid managers, "Is your team supposed to blindly follow some ancient plan? Our agile competitors will beat us every time." Of course things change and plans, architectures, and designs must adjust. Details and understanding constantly evolve, driving continuous iteration of our work. But if your goal today is to build a social computing experience, no detail or external influence should be switching you to build tractor tires.

Strong managers know that all kinds of variation in team structure, competitive landscape, market fluctuations, and technical challenges precipitate changes to the best laid plans and designs. However, it's rare for those variations to necessitate a complete shift of direction. A strong manager welcomes change and contextualizes it for their team so that their momentum toward a shared goal stays strong through many corrections in course.

Eric Aside

Great managers directly confront distractions to keep them from disrupting their teams. Some have a regular "rumor mill" portion of their staff meetings to discuss the latest gossip. Shining a light on these issues and nipping them early keeps teams focused.

All progress has resulted from people who took unpopular positions

Being consistent as a manager may seem dull, but it's the kind of dull teams truly appreciate—the kind of dull that leads to results. While it sounds easy to be consistent, it requires courage. Courage to stand your ground and stand behind your words. Courage to be accountable for the direction you've set.

I'm talking about commitment. I'm talking about integrity. I'm talking about shaping the world to fit your vision rather than mindlessly following the latest trend or circumstance.

Our vision should be shaped by the needs and aspirations of our customers and the imagination of our collective minds, but in the end our vision belongs to our leaders as individuals. Our success depends on them having the courage to speak it and steadfastly pursue it. Do you have that courage?

Hire's remorse

ericbrec — Thu, 01 Oct 2009 09:00:00 GMT

Looking for that perfect candidate to fill a role? Good, that means you'll never steal a great candidate away from me. I love it when industrial-strength stupidity renders my competition comatose. You can't hire the perfect candidate, but please keep trying. Maybe after six months I'll even get your open headcount.

This isn't a case of letting the perfect be an enemy of the good. Idiotic hiring managers aren't trying to create perfect candidates—they are waiting for them to appear. It's like a romantic awaiting their soul mate or a home buyer searching for their "dream house." Guess what? Dreams aren't reality.

If someone tells you on your first or second date that you are the man or woman of their dreams—run. They aren't dating you. They are dating their dreams. Sooner or later, they'll realize the two don't match. The same thing happens when hiring managers get caught up in seeking their dream candidate.

Hiring people instead of pipe dreams

It's natural for a hiring manager and their team to imagine what the new hire will be like. When you spend so much time checking resumes, doing phone screens, informationals, and interviews, you can't help but think about the potential outcome.

Unfortunately, there are three dangers with getting caught up in fantasy:

§ You may not interview a great candidate even if they meet your needs because they don't match your preconceived notions.

§ You may hold off on an offer to a great candidate because they lack attributes that were imagined but not essential.

§ You may regret hiring candidates who turn out different from your projection of perfection, compromising their chances for success.

Of course, you shouldn't hire people who don't meet the high bar we set, but it's awful to lose out on strong hires because you were busy hallucinating. Let's dive deeper into each case.

Eric Aside

I talk about informationals and interview loops more in "Out of the interview loop" (Chapter 9).

I found myself much more reasonable

If you have a preconceived notion of whom you're hiring (worse case—someone just like you), then you're certain to subconsciously filter applicants based on that template. You may get candidates that match your musings, but you'll miss a crowd of candidates that meet your needs. If a good hire is one in a hundred (not far from the truth), the sooner you review a hundred qualified candidates, the sooner you'll hire someone. In addition, less filtering brings more diversity, which leads to better balance, better products and services, and better customer experiences.

If you hold off on an offer to a great candidate thinking that the next candidate might be even more ideal, you're likely to lose both. Surely another team will want your great candidate, and your next candidate will be at least as flawed. They say, "A bird in the hand is worth two in the bush." Thus, the next candidate better be twice as good if you hold off. Otherwise, make an offer now before your great candidate becomes your great regret.

Speaking of regrets, ever order something only to regret it shortly after? That feeling of buyer's remorse can afflict managers as well. Hire's remorse happens when you've imagined who might fill an important position, fill it with a real person, and then regret the decision because that person isn't precisely who you wanted. Quit sulking and get over it. Only movie directors occasionally get what they imagine, and that only lasts while the camera is rolling. You've hired a great person, now give them a chance.

Well, what do you need?

How do you differentiate what is really required for your open position from your unintentional biases? Consider the must-have results you seek from the role, and consider how soon you need those results. Then insist on candidates that have achieved those results in some general way. The sooner you need results, the more specifically the candidate needs to have achieved them before.

For example, say you need someone who can develop and ship code for a service. If you can afford to have them figure it out over nine months, hire someone who has demonstrated they can write code of any kind and ship it. It could be a game or a numerical algorithm for a thesis. All you need is the development skill and the ability to finish something. That could be almost anyone from any field—lots of possibilities.

However, say you're in SQL Server and need an engineering lead to step in right away. In that case, you need someone who has recently been an engineering lead. Your need for SQL Server expertise might not be as immediate though, so that's not an essential skill and shouldn't bias your thinking. You'd hate to pick a lousy lead with SQL experience over a great lead who can gain SQL experience over time.

The key is to focus on must-have results and the core skills essential to achieving those results. Then look for anyone who demonstrates those essential skills and gets analogous results. You can be more specific if your need is more immediate, but don't kid yourself. Getting picky may cost you candidates who'll deliver great results for years if you support them and give them a chance.

You could even say that he has principles

One item you generally won't find on a resume is a candidate's principles. Principles don't tend to align with appearance, skill set, or even achievements. Thus, when you imagine your ideal candidate you often don't think of principles, which is yet another reason not to waste your time imagining your ideal candidate.

What principles are important to you and your team? Integrity? Transparency? Accountability? Selflessness? Loose coupling? Screen for them. They are just as important as skills sets and demonstrated results. Many would argue that principles are more important. People can learn skills and work together to achieve results. Principles can be harder to attain or change.

Don't know what principles matter to you and your team? Figure it out—now. Let your team know. Being principled is itself a principle. For me, it matters the most and is the first trait I seek when talking to candidates.

I'm trying to tell you something about my life

Life is not a novel you get to write where everything turns out the way you conceive it. It's full of twists and turns for you to ride and hopefully enjoy in the end. Hiring and building a team is no different.

You have no idea who will respond to your open positions at what times, so don't try to guess. Instead, keep your mind open to all possibilities. Remember, you want a team full of differing viewpoints that are all aligned toward a common goal.

While you don't want unpredictable ships dates and quality, you do want unpredictable ideas and interplay on your team. They are the source of innovation and improvement. The more your team is filled with variety instead of clones, the more your team will enjoy learning from each other—a result reflected in more thoughtful designs and improved customer experiences.

So, consider the needs of your team, but stop short of projecting who might fill them. Keep your mind open to the possibilities, give offers immediately to great candidates unless you know the next candidate is twice as good, stick by your principles, and avoid hire's remorse. Everyone complains about insufficient resources—the sooner you fill your open positions the happier and more productive your team will be.

Right on schedule

ericbrec — Tue, 01 Sep 2009 09:00:00 GMT

My older son can now drive. This adds two new worries to my life—how ancient I feel and thoughts of my son in a ditch somewhere. To mitigate the second worry, my wife and I enforce a curfew and insist my son call if he's running late. The other night, he arrived home 20 minutes late without notice. My wife was furious that he was late. I was furious that he didn't call.

Why didn't my son call to say he was running late? Because, like my wife, he was focused on the schedule. He avoided facing conflict until he got home. He said, "I got home as fast as I could"—presumably breaking numerous traffic regulations along the way. My son completely missed the point. The purpose of the rules was to mitigate risk, yet his response to them was to drive recklessly.

Software engineers do this all the time. They come up with a development schedule, unexpected issues come up, and they end up being late. Instead of informing their managers of the delay, they avoid facing conflict, rush the work, sacrifice quality, and slip the schedule, all with little control or visibility. It's the opposite of what managers should want, yet those same managers insist on following the schedule precisely. Why? Because most managers and engineers don't distinguish between the two types of scheduling—meeting a commitment and managing risk.

Those who understand binary and those who don't

Yes, that's right. There are two types of scheduling and project management.

§ Meet a commitment. You made a commitment to customers or partners and you must meet it at the quality and time period promised. Period.

§ Manage risk. There is a mix of critical and desirable work. People can make bad choices. Issues can arise. You must manage risk to ensure critical work gets done.

These two approaches to scheduling and project management often get confused. Why?

§ They typically appear together. The overall project has commitments, but it is made up of smaller tasks that require risk management.

§ They both use dates. The difference is that dates for commitments are untouchable and drive everything. Dates for risk management are simply checkpoints to make sure work stays on track.

§ They both are called scheduling. Most people simply don't know the difference.

§ Meeting commitments is the only type most people are taught. From the time kids enter school, they are exposed to inflexible due dates and commitments they must meet. When they later learn project management, it is all about Gantt charts and milestones, with some risk management thrown in as an aside.

§ Managing risk is usually self-taught and informal. A small number of people are formally taught risk management. Most of us learn it from peers in college as we juggle large workloads. Instead of completing everything on-time, we form workgroups, focus on the critical work, and minimize the damage to our grades.

This tragic lack of understanding leads to horrible decisions, poor engineering, and scheduling disasters. You need to know the difference and apply the right scheduling to the right problems. Let's start with meeting commitments.

That's the only thing you're committed to

Meeting commitments is essential to working with partners, which in turn is essential to running most businesses. You can't coordinate work across internal dependencies or external agreements without synchronizing on dates and deliverables. Because commitments cascade, you must meet them or face catastrophe.

Say your daughter's birthday is coming and you've promised her a new game she wants. How would you feel if it wasn't delivered to you when promised? There is a chain of handoffs between the developer, the manufacturer, the seller, and you that all must be met to ensure your daughter's happiness on her birthday.

Of course, this is much easier to do for Web-based products, but the same problems come up with handoffs between teams or departments. Delivering on commitments builds trust and lasting relationships between partners. Missing commitments does the opposite. While many software projects require little or no coordination across groups, running large and mature projects typically involves meeting commitments, and thus formal project management techniques.

Eric Aside

To help them make their commitments, companies typically use inventory, buffers, and other forms of risk management for individual steps in the process. That's the whole point. You use formal project management for meeting your high-level commitments and risk management for properly completing the individual steps in your process.

Don't you think it's a little risky?

Risk management is about making sure the critical work gets done properly, even in highly variable environments. Scrum and Feature Crews are excellent examples of software development practices that focus on risk management—in particular, the risk that you won't efficiently ship value and quality to the customer.

As I pointed out in my very first column, Dev schedules, flying pigs, and other fantasies, dev schedules and test schedules are in the risk management category. All the feature dates are checkpoints to mitigate risk. Only the small number of cross-group synchronization points (major milestones) are commitments.

What matter in risk management are focus, order, and status—not precision. Focus on what's important, do those items in priority order, and track the status as the situation changes. Notice that hitting precise dates for tasks isn't important, so long as you finish the critical tasks at the expected quality on time. Everything else can be cut.

That's why you must tell your engineers the same thing I told my son, "Coming home right on time isn't important. Telling us you aren't coming home on time is." You can only manage the risks if you know about them. The dates are there only to alert you when plans need to change.

Of course, you can't slip a critical task past a commitment date (a major milestone), and my son can't stay out past 1:00 A.M. or his license will be suspended. But curfew is well before then, as it should be, to avoid any chance of catastrophe.

Eric Aside

There are many popular risk management techniques. Here are a few handy ones for software development (many taken from prior columns):

· Hold daily stand-up meetings—15 minute meetings to talk about progress, future work, and blocking issues (called Scrums in Scrum).

· Assign a backup for all task assignments (partner less experienced folks with more experienced folks).

· Use buffers—set aside time for task fluctuations (personally, I never liked this practice; I'd rather have a well-prioritized list with no intention of completing everything).

· Under promise and over deliver—also known as setting appropriate expectations.

· Establish a fallback plan—have a plan in mind in case a risky task fails, like cutting back the feature or going back to the previous version.

· Balance risk—keep the overall risk of your project at a constant state of "scary but not terrifying" by adding and removing risk as things change. For example, if a team member has a parent fall ill, your risk has increased so you should cut a risky feature or reassign that tough task you gave a junior engineer.

You pick the one right tool

So before you start working on a schedule, stop and think about what's on it. Is it a set of dates and deliverables you've committed to a partner? Or is it a set of tasks with various priorities that you need to track and avoid messing up?

In the case of my son coming home by curfew, it was a task we didn't want him to wreck, literally. Thus, we were doing risk management and the focus needed to be on giving timely status as opposed to coming home at a precise time. Most software development tasks fit that mold. You just want your engineers to tell you promptly if they are running late so you can adjust. Precision is unnecessary and potentially counter-productive.

However, if you are running a large project with multiple teams and partnerships, then commitments and synchronization are critical at a high level. The high-level schedule is full of milestones and classic project management tools.

Just don't confuse the high-level schedule with the low-level tasks. If you treat the low-level tasks like your high-level commitments, your engineers will take shortcuts and drive too fast. Instead of managing risk, you might cause them to crash one of your critical tasks, which in turn breaks your high-level commitments. Use the right tool for the right level. You'll sleep better at night.

20 years together

ericbrec — Sat, 01 Aug 2009 09:00:00 GMT

Eric Aside
It's my 20th Wedding Anniversary. My wife and I are celebrating in the San Francisco Bay area, where we first started living together a few blinks of an eye ago. We'll watch a ball game, see some sites, and visit Tesla Motors to check out a model of the sedan we ordered.

Long time readers know that I ordered a Tesla Roadster years ago as part of my mid-life self-indulgence. It arrived in March this year and I am so loving it. It's a great car and a lot of fun to drive. My wife and I have been so impressed by Tesla's nearly flawless delivery of this v1.0 car that we immediately put money down on a sedan for her. Good times.

The VP-geebees

ericbrec — Wed, 01 Jul 2009 09:00:00 GMT

It's the end of the fiscal year. Most engineers associate this time with performance review season, but for principal-level engineers and higher it's also executive review season. Time to waste weeks of your life writing slides for executive presentations that will be rewritten five times before they are never presented.

Executive reviews aren't a waste of time—occasionally you need an experienced, authoritative voice to blow apart your assumptions and refocus your efforts on desired business results. Preparing isn't a waste of time—being forced to explain yourself to others always helps your thinking, and I've got no desire to look like an idiot in front of the person who approves my compensation. The real waste of time is the focusing on getting the right slides for every season and situation instead of getting the right strategy.

Smart, high-level people simply don't know how to cope with executive reviews. They think it's a time to show off instead of a time to listen. They respond inappropriately to executive criticism of their badly presented, unsuitable slides. I've done it too—it's a trap set by our superiors filling out the poor templates dictated by their superiors. It's the misinformed leading the uninformed. Well, now it's time to break that cycle, avoid the pitfalls, and focus on what matters—valuable feedback on your clear and concise plans.

Wisdom to know the difference

Why do so many otherwise intelligent people bungle executive reviews? I believe there are two reasons—exuberance and confusion.

§ Exuberance over the importance of the moment. It's so important that we must cover every detail rather than focus on what's important. Twisted huh? Who defines what's important? The executive. What's important to the executive? Ask. Press for clarity. Don't accept second-hand smoke from an assistant. It's not good for your health.

§ Confusion between executive reviews and presentations. Both use slide decks. Both involve presenting. The difference is that in presentations the presenter is in control. In executive reviews, executives and their posses are in control. Failure to recognize this difference leads to failure in your review.

The secret of my success

How do you handle executive reviews successfully, obtaining all their potential benefits? Here's a three-step guide:

1. Learn what is important to your executive.

2. Present that information in three slides or less.

3. Respond to questions with insight and to feedback with thanks.

That's it. Let's break it down.

A riddle, wrapped in a mystery, inside an enigma

You first must learn what's important to your executive, from both an informational and a philosophical perspective.

From an informational perspective, what does your executive want to know about your project? Alignment with other projects? Financial contribution? Market share impact? Value proposition? Competitive response? You want to learn how your plans are being evaluated.

From a philosophical perspective, what principles are most important to your executive? Transparency? Alignment? Loyalty? Integrity? Self-confidence? You want to learn how you are being evaluated.

How do you learn your executive's informational and philosophical perspectives? Ask peers who've already been through a review with your executive. Ask your boss and your skip-level boss. You can even get thirty minutes on your executive's calendar. Be sure not to believe any one individual, but see patterns in feedback from multiple sources.

Easy as 1, 2, 3

Now you are ready to create the slide deck. You need only three slides—the current situation, the desired situation, and the tactics to get from the first to the second. That's all you should have. Remember, you are not in control of the review—the executive is. All you can hope to do is frame the discussion. All the other slides can either be cut or left as appendix slides for reference.

The current situation slide may be a problem statement, a current scorecard, or a recap of progress to date. The proper context and information depend on what's important to your executive, which you learned earlier.

The desired situation slide may be a solution, a target scorecard, or a going-forward strategy. It should align with your first slide and resolve the issues it raised.

The tactics slide may be a timeline, bullet list, or table of next steps, typically also indicating risks and mitigations with associated asks. Careful what you say on this slide. It tends to convert directly to commitments.

Eric Aside

The tactics slide seems like it covers a lot of information. Of course, all three slides do. You need to understand how your executive likes information presented.

· Does she like eye charts with all the information on the slide?

· Does she want summary slides and expects you to have all the details in your head?

· Does she prefer detail slides in the appendix that she can reference?

I read the instructions

Many executive reviews require you to follow a template with predetermined slides for you to fill-out. Having a template is terrific—it adds consistency and clearly sets expectations. Unfortunately, most templates are hideous with four or five times the number of slides needed. The templates are either ancient or produced by assistants.

How do you handle a fifteen-slide template? Pick out the three crucial slides—the ones that describe the current situation, the desired situation, and the tactics to get from the first to the second. Get those three slides right—then ensure the other slides align consistently with your crucial slides. This keeps you on message no matter where the executive takes the conversation. If possible, skip past the other slides and stick to the crucial three.

The purpose of the review is to get valuable feedback on your clear and concise plans. By aligning your slides and staying focused, you can frame the discussion and get the input you need.

Eric Aside

A handy tip is to send out a pre-read three days before the review. Write a one-page document that addresses the executive's key questions or provides context that attendees should know before the meeting.

The pre-read helps the conversation stay focused. It also gets the executive in the right frame of mind and provides the opportunity to send clarifying questions to you in advance so you can better target your presentation.

Oh behave!

The last step in my three-step guide to executive reviews is about how to behave. First and foremost, do not be intimidated or enchanted by the executive. Executives used to have your job and they miss it (just ask if you don't believe me). They still use the bathroom. They still embarrass their kids. Do yourself a favor and get over yourself. Act like you've done this before.

The executive will typically take two actions during your review—ask questions and make comments. Most of the time you want to take notes and keep your mouth firmly shut. Use duct tape if you must. Abraham Lincoln said, "It is better to remain silent and be thought a fool than to open one's mouth and remove all doubt."

When should you say something? When you have something insightful and relevant to say. "I agree" doesn't cut it. "We're doing that" doesn't cut it. "When we fixed that issue our support calls dropped 67%" might be worth mentioning if it's relevant. When you open your mouth, be sure you are adding value, staying respectful, and being concise. "Yes," "No," and "I don't know" are often sufficient. The rest of the time you should listen.

Eric Aside

If you need help being succinct, tell a friend at the review to give you a signal when you need to stop talking—perhaps a flashing neon sign.

As I mentioned in "I'm listening," the single proper response to all feedback is, "Thank you." In the case of executive feedback, be sure to write the comments down and consider each point. You don't have to address everything the executive mentions, but you do need to consider it.

Remember, executive reviews aren't the time to show off. They are the time to receive valuable feedback on your plans. The time to show off is when you deliver on those plans.

How'd I do?

When the review is finally over, you'll likely feel awful. The executive asked many tough questions and made a bunch of pointed comments. Was it a disaster? How can you tell?

Luckily, it's easy to tell how the review went. The key is the level of detail the executive discussed, not in the number of positive or negative comments. If the executive's questions and comments were all general and high level, then the review did not go well. The executive was questioning your basic strategy and assumptions. If the questions and comments were in the details, then the review went quite well. The executive agreed with your strategy and approach and was giving you feedback on small pieces.

Either way, executive reviews aren't about giving you an ego boost. They are about getting valuable feedback on your plans. Learn the information and principles the executive cares about, present your plans as simply as possible within that context, and be a professional during the review, and you'll get all the feedback you need to succeed.

Eric Aside

Are executive reviews really necessary to operate a business? At times they seem to act as a crutch for a lack of organization and aligned planning. When an executive staff's plans are aligned and the organization is built to match the plan, then all the executive should need to run the business are regular staff meetings and coordination meetings with executive peers. It also helps if the executive is accessible to everyone in the organization through blogs, one-on-ones, events, and casual encounters. A number of Microsoft organizations are now run this way.

I hardly recognize you

ericbrec — Mon, 01 Jun 2009 09:00:00 GMT

The annual engineering awards are being given out this week at the Microsoft Engineering Forum. Annual reviews will soon follow. These are great opportunities to recognize impactful work. It's too bad most managers are tragically ignorant of how to recognize their employees or truly why they should.

If you are a manager, you're probably relishing this opportunity to heckle all those bad managers. Guess what? I'm talking about you. You don't know how to use recognition properly. You don't know why you should. "But I'm great at recognizing my employees," cries a clueless manager. "I'm always congratulating my team—I even shaved my head once." Let's call this manager, "Chaos."

Chaos thinks recognition is all about morale and motivation. Certainly, there are real benefits for Chaos being a team cheerleader. But if that's the depth of his use of recognition, then chaos is what he'll get.

Everybody wants results

What Chaos fails to recognize is that recognition is a form of reinforcement. Reinforcement drives behavior. Behavior drives results. Results are king at Microsoft. Good recognition focuses on reinforcing desired results (and correcting undesirable ones).

If you aren't thoughtful about the results you seek, recognition can easily drive detrimental behavior. For example, Chaos shaved his head when his team met a tough milestone. To meet that milestone, team members cut corners on quality and deferred fixing structural issues. Those issues increased the "bug debt," prolonged stabilization, and reduced release quality. More importantly, Chaos' team members learned that Chaos rewards cutting corners and doesn't respect quality.

Eric Aside

Cutting corners for rapid development is desirable for prototypes and new ideas, where learning about the problem space is the result you seek.

The end may justify the means

"Yeah, but we hit the milestone. We built team unity. That means something!" claims Chaos. Do the ends justify the means? No, not with your narrow view of the ends.

The ends for Chaos were a united team hitting a tough date. However, others ends were achieved—increased bug debt. If the ends had been defined as a united team hitting a tough date with zero bug debt, then the means can be left to the team.

Chaos is getting cynical. He says, "So if the team robbed a bank to get money to pay a vendor to reduce bug debt then that would be okay?" No, it wouldn't. Chaos has introduced another end—jail time. Define the ends as a united team legally and responsibly hitting a tough date with zero bug debt, and that problem is avoided.

It's not easy to carefully define and communicate the ends you seek. It's much simpler to follow Chaos and reward haphazard results, ignoring the unintended consequences. However, setting clear expectations and recognizing your truly desired results pays huge dividends:

§ You micromanage less.

§ Your team innovates more.

§ You get the results you desire.

§ You have more time to focus on developing and recognizing the great work of your team.

The time has come to act and act quickly

Do you wait till the ends are achieved before recognizing them? Recognition is most effective when given immediately after achieving a goal. But you also want to recognize all the intermediate results that led to the end result.

For example, on the way to your united team legally and responsibly hitting a tough date with zero bug debt, your lead ran a great design review. You should immediately recognize her effort saying, "That was a terrific design review today. I love how you listened to everyone's opinion without critique. I also liked how you summarized that feedback and improved the design. Correcting those errors and misunderstandings early will save us significant time and lead us toward hitting our date with zero bug debt."

Notice the keys to great recognition:

§ It's immediate—the same day, or even better, the same minute.

§ It describes precisely what you liked—as opposed to the generic "nice job."

§ It's tied to the desired end result—reinforcing the real value of the effort.

You may not have the time or opportunity to recognize every positive step toward your end goal. However, you should keep your eyes open and address as many small victories as you can. Your team will love it, they'll better appreciate your expectations, and they'll be better aligned toward your desired result.

Let us celebrate

Chaos wonders, "Day-to-day recognition is great, but doesn't it detract from the big celebration at the end? Was I wrong to shave my head?" Chaos' grooming habits aside, a celebration marking a major achievement is just as important as day-to-day recognition. However, because it's a culmination of a long-term effort it's not as simple as sharing a few comments or shaving your head.

First and foremost, recognition should be for a carefully defined desired result, not something arbitrary like "great effort" or "someone said something nice." For example, don't give out an award for "teamwork." Give out an award for "teamwork across divisions and geographies that led to delivering a complete customer scenario."

Once you have clearly defined criteria for the recognition, plan the celebration. Here's what makes for a lasting positive experience:

§ Make it personal—if you defined the goal, the recognition should come from you. Include some personal remarks that express the spirit behind your goals and the way individuals or the team embodied that spirit.

§ Make it public—public ritual is important. It carries meaning, builds community, spreads the message, and creates a shared sense of purpose.

§ Make it lasting—the associated award should be substantial to the senses—heavy, bold, eye-catching, and tactile. Shaving your head meets many of these criteria, but so do heavy physical awards (like the Oscars) and giant signed banners on heavy poster board.

These guidelines give your celebration enduring emotional impact. Food or money don’t cut it.

I'd like to thank the Academy

The last element to consider is, "Do you give the recognition to the team or to the individual?" While you can certainly give the whole team a celebration and a day off, recognition for carefully defined desired results should be called out to a small number of recipients (typically, no more than five). Any more than that dilutes the impact.

Why is the impact diluted when given to more than five recipients? Because when you recognize a larger group, there are sure to be individuals who didn't embody the spirit of your goals. The message you send is that tagging along is just as good as being the driver. It isn't. Who originated the action? Who drove it to fruition? Those are the people at the center and in the lead. Those are the people you recognize and encourage others to emulate.

Eric Aside

I've been involved in the internal Engineering Excellence (EE) Award program for some time. It recognizes broad improvement in the way we engineer our products and services. The criteria are around demonstrating that improvement and making it available for others (business and customer impact, plus adoption). The recipients are those individuals who came up with the initial idea, first put it in practice, and drove adoption. The ceremony has ritual (Bill Gates used to host it) and the awards themselves are bold, heavy, eye-catching, tactile, and will last a lifetime.

Over the past several years, the EE Awards have recognized and encouraged dramatic improvements in our engineering—more secure and reliable products, better customer feedback, and broader language support. Reviewers in specialized areas are noticing the difference. Hopefully, when enough improvements are broadly in place, everyone will notice.

An interesting side note: a few years ago we gave an EE Award to a tool that consolidated a large number of duplicate efforts, gained broad adoption, and automated processes that improved our software. Unfortunately, the tool itself wasn't well engineered, which hurt productivity and reflected poorly on the award program. A great example of needing to carefully define the ends you seek.

All right, let's review

Now that you know how to recognize your employees and why you should, how can you apply this to the annual review process?

§ Describe what you liked (and disliked) about the results your employees achieved and how they achieved them.

§ Talk about the small results and the big results. Tie them together.

§ Set carefully defined goals for the future that will drive personal development and stronger results for your business and customers.

Clarity around expectations tied to consistent feedback described in plain language is critical to getting great results, and a happy and secure team. Recognition requires careful thinking and deliberate action, but it's not difficult to do. Avoid the chaos and you can even keep your hair.

It starts with shipping

ericbrec — Fri, 01 May 2009 09:00:00 GMT

Call me "old school" but I believe in shipping. Trying isn't enough. Getting close isn't enough. Good ideas aren't enough. You've got to ship.

It used to be that interviews started with, "What have you shipped?" If you hadn't shipped recently, "Why?" Why? Because you can't deliver customer value if you don't deliver. You can't iterate and improve without finishing an iteration. You can't get customer feedback without customers.

People used to complain that promotions and rewards were disproportionally distributed to those who shipped. I say, "Absolutely, that's how it should be." Does this hurt quality? No, you set a high minimum quality bar and ship. Does it hurt innovation? No, innovators have always risked an initial drop in pay to receive a big payoff should they deliver.

Eric Aside

Some people complain that the big payoff doesn't exist at Microsoft for innovative ideas. Those people haven't shipped. The people who successfully ship innovative ideas are the ones who become our organizational and technical leaders.

It all starts with shipping. This is particularly apt with services, where everything literally starts with shipping, and where I'm focusing the rest of this column. Our critics claim that in the new world of services Microsoft has forgotten how to ship. Perhaps, but Microsoft has forgotten more about shipping than most companies will ever know. We just need some reminders and reeducation, especially when it comes to services.

Eric Aside

Does a focus on shipping drive death marches? No, death marches delay shipping. As I wrote in “Marching to death” (chapter 1), death marches result from a lack of planning and courage. This is particularly important to understand in the services world where sustainable shipping is critical to long term success.

I offer you my service

How much about shipping services has Microsoft forgotten or doesn't get, according to critics? Not as much as they would have you believe, but enough to make you think. Let's go over the herrings and the heartaches, mixed with a little happiness.

The red herrings:

§ Services make you think about everything differently.

§ Services center on data while packaged products center on functionality.

§ Services have greater security concerns than packaged products.

§ Services have serious issues with dependencies.

§ Services demand higher quality and faster iterations than packaged products.

The heartaches (and happiness):

§ Services run across hundreds of machines, not on a single client.

§ Services must scale out automatically.

§ Services are easier to switch than packaged products.

§ Service upgrades hit everyone instantly.

§ Services are living, changing things.

Let's break these down, starting with the red herrings.

What is that smell?

The first services red herring is a big one, "Services change everything." As I addressed in At your service, this is total bovine fertilizer. Services start and end with helping customers achieve their goals, just like all products ever. You focus on the customer experience and what they hope to accomplish or you lose. End of story.

The next three red herrings—centering on data, security concerns, and dependency issues—all apply just as well to shipping packaged products, though it may have taken us longer to realize it. You can't expose data format changes to customers without chasing them away, on the client or the server. There isn't a computer product or service today that isn't vulnerable to attack—you must secure them all. Finally, if you think external dependencies aren't problematic on the client, you clearly don't use many drivers. I'm not saying these aren't real issues—I'm saying they aren't new or specific to services.

The last red herring is among the most common concerns raised about why shipping services differs from shipping packaged products—high availability and Internet time. Look, it's not okay for packaged products to never work or require a reboot every time you use them; at least it hasn't been for quite some time. The quality bar is no different for services, though there are plenty of services that fail constantly.

As for Internet time, that hit packaged products a decade ago with the introduction of Windows Update. And if you think that those patches are just security fixes, you haven't been paying attention. More and more we are fixing all kinds of experience issues shortly after customers report them, for services and packaged products. That's a great thing for customers.

However, gradually improving the customer experience every month or every day isn't enough. Both services and packaged products need to ship significant, orchestrated updates to deliver breakthrough customer value. Facebook wasn't going to gradually update itself into Twitter any more than Vista would gradually update itself into Windows 7. You must focus on what the customer is trying to accomplish, and sometimes that isn't a quick change.

Eric Aside

The best way to learn how to ship is to do it early and often. Make every build a shippable build. Build every day and rebuild the entire system at least every week. Deploy regular tech previews and betas. Deploy regular incremental updates and fixes into production. Ship early, ship often. Practice makes perfect.

There are too many of them

However, not everything about shipping packaged products applies to shipping services. There are mental, process, and team adjustments that you need to make.

First and foremost is that services run across hundreds or thousands of machines dispersed in multiple data centers worldwide. Sometimes functionality and data are replicated. Sometimes functionality and data are specialized. Usually, it's a combination of both for scale and reliability. Naturally, this presents design and synchronization problems but plenty of books have been written about that (read don't rediscover). The less obvious challenges are around debugging and deployment.

Why is debugging a service so tough? Timing issues are killer given multiple threads on multiple processors across multiple machines. Yikes! However, that's not even the toughest challenge.

What's the first thing you do when debugging an issue? Analyze the stack, right? With services the stack is split across servers and requests, making it nearly impossible to trace a specific user action. The good news is that there are new tools that help tie user actions together across machines. The bad news is that this isn't the toughest challenge either. The toughest challenge is that you're always debugging in the live environment. You don't get symbols, breakpoints, or the ability to step through code.

So let's recap. Debugging services means debugging nasty timing issues across multiple machines with no stack, symbols, or breakpoints on live code. There's only one solution—instrumentation—and lots of it, designed in from the beginning, knowing you'll soon be debugging across live machines with no stack, symbols, or breakpoints.

They're multiplying too rapidly!

Solving debugging brings us to the other huge challenge—deployment. Deployment needs to be completely automated and lightning fast. We're talking file copy installation, with fast file copy. No registry, no custom actions, and no manual anything.

Why does deployment need to be so fast and simple? Two reasons:

§ You're installing onto hundreds or thousands of machines worldwide while they are live. Installation must work and work fast with zero human intervention ever. The slightest bit of complexity will cause failures. Remember, five minutes times 1,000 machines equals three-and-a-half days. It had better just work.

§ The number of servers needs to grow and shrink dynamically based on load. Otherwise, you are wasting hardware, power, cooling, and bandwidth in order to meet the highest demand. Because your scale depends on load, it can change any time. When it changes, you need to build out more systems automatically and instantly.

The happiness around deployment is that Azure will do most of the heavy lifting for you (so let it, don't reinvent). However, you still need to design your services to support file copy installation.

Life is so uncertain

Enough of the challenges you can predict, how about the unpredictable ones? The services landscape is in constant change. While some services are sticky because they hold your data (like Facebook or eBay), many aren't sticky at all (like search or news). A few minutes of downtime can cost you thousands of customers. Data compromise or loss can cost you millions of customers. They'll just switch. Our competitors will be happy to accept them. It cuts both ways so you need work hard to both welcome and keep new users.

When you update a service everyone gets the new version instantly, not over years. If there's a bug that only one customer in a thousand experiences, then that bug will hit thousands of customers instantly (law of truly large numbers). That means you need to resolve the issue quickly or rollback. Either way, it's a bad idea to update a service on a Friday and a good idea to have an emergency rollback button always at the ready.

Finally, it's important to realize that services are living, changing things. You'd think that because the servers are all yours with your image and your configuration that it would be a controlled environment—and it is until you turn on the switch. Once the server goes live, it changes. The memory usage changes, the data and layout on the disks change, the network traffic changes, and the load on the system changes. Services are like rivers not rocks. You can't ship and forget services. They need constant attention. To make your life easier, bake resilience in by automating the five Rs—retry, restart, reboot, reimage, and replace (though replace may require human hands at some point).

The happiness that comes with these heartaches are customers willing to switch; an ideal idea testing platform because you can show customers different ideas and see which they prefer on a daily basis; and the ability to ship now and find the tricky intermittent Heisenbugs later (using your five Rs resilience to keep up availability).

Back to basics

There you have it. Some food for thought mixed in with the old basics of writing solid code that focuses on customers and their goals.

However, none of this is worth anything without shipping. Make shipping a priority and we all win. Sure, the quality bar has gone up, but we're not kids selling lemonade anymore. We need to ship quality experiences regularly, on both long and short time scales. We need to ship on the Internet, on the PC, and on the phone. We need to serve our customers well and delight them into sticking with us. It's a long journey, but it doesn't start until we ship.

Your World. Easier

ericbrec — Wed, 01 Apr 2009 09:00:00 GMT

During difficult economic times like these, people tend to whine less about common complaints that now seem trite. Mostly, I'm relieved not to hear how much e-mail is in Ingrid's Inbox, how Brian broke the build again, and how Suresh's service schedule slipped successive sprints.

However, it's during difficult days that we should patch plaguing problems. When are you going to be more motivated to mend malignant maladies? Surely, no additional alliteration is advisable.

A surprising number of common issues can be solved using two simple techniques—single-piece flow and checklists. There's a ton of behavioral and process theory behind why these simple methods are effective. The point is that they are effective and you and your team are less effective without them.

All too easy

Take Ingrid's Inbox. Like most Inboxes, Ingrid's is overflowing. She spends tons of time on it, yet it only gets bigger. She constantly loses track of mail, discovers mail, and revisits mail. It's hopeless.

Ingrid would have her mail under control if she followed single-piece flow. Single-piece flow tells her to handle one piece (one message) at a time till it's done. By "done" I mean she'll never look at that message again (except to answer a related message).

Here's how it works. Each time after Ingrid reads an e-mail message she does one of four actions:

1. She deletes the message (my favorite).

2. She files it away in a folder.

3. She forwards the message to someone else and then deletes or files it.

4. She answers the message and then deletes or files it.

That's it. She never opens a message and then leaves it in her Inbox. By the end of each day, every day, her Inbox is empty. She never misses a mail message, loses a message, or revisits a message.

Single-piece flow is efficient because it removes overhead and rework. There's overhead every time you context switch to look at a new message, and there's rework when you re-read a message. In single-piece flow, overhead is minimized and rework is eradicated.

Eric Aside
Sure, there are exceptions to the read-it-once rule, but they account for less than 5 percent of the mail I get in a day. Even those e-mail messages get filed in a special folder for more intensive attention. I also use Inbox rules to pre-filter mail from discussion groups.

If you're wondering how to get started and don't want to just delete all the mail in your Inbox, follow these steps:

1. Take mail you are actively working on right now and move it into a special folder.

2. Create folders for your remaining mail that correspond to your obligations and interests.

3. Search your Inbox for mail that fits each folder and move that mail into the folder.

4. Go through your special folder and clear out 90% of it using single-piece flow.

Now you are on your way.

Deja vu – all over again

Brian keeps breaking the build. You can punish Brian till he's afraid of checking in code regularly, but doing so only causes other problems.

A better solution is to give Brian a checklist. Checklists are wildly misunderstood, improperly developed, and underutilized. Regrettably, well-meaning compulsive people list everything possible Brian should check before he submits code to the build. That's not only a waste of time, it's also ineffective.

Brian's checklist should list only common causes of build breaks (less than one page’s worth). It should be in Brian's sight when he submits code. The goal is to be quick, easy, and effective.

Too long or complex and Brian won't follow it. Too short and it's not effective. Luckily, most mistakes are common mistakes. Thus, all the team needs to do is collect a list of the common or critical causes for build breaks and turn that into a checklist. The same is true for design review lists, code review lists, and all checklists.

Remember to update your checklists as your failure patterns change or they will become stale. Checklists prevent common errors and promote good habits. Any structured manual process you follow should have a simple checklist—unless you like being Brian the build breaker.

Eric Aside
You may have battles deciding what goes in a checklist. You shouldn't. Remember, you list what the data says are the common or critical failure points, not everything that ever happened.

For example, I added a checklist to my e-mail signature several months ago, which I check and then delete before I send every mail. It lists the two mistakes I've made for years, but haven't made since:

· Check the Cc and Bcc lines for undesired aliases

· Ensure the subject line is accurate

Slip sliding away

Suresh's software squad slipped their schedule on successive sprints. Bad news for a service—or any project. Is it time to work weekends? No. Is it time to slap the squad silly? No. Is it time for single-piece flow and checklists? Yes.

Suresh's squad is made up the usual way—a few PMs including a service engineer, a bunch of developers, and a similar-sized bunch of testers. The PMs write specs, the developers code them, and the testers test them. The squad is using Scrum-like Sprints with a nicely prioritized backlog of features.

Unfortunately, the PMs are creating specs faster than can be implemented. They waste time and effort on specs that change or are cut before they see daylight. The developers and testers jump from feature to feature as they get blocked. Nothing is in sync. Nothing gets finished. The schedule slips incessantly. In retrospectives, all Suresh's squad talks about is unblocking people.

Even though Suresh's squad is using Scrum-like Sprints, they aren't using single-piece flow. They aren't splitting into cross-discipline teams, with each team working on one feature at a time till it's done. They don't even have a checklist that defines done. It's doomed.

Once they create feature teams that spec, code, and test one feature at a time (sometimes called, feature crews) and a checklist that defines done, there's a chance for progress. The single-piece flow removes blocking issues because everyone is working on the same problem. Instead of jumping ahead, the checklist keeps the team honest, motivating them to work together, finish, and stay focused. Now the team doesn't waste time context switching and can tell how long it really takes to complete a feature, leading to confident scheduling and higher quality finished products and services.

Eric Aside
Many people wonder what to do with feature crew PMs once they finish specing, or developers once they hit code complete. For PMs there are two solutions—be part of multiple feature crews or be prepared to work with their dev and test peers on problem solving and development. For developers, the right solution is to work with the test team on tools, automation, unit tests, and component tests.

There's another clever solution written up by a former Microsoft employee, Corey Ladas. He calls it Scrumban and you can read about it on his and Bernie Thompson’s Lean Software Engineering site.

Our two weapons are

So there you have it—single-piece flow and checklists. Two enormously useful, remarkably simple, and yet woefully underutilized techniques for managing workload and building quality software.

Single-piece flow and checklists can be applied to individuals, small teams, and large divisions. They aren't controversial when used pragmatically, and have years of documented case history supporting their effectiveness.

Sure, you could create a whole grassroots movement around single-piece flow and checklists, but that seems a bit overblown for such simple ideas. Maybe you should just use them wisely. Enjoy the time you get back and the improvement in your results. The best things in life are often the most basic and simple.

Eric Aside

James Waletzky, has an amusing blog entry with a few checklist references entitled, Checklist? We don't need no stinking checklist!

I'm listening

ericbrec — Sun, 01 Mar 2009 10:00:00 GMT

It's Midyear Career Discussion time at Microsoft. Perhaps you just finished, but more than likely you're still trying to squeeze yours in. How'd it go? How will it go? For you? For your manager? Well, that depends.

It depends a bit on your prior performance and your manager's prior performance. It depends a bit on the feedback itself and how that feedback is given. It depends a bit on how your parents raised you and the comfort of your chair. But the biggest influence on the lasting impact of your Midyear Career Discussion is the way you and your manager respond to feedback.

Let me put this delicately to you. You have no frigging idea how to give and take feedback. Seriously—not one frigging idea. Think I'm wrong? You are only proving me right. If you actually knew how to give and take feedback your response would be a sincere and polite, "Thank you."

Thanks for the advice

In fact, there are only two valid responses to feedback, "Thank you" and "Go on."

The "Thank you" is simple and self-explanatory. Too bad most people don't use it. Most people defend themselves, explain their behavior and results, and describe how they are already taking the right steps.

Please, slowly and carefully shut your mouth, empty your mind, and listen. Perhaps you can even take notes. Then, when the generous soul is finished, say, "Thank you."

You don't say it to be polite. You say "Thank you" because you mean it. Your relationships, your life, and our products and services would reek far beyond their current stench if people were not kind enough to provide an outside perspective and help us improve. Thank goodness they are willing to do it. To ensure they continue it's essential to sincerely appreciate it.

Tell me more about me

In addition to "Thank you," a valid response to feedback is "Go on." As in:

§ "Could you talk more about that?"

§ "I don't quite understand—could you describe that further?"

§ "Thank you, that's helpful, what else can I do differently?"

Anything that encourages clear and continued feedback is appropriate.

Back off, man. I'm a scientist

What's inappropriate is anything that questions or cuts off feedback. This includes:

§ "I'm working on it." So what? You're doing the wrong thing, you haven't made much progress, or you are actually improving. Regardless, the feedback is valid and your comment is irrelevant and self-serving.

§ "I was trying to …" So that makes it better? Never confuse reasons with excuses. If you can get better, you should get better. No excuses.

§ "I disagree." So this is news? You're getting feedback. It's opinion. The fact that you like your current approach is not a revelation. When the feedback seems wrong, you've either missed something or left the wrong impression—that’s precious information.

Keep in mind that you don't have to follow whatever advice you get. All you are obligated to do is listen, consider the advice carefully, and thank the person for helping you.

Eric Aside

A particularly important time to keep your mouth closed, take notes, and simply say, "Thank you," is during an executive review.

Now it’s my turn!

Now that you know how to take feedback, it's time to learn how to ask for it and provide it. When asking for feedback and when providing it, there are three basic questions:

§ What is good [about what I'm doing or the work I've done]?

§ What could be better?

§ Any further comments?

You can structure feedback more, but the simplest, complete ask are those three questions. And it is those three questions that you want to answer when you provide feedback.

Eric Aside

Feedback is best provided immediately before or after behavior. The ideal is to provide positive feedback directly after desired conduct; and provide corrective feedback just before it’s needed. In other words, apply feedback at precisely the moment it is most constructive.

For example, a guy on your team sends a great email but forgets to copy a stakeholder. You reply to him right away, “Great mail—concise and insightful.” Later, just before he’s supposed to send the next update you write, “Remember to copy all stakeholders.” The reminder is more useful at that time.

We have come full circle

When providing your feedback, start with what's good, talk about improvements, add on your other comments, remind about improvements, and then reiterate what's good. That order is important.

§ You start with what you like. It sets up the conversation on an upbeat note and prevents the impression that all is lost. If you start with what's wrong, your listener may never hear what's right.

§ Next, you talk about ways to improve. Ideally, your listener should focus on just one change. One change is all that most people can handle at a time. Pick the most impactful improvement and emphasize it.

§ Of course, you'll have plenty of other thoughts that aren't as important. Feel free to mention those in the context of "a few other comments."

§ Then come back to your main message—the one or perhaps two improvements that would make the most difference.

§ Finish with what is going well. It's important to end on a positive note.

Eric Aside

Remember to always focus on the behavior or outcome, not on the person. People can't change who they are, but they can improve their actions and results.

We don't have much time

That's it. Being concise is important. If you want your feedback to matter it should be clear, consumable, considerate, concise, and centered on the receiver. Your feedback isn’t about you and your glorious knowledge; it is about helping the recipient.

If you are on the receiving end of the feedback you should be just as concise. Feedback is precious, whether it's from a customer, a peer, or your manager. Don't get in the way. Encourage it. Savor it. Appreciate it. Thank you.

Green fields are full of maggots

ericbrec — Sun, 01 Feb 2009 10:00:00 GMT

As I said in Nailing the nominals , the two keys to successful big projects (100K+ LOC) are thinking ahead and defining done. Thinking ahead is about design and planning. Defining done is about setting a quality bar and sticking to it. Yet many big projects...(read more)

Sustained engineering idiocy

ericbrec — Thu, 01 Jan 2009 10:00:00 GMT

Plumbing channels waste water into a series of larger and larger pipes till it is expelled. That's because sewage flows downstream, which explains the quality of goods that test, operations, and sustained engineering teams receive. After all, they are...(read more)

De-optimization

ericbrec — Mon, 01 Dec 2008 10:00:00 GMT

Why? Why! Why do managers make stupid decisions that cause devastating churn and tawdry results? And it's not just managers, though they are particularly proficient at promoting poor performance—architects, leads, and individual contributors flood the...(read more)

NIHilism and other innovation poison

ericbrec — Sat, 01 Nov 2008 20:13:00 GMT

Is innovation the act of creating something new (as the dictionary claims) or is it building upon the work of others? To me this is a fundamental question that Microsoft as a company and as a culture has gotten horribly wrong. We deal with the consequences...(read more)

Nailing the nominals

ericbrec — Wed, 01 Oct 2008 09:00:00 GMT

People are always looking for that amazing breakthrough technology or process that solves all their problems—enhances their love life, trims their waist, and improves the productivity of their development team. That's why process manias like Agile and...(read more)

I would estimate

ericbrec — Mon, 01 Sep 2008 09:00:00 GMT

When I'm discussing challenges with fellow engineers, the first topic that comes up isn't estimation—it's career and people challenges. That's why those issues are so rampant in these rants. However, "How do you generate task estimates?" is always among...(read more)