Three Questions to Ask when Being Micromanaged

One of the foundational principles of agile and Scrum is a belief in the power of self-organizing teams. This makes a micromanaging boss, ScrumMaster or product owner a particularly difficult problem for agile teams.

I’ve found asking three questions helpful in dealing with micromanagers.


The first question is Who? Who is being micromanaged? If you are being micromanaged but the rest of the team is not, this tells you it is your own performance that someone is worried about. If so, you’ll need to improve your own performance and that stakeholder’s view of your performance.

But if your entire team is being micromanaged, the behavior is just part of who that stakeholder is.

To determine whether it’s just you or your entire team being micromanaged, spend a sprint or two noting what types of things draw the micromanager’s attention. Log all micromanaging activities so you can look back at the data and determine who is being micromanaged.


A log of micromanagement activity will also help you answer the second question: When is the micromanaging occurring?

Does the stakeholder micromanage shortly before or after a meeting? For example, a product owner might leave their customer call every Tuesday feeling stressed and more inclined to micromanage. Or a Scrum Master might be prone to micromanage the day before the monthly meeting with the engineering VP.

Some people are more prone to micromanage at a specific time of day. A boss early in my career was particularly prone to micromanaging before his first cup of coffee.

Others may be more prone to micromanagement at specific times during an iteration. Perhaps the person you’re dealing with is most prone to micromanaging during the last few days of the iteration when he or she gets nervous about whether everything will get done. Again, log this type of information so you can later look for patterns.

I use a spreadsheet with the following columns:

Date: The actual date (e.g., March 8, 2017). This usually won’t help identify patterns but can be useful if you look back on the data and need to remember what might have been going on in the organization at the time.

Day of Week: Sometimes micromanaging occurs most frequently on certain days (e.g. Friday) so note the day of the week.

Day of the Sprint: To help see if micromanaging occurs most frequently at certain points within a sprint, note the number of days into the sprint when the micromanaging occurred. For example “Day 3” or perhaps “7 / 10” to indicate it occurred on day seven of a ten-day sprint.

Time: Note the time of day when the micromanaging occurred (e.g., 10:15 A.M.)

Who Was Being Micromanaged: Note whether it was you personally, the entire team, or perhaps a teammate being micromanaged.

What Was Being Micromanaged: Note the issue in this column.

Context: Note whether the micromanaging coincided with anything else occurring within the sprint, project or organization. Did it occur right before or after a meeting? Which meeting? What was occurring during the iteration overall?

Notes: Include anything additional worth remembering about the incident. You can see a sample in the following table.



Day of

Day of
Time Micromanager Who? What? Context Notes
March 8 Wed 6


Anne me Story about adding data sources    

Anne asked me for the 3rd time in two days how this was going.

March 8

Wed 6 2:15 Arie team Next week’s new client launch  

Arie emailed the full team to remind everyone how important the new client launch is


March 8

Thurs 6 9:28 Anne teammate  

Story about Salesforce integration

While en route to daily scrum, Anne asked me to tell Ashish

to see her sometime about the story he’s working on for her.

Ashish has been providing her a daily update already as she requested.



After you’ve logged a couple of weeks of micromanaging activities, it’s time to ask the third question: Why is the micromanaging happening?

Scan your log looking for patterns. See if there are triggers that create the micromanagement. Perhaps your product owner micromanages you after her weekly meeting with her boss.

Perhaps your line manager is prone to micromanaging at the end of the month when he has to prepare a report for his boss.

Based on the patterns you see, try to identify conversations that may be worth having with whoever is micromanaging. You’re unlikely to get far by merely saying, “Please stop micromanaging.” Instead, talk to micromanagers in an attempt to learn what concerns them that they’re behaving as they are.

Once you’ve identified some of the triggers for micromanaging, it’s time to anticipate and eliminate those triggers.

Anticipate and Eliminate

If you can anticipate micromanaging behavior by noticing when it occurs, work to eliminate the trigger. Often you can do this by proactively providing information to the micromanager.

For example, if you know your product owner gets stressed and micromanages after a weekly meeting with her boss, schedule a meeting with your product owner ahead of that meeting. Be sure your product owner is well informed and prepared for her meeting.

Proactively provide information to stakeholders who are prone to micromanagement. Try to do it just in time so they have (and remember) the information in advance of whatever triggers them.

Avoid creating burdensome new processes for yourself. But you can assert control over a stakeholder (or boss) relationship by proactively providing information rather than waiting to be asked for it and then being forced to provide it on someone else’s schedule.

Some People Are Incurable

By following the advice here, you won’t always be able to eliminate micromanagement. Some stakeholders are incurable micromanagers. But the tips here will help you take greater control over most situations and generally make them more tolerable.

Download the Micromanagement Log

Download the Micromanagement Log

Get a copy of the Micromanagement Log PDF

Get my PDF Now!
Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at If you want to succeed with agile, you can also have Mike email you a short tip each week.