Design Your Agile Project, Part 4

If you are thinking of agile as part of a program, each team has to have its own approach to agile. Why? Because each team has its own risks and problems. You don’t need to standardize agile for anyone. If you treat people as if they are adults and explain the principles that you want (working software all the time and expose the interdependencies), provide training or whatever other resources they need, you are likely to get what you want.

That’s why I wrote Design Your Agile Project, Part 1 for teams who are collocated, and can use any approach to agile. Design Your Agile Project, Part 2 is for teams who have many challenges, but are collocated, and can work through those challenges. Design Your Agile Project, Part 3 is for teams who are geographically distributed and have to think about what to do.

In the program, what you need is for each team to deliver, all the time. The program wants as close to continuous delivery as possible. You can reduce the interdependencies—or plan for them. You can certainly expose them.

Feedback is Necessary

Did you see Jason Yip’s tweet (@jchyip) the other day, where he quoted this, “”Large organizations…lose their resilience simply because the feedback mechanisms…have too many layers of delay and distortion.”

This is why you cannot standardize on anything for any team in a program. Why? A program needs resilience. It needs to be able to release early and often. Just because it’s a program does not mean it does not need to be able to obtain feedback.

Each team must know the principles:

  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

Teams use agile and lean principles. Management treats the people on the teams as if they are adults. The teams look at their own issues and design their own approach to agile/lean, always keeping in mind the idea that they need to deliver early and often.

Now, let’s talk about what happens when you want to meld these teams into a program.

Each Team is the Heart of the Program

You might think that things roll down from the program manager or the core team. Not in my world. This is where each team’s autonomy, each team’s ability to make its own decisions about how it implements its approach to agile or lean is key.

The teams are the heart of the program. All of the teams: the core team, the technical teams, the teams that the core team represents.

This is a change from traditional process thinking. It’s a change from traditional program management thinking. This kind of thinking requires that the teams know how to do agile already, and are new to the program, not to agile. This kind of thinking also means that the program manager is a servant leader.

In a program, you will have interdependencies. You want to minimize them. How do you do that? By reducing batch size, the size of each feature. By coordinating the features with a program roadmap. And, by looking at the value of each feature, not its cost (estimate).

That means the teams need to become good at delivering, not estimating. It also means the product owners need to become very good at creating ranked backlogs for the teams, and changing them. It means that the program needs a roadmap that can and does change.

Remember, agile is about the ability to change, because the teams get to done at regular intervals, whether those intervals are iterations or because the teams work in flow.

What If the Teams are New to Agile?

What if you want to have a program with teams that are new to agile or lean? You can do anything on your program. You need to assess your risks. Let’s look at the Cynefin framework to see where your risks might place you, if your teams are new to agile.

CynefinIf your teams are new to agile, and they are all in one physical location, and they know the domain of the product under development, i.e. you are only changing how they are developing, maybe you are just in the Complex part of the framework. You are changing the culture of the program.

However, if you have new-to-agile teams, who don’t know the product domain, who are geographically distributed or dispersed from one another, and you want to transition to agile, do you see that you might be in the Chaotic part of the framework? That you have no way of knowing the risks?

That is much more difficult.

Let me provide you an example. Imagine that you are working with developers in Europe who have a 15-person development team. They have only programmers on their team. They have never worked with testers. Why? They have never seen the need to do so. They have been successful, according to them, up until now.

You are in New York, where the product management is. You know the product domain. The developers? Well, maybe not so much.

Several years ago, I consulted to a company that had this precise organization. They were going to “revolutionize aerospace.” Only the product managers understood the aerospace information. The developers had no domain expertise and they were several timezones away. The developers had worked together before, but had never worked with testers. They had never seen the need. They had never worked on a regulated product before.

When I suggested they had “unknowable unknowns,” and that their risks were higher than they thought they had, the senior management laughed at me. I told them yes, agile was fine, but I thought they should use one- or two-week iterations with kanban boards to expose their bottlenecks.

They ignored my advice. The company went with four-week iterations, spent a pile of money, had no product to show after 18 months. Oh, the developers bandied words such as “refactoring” and “TDD” and “BDD.” What they did was BDUF (Big Design Up Front) because they had no idea what they were doing. The company went under.

What do you do when not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change?

Don’t panic! You work in ways to reduce your risk.

Stay tuned for Part 5.

Posted in agile | Tagged , , , , , , | Leave a comment

Manage Your Job Search is Out; You Get the Presents

I am happy to announce that Manage Your Job Search is available on all platforms: electronic and print. And, you get the presents!

For one week, I am running a series of special conference calls to promote the book. Take a look at my celebration page.

I also have special pricing on Hiring Geeks That Fit as a bundle at the Pragmatic Bookshelf, leanpub, and on Amazon. Why? Because you might want to know how great managers hire.

Please do join me on the conference calls. They’ll be short, sweet, and a ton of fun.

Posted in books | Tagged | Leave a comment

Who Solves Which Problems?

Many years ago, I was part of a task force to “standardize” project management at an organization. I suggested we gather some data to see what kinds of projects the client had.

They had short projects, where it was clear what they had to do: 1-3 week projects where 2-4 people could run with the requirements and finish them. They had some of what they called “medium-risk, medium return” projects, where a team or two of people needed anywhere from 3-9 months to work on features that were pretty well defined. But they still needed product managers to keep working with the teams. And, they had the “oh-my-goodness, bet the company” projects and programs. Sometimes, they started with a small team of 2-5 people to do a proof-of-concept for these projects/programs. Then, they staffed those projects or programs with almost everyone. (BTW, this is one of the reasons I wrote Manage It! Your Guide to Modern, Pragmatic Project Management. Because one size approach to each project does not fit all!)

The management team wanted us, the task force, to standardize on one project management approach.

In the face of the data, they relented and agreed it didn’t make sense to standardize.

It made a little sense to have some guidelines for some project governance, although I didn’t buy that. I’ve always preferred deliverable-based milestones and iterative planning. When you do that, when you see project progress in the form of demos and deliverables, you don’t need as much governance.

There are some things that might make sense for a team to standardize on—those are often called team norms. I’m all in favor of team norms. They include what “done” means. I bet you’re in favor of them, too!

But, when someone else tells you what a standard for your work has to be? How does that feel to you?

I don’t mind constraints. Many of us live with schedule constraints. We live with budget constraints. We live with release criteria. In regulated industries, we have a whole set of regulatory constraints. No problem. But how to do the work? I’m in favor of the teams deciding how to do their own work.

That’s the topic of this month’s management myth, Management Myth 28: I Can Standardize How Other People Work.

If you think you should tell other people how to do their work, ask yourself why. What problem are you trying to solve? Is there another way you could solve that problem? What outcome do you desire?

In general, it’s a really good idea for the people who have the problem to solve the problem. As long as they know it’s a problem.

How about you tell the team the outcome you desire, and you let them decide how to do their work?

Posted in management | Tagged , , , , , | 4 Comments

I’m a Management Expert on Twitter

I’ve just been named to one of the 100 top management experts on Twitter. See Keeping Up with #Management:100 Experts on Twitter. You have to page down under “Executive Coaching” to see me.

I’ll return to editing my “Design Your Agile Project” series now. It needs serious editing. That’s why you haven’t seen the next post yet.

Posted in management | Tagged , , | Leave a comment

Design Your Agile Project, Part 3

What do you do  for geographically distributed teams, if you want to move to agile?

First question: does the team want to move to agile? Or, does the management want to move to agile? I am serious.

I might take the same actions, but for different different reasons. In either case, the team needs to learn about what agile and lean means, and how to do agile. In both cases, the team needs help and protection from management.

Why Does a Geographically Distributed Team Need Help and Protection from Management?

Types of Teams

Types of Teams

Managers create geographically distributed teams for many reasons. Some reasons are that there are smart people all over the world. In that case, managers create feature teams.

When managers create dispersed teams, teams with one and two people in disparate locations in far-flung locations (more than 60 meters away), managers are under the impression that “experts” can perform jobs better than teams can.

When managers think that “experts” can perform jobs better, they create bottlenecks in the work. Bottlenecks prevent flow. Bottlenecks prevent agile or lean from working. It does not matter if you want agile or lean. You won’t get either with a bottleneck. You have to overcome the bottleneck.

Can you make a geographically distributed team work in an agile way? Yes. Let’s go back to the principles.

Our principles of agile or lean:

  1. You need to see all the work in progress.
  2. You want to flow work through the entire team.
  3. You want to see working software, sooner, rather than later.

If you, like me, don’t care how we get there, we have options.

How Could a Team Take These Principles and Create Their Own Agile Approach?

Let’s take one thing at a time.

Let’s assume the team is not accustomed to working on small items of value. If you are like many of my clients, this is the case. What would it take for the team to start working on small features that deliver value?

Let’s think about the product again:

Potential Release Frequency

Potential for Release Frequency

What kind of potential for release frequency does the team have? That colors the team’s thinking. The more potential for continuous deployment, the easier it is to work on small items of value.

This is where I like to introduce the notion of spikes and timeboxes. I ask the team to take their smallest feature, and work together on it. They don’t always have any notion of “together,” either. They say things such as, “We need …” and list the impediments to their ability to work together.

Now we see the need for management support.

Project Management is Not a Dirty Word; Neither is Management

I know that some of you dislike the idea of agile project managers. I know some of you positively hate the idea of management in agile organizations. Let me suggest that for teams transitioning to agile, there is a place for management. That place is creating an environment in which the team learns how to self-manage.

There is no place for command-and-control project managers—never has been, never will be. Unless it’s time for lunch. Sometimes, teams need people to say, “Lunch-time!” But even that isn’t command-and-control. That’s someone saying, “I’m taking care of my need to eat. Want to come along?”

It’s the same thing for a team with a lot of risk and a lot of unknowns. A team where the normal, out-of-the-box agile solutions don’t work. Why would you let a team like that flounder?

That team needs everyone to lead. And, it often, but not always, needs someone to represent that team to management. Why? Because management doesn’t understand agile yet. That part might come now, and it might come later. But in an agile transition with many unknowns, it almost never happens at the beginning, even if management is saying, “Please go agile.”

A geographically distributed team needs management support. It does not need command-and-control. That team does need support.

That’s when I ask the person working as the project manager to start removing impediments. The team creates their own visual board. (Yes, a distributed team almost always needs a tool. I like to start with cards on a wall first, take pictures of it. Once a team knows how they like to work, then they choose a tool.) The team decides what the length of their timebox is for this feature, if they want to use iterations. They decide how to spike it. They start making decisions.

That team especially needs to understand the problem of bottlenecks, experts, and how to stop needing experts.

After they practice this a couple of times, they have the confidence they need to do this more times on their project. They can call this agile, but it might not have a real name. It’s a mishmash of timeboxes and kanban, but it works for them. Does it matter what it’s called?

The Team Needs Management to Remove Obstacles

Teams might need management support. For example, I often discover geographically distributed teams don’t have enough testers. Well, you say, that team flunks the “we have all the cross-functional roles to do the work” part of agile. Yes, and what if they don’t know that? What if they want to try agile? What if they want to work through their obstacles and impediments? They need someone to represent them to their management, while they try to test as they proceed, right?

You could substitute “database admin” or “GUI designer” or whatever it is you need for tester in the above paragraph. Whenever you need someone to advocate on behalf of the team to management, you might want an agile project manager. Not someone to say, “When is the project going to be done?” Nope, not that kind of a PM. Someone to say, “What does the team need? I can help acquire that.”

PMs who provide servant leadership to the team, and represent what the team has accomplished to the rest of management can be invaluable. They can help the team understand its process and facilitate what the team can do if the team gets stuck. These are agile project management skills.

At this point, the team can try several approaches I suggested in these posts:

You might have an even better alternative than the ones I suggested.

Do you need a project manager? No. Do you need a servant leader? In my experience, yes. Maybe in your experience, no. I would love to hear from you, if you have a geographically distributed team that does not have a servant leader.

How Does This Team Evolve?

CynefinSome of my clients who are committed to agile have evolved their dispersed teams to be feature teams in multiple places. That has worked very well for them.

That has allowed each team to transition from the Complex to the Complicated. They now have collocated agile or lean teams. They can design their agile projects, as in Part 1. They retain the value of smart people all over the world. They don’t have the aggravation of trying to meet in different time zones for a project. They still have it for the program.

Some of my clients are still trying to make the dispersed teams work. It’s really hard. You might want to read my paper about the common problems on these teams.

Where are we now?

In Design Your Agile Project, Part 1, we discussed a straight-on approach to using whatever approach to agile, because it was obvious where you were.

In Design Your Agile Project, Part 2, we discussed looking at your system of work, and thinking about your unknowns. You need to think about your risks, and consider what you need to experiment with, to design your own agile project.

This part, part 3, is a continuation of part 2. It matters because you might need a servant leader who might be called a project manager. The title matters, because especially on a geographically distributed team, you are bridging the gap and the culture between the old way of working and the new way of working. I still think it’s Complex. Some of my clients think it’s Chaotic because they have so many impediments.

Whatever it is, you need data to take your next step.

Posted in agile | Tagged , , , , , , | 1 Comment

Design Your Agile Project, Part 2

The point of using agile is to get finish something valuable-to-the-business quickly, to get feedback. Why? For several reasons, but the first one is so you can change the project’s priorities. The second is so you can change the project portfolio. The third is to get feedback on what you’ve done. Okay, you can exchange one, two, and three if you like. For me, those are the top three reasons to get to done every few days to two weeks. They are right behind each other in priority. Agile is all about change.

This is why every project needs to design its own way to get to done.

If you have a single collocated team, who understands how to deliver value quickly you might be in the situation described in Design Your Agile Project, Part 1.

What happens when you have more unknowns? What if your organization is “addicted” to waterfall and long projects? When you can’t see the people on your project, because everyone isn’t in the same place? When you have a lot of technical risk, such as technical debt? How about when you’re starting a program and everyone is transitioning to agile (oh please, don’t do this). Or, you’re new to agile, and you don’t have training. I have a question: would you drive a car on the road with no training, either?

Rethinking What to do When Your Project or Organization is Full of Unknowns

CynefinLet’s discuss the principles of designing your agile project when you have more unknowns. Let’s start with a common problem: an organization “addicted” to waterfall and long projects. And, they’ve heard about this “agile” stuff, and they want to try it.

If you have heard about the many places Scrum has failed, this is classic. Scrum says, “replace your old culture with this new culture.” Wow, that’s a big shift. If you look at the Cynefin framework, you can see that for an organization addicted to waterfall, long projects and big requirements, they are not in Complicated. They are in Complex. Why? Because they have too many unknowns.

Here’s what I see when I do assessments in these organizations:

  • Much multitasking to address emergencies.
  • No project portfolio management
  • Their requirements are so large, it takes them forevvveerrr to release anything
  • Because their requirements are so large, and because their releases are so long, that increases the demand for emergencies: patches, interim releases, firefighting.

There could be more. This is enough.

In that case, you want to look at the Cynefin framework, and say, “What does the Complex side of the framework say?” It says we should consider emergent practice. We should not only consider out-of-the-box solutions. We have to probe-sense-respond.

What do we need to accomplish? Getting to working software, at the end of an iteration. Or, in flow. We want a feature, in flow, in a day or two, maybe three. We want completed features, with no leftover wasted work (unfinished features) at the end of an iteration. We want to be able to change what we do after the iteration, or after the feature. How do we accomplish that, from the team’s perspective? Let’s forget labels, and focus on the team.

What’s the First Thing the Team Could Do?

I like to ask, “How little can we do?” Too often, the team has been asking “How much can we do?” Starting with that question helps.

Thinking in inch-pebbles, timeb0xing work, spiking work, all of that helps to learn how to work small.

Sometimes, when we have stories, and we don’t know how to break them apart, we ask, “What’s the first thing that could add value?” Maybe that’s a good question here. You could ask, “What’s the first thing the team can do?” Or, “What’s the first thing we can do that would help us get to done in a one- or two-week iteration?” Or, “How do we finish a feature in flow (kanban)?”

Often, for teams who are in the Complex side of the framework, I suggest these things:

  1. Start a kanban board. You need to see what your actual process is. You need the visuals.
  2. Decide on your work in progress limits, and stick to them, at least for a week.
  3. Retrospect and reflect on those limits, the progress you’ve made and anything else that arose. Where are you, as a team? What progress did you make? What do you want to keep, add, change?

Notice how this is not out-of-the-box agile or lean. It’s a way to start a team moving from the Complex to the Complicated. Once a team has been through the first week, they iterate, keeping in mind these principles:

Let’s Review the Principles:

  1. Get to done, either in flow or iterations. Why? Because we want to develop working software.
  2. Keep the iterations short, either one or two weeks. Longer is not better. Why? It’s too long to allow for frequent change. Why? Because we need to allow for change in the project. That way, we can get feedback on the features, change the project’s priorities, and manage the project portfolio.
  3. Find a way to connect as a team, regardless of how you do so. Real-time rituals are not good if they make everybody crazy from lack of sleep. Why? We need sustainable development, even if real-time rituals are the best.
  4. Find a way to reflect as a team. Surrogate reflection is not good. Why? How can someone else substitute for what’s really going on in a team?

Where are we now?

Nobody has changed roles. Nobody has changed culture. We are looking at our process, and making things smaller for a while. We are reflecting. All of this in order to simplify, to move from the Complex to the Complicated.

Remember, I have only discussed what I have done with teams who are collocated, who have had problems with too-large features, long waterfall projects, and many emergencies. I haven’t addressed the issues of distributed teams yet. They are next.

I hope you stay with me as we move to part 3.

Posted in agile | Tagged , , , , , | 3 Comments

Design Your Agile Project, Part 1

The more I see teams transition to agile, the more I am convinced that each team is unique. Each project is unique. Each organizational context is unique. Why would you take an off-the-shelf solution that does not fit your context? (I wrote Manage It! because I believe in a context-driven approach to project management in general.)

One of the nice things about Scrum is the inspect-and-adapt approach to it. Unfortunately, most people do not marry the XP engineering practices with Scrum, which means they don’t understand why their transition to agile fails. In fact, they think that Scrum alone, without the engineering practices, is agile. How many times do you hear “Scrum/Agile”? (I hear it too many times. Way too many.)

I like kanban, because you can see where the work is. “We have a lot of features in process.” Or, “Our testers never get to done.” (I hate when I hear that. Hate it! That’s an example of people not working as a cross-functional team to get to done. Makes me nuts. But that’s a symptom, not a cause.) A kanban board often provides more data than a Scrum board does.

Can there be guidelines for people transitioning to agile? Or guidelines for projects in a program? There can be principles. Let’s explore them.

The first one is to start by knowing how your product releases, starting with the end in mind. I’m a fan of continuous delivery of code into the code base. Can you deliver your product that way? Maybe.

How Does Your Product Release?

I wish there were just two kinds of products: those that released continuously, as in Software as a Service, and those with hardware, that released infrequently. The infrequent releases release that way because of the cost to release. But, there’s a continuum of release frequency:

Potential Release Frequency

Potential for Release Frequency

How expensive is it to release your product? The expense of release will change your business decision about when to release your product.

You want to separate the business decision of releasing your product from making your software releaseable.

That is, the more to the left of the continuum you are, the more you can marry your releases to your iterations or your features, if you want. Your project portfolio decisions are easier to make, and they can occur as often as you want, as long as you get to done, every feature or iteration.

The more to the right of the continuum you are, the more you need to separate the business decision of releasing from finishing features or iterations. The more to the right of the continuum, the more important it is to be able to get to done on a regular basis, so you can make good project portfolio decisions. Why? Because you often have money tied up in long-lead item expenses. You have to make decisions early for committing to hardware or Non Recurring Engineering expenses.

How Complex is Your Product?

Let’s look at the Cynefin model to see if it has suggestions for how we should think about our projects:

CynefinI’ll talk more about you might want to use the Cynefin model to analyze your project or program in a later post. Sorry, it’s a system, and I can’t do it all justice in one post.

In the meantime, take a look at the Cynefin model, and see where you think you might fall in the model.

Do you have one collocated cross-functional team who wants to transition to agile? You are in the “known knowns” situation for agile. As for your product, you are likely in the “known unknowns” situation. Are you willing to use the engineering practices and work in one- or two-week iterations? Almost anything in the agile or lean community will work for you.

As soon as you have more than one or two teams, or you have geographically distributed teams, or you are on the right hand side of the “Potential for Release Frequency” chart above, do you see how you are no longer in the “Complicated” or “Obvious” side of the Cynefin model? You have too many unknowns.

Where Are We Now?

Here are my principles:

  1. Separate the business decision for product release from the software being releaseable all the time. Whatever you have for a product, you want the software to be releaseable.
  2. Understand what kind of a product you have. The closer you are to the right side of the product release frequency, the more you need a program, and the more you need a kanban to see where everything is in your organization, so you can choose to do something about them.
  3. Make sure your batch size is as small as you can make it, program or project. The smaller your features, the more you will see your throughput. The shorter your iteration, the more feedback you will obtain from your product owner and “the business.” You want the feedback so you can learn, and so your management can manage the project portfolio.
  4. Use the engineering practices. I cannot emphasize this enough. If you do not keep your stories small so that you can develop automated unit tests, automated system tests, use continuous integration, swarm around stories or pair, and use the XP practices in general, you will not have the safety net that agile provides you to practice at a sustainable pace. You will start wondering why you are always breathless, putting in overtime, never able to do what you want to do.

If you have technical debt, start to pay it down a little at a time, as you implement features. You didn’t accumulate it all at once. Pay it off a little at a time. Or, decide that you need a project to prevent the cost of delay for release. If you are a technical team, you have a choice to be professional. No one is asking you to estimate without providing your own safety net. Do not do so.

This post is for the easier transitions, the people who want to transition, the people who are collocated, the people who have more knowns than unknowns. The next post is for the people who have fewer knowns. Stay tuned.

Posted in agile | Tagged , , , , , | 3 Comments

Overcoming Several Pitfalls of Agile Transition: Webinar, March 10, 2014

Join me for a webinar on March 10, 2014 at 7pm Eastern. My topic is “Overcoming 7 Common Pitfalls of Transitioning to Agile in Software Engineering.” I’m speaking as part of the Graduate Professional Studies Spring 2014 Guest Speaker Series.

Register here.

P.S. If you missed the webinar, here is the audio recording. Enjoy!

Posted in webinar | Tagged , , , | 6 Comments

Debugging Your Geographically Distributed Agile Team Posted

I have a new column up on project It’s called Debugging Your Geographically Distributed Agile Team. (You have to register to read it. Registration is free.)

You can do agile with geographically distributed teams. You might not be able to do Scrum. You have other choices of approaches.

Helping a team form is tough. This article, which is true, shows how tough it can be.

Do you have similar experiences? Different experiences? Let me know. I’d love to hear from you.

Posted in agile | Tagged , , , | Leave a comment

Understanding State vs. the Micromanagement Trap

Back when I was a Director of many things at one company, we had an urgent patch to go to a customer. My VP wanted it “yesterday.” Well, time only goes in one direction.

I gathered my continuing engineering team, explained the pickle we were in. “Everyone wants this patch right away. However the customer is truly pissed. I want to know that we have a fix that works. And, while you are working on it, I will need to know updates every morning and every afternoon. I will run interference for you, as well as I can.”

Everyone groaned. They knew what this meant. We had a small company. The corporate management was just down the hall from our offices. Even though I said I would run interference, nothing would prevent the VP of Engineering, the CEO, or the CTO from popping their heads in “to see what’s going on.” Everyone wanted to make the customer happy, right now.

At the time, I didn’t know about kanban boards. I knew about spreadsheets and email. I had four people working on this fix. I knew what they were all doing. So did they.

They managed themselves. Their offices were close to each other. Every day, about noon or so, they gathered in my office, so I would have the most up-to-date status. It wasn’t quite a standup, because some of the work was what we would now call spikes. (At first, we had no idea what was causing the problem.)

As we identified the problem, I explained to management on behalf of the team how they narrowed down the problem and identified it. Then I explained to management on behalf of the team how they were debugging the problem. Then I explained to  management on behalf of the team how they were testing the fixes they proposed. Then I explained to management how they were packaging the fix they had decided on.

If we’d had a visual board, this might have been easier. I used email. It took close to a month. It was a very difficult fix.

Notice what I did:

  1. I explained to the team the results I wanted: as quickly as possible, but it had to be right. Right trumped shoddy.
  2. I explained that I needed information, and how often I needed it.
  3. I ran interference and kept the rest of the management team informed, daily. My goal was no surprises.
  4. I explained things on behalf of the team, so they got the credit. I was doing my management job, not technical work.

Because our management, and I could share the interim results with the customer, the customer was not happy during this month, but they were pleased to know we were working on the fix. By the time they got the patch, they were very pleased. It worked.

I did not micromanage my people. I understood their state. There is a big difference. And that is the topic of this month’s management myth, Management Myth 26: It’s Fine to Micromanage.

If I had stood over their shoulders, and asked, “Is it done yet?” I suspect I would have had different results.

My team understood that I was doing my management job. I didn’t prevent all other senior management interference. But, I prevented most of it. In return, they were free to work together to accomplish their goal: a fix that didn’t upset the rest of the system and really fixed this customer’s problem.

It’s easy to fall into micromanagement. We, as technical people are terrific problem solvers. We excel at it. We want to help other people solve their problems. Micromanagement is inflicting help on other people. It’s not helpful. It’s irritating and prevents other people from doing their jobs.

Have you caught yourself micromanaging? If so, what made you stop?

Posted in management | Tagged , , , | 4 Comments