Something to be aware of when one manages a team is the tendency to ‘micro-manage’ them. What is micro-managing? You know what it is! I’m sure you all have worked with a manager that wanted constant updates, that wanted to take every decision and was absolutely terrified of you doing something that they weren’t 100% in agreement with. Yeah, that. The WhatsApp messages at all hours asking for status updates and so on. The flip-flopping on decisions. You get the picture.
The problem with micro-managing is that it doesn’t work. You end up in the sort of spiral that comes when relationships have no trust - lack of engagement from the team, retention issues, poor quality output leading to less trust leading to more micro-management and so on.
What’s worse is that micro-management kills the very thing that makes teams productive. As a wise man once said -
Never use a lever as a hammer. You don’t get leverage, you get hemorrhage.
Teams provide leverage because the whole is greater than the sum of its parts. The diversity of skills, knowledge and context in a team beats the skills, knowledge and context in any one single person - no matter who that person is. Not understanding this leads to teams where the manager dictates the problems and their solution without allowing the team to bring their minds to bear on the problem. This necessarily leads to poor outcomes.
Are you a micro-manager?
It’s entirely likely that you are a micro-manager. It’s also likely that I am a micro-manager. Just like attending an Alcoholics Anonymous meeting, it’s just better to accept this as a starting point if you’re in doubt. With that out of the way let’s see what we can do to stop micro-managing.
How to stop?
There are two tools I use to reduce my ability to micro-manage. “Cadence” and “Blast Radius”.
Cadence -
I use the word ‘cadence’ to imply a rhythm. Everything in nature operates with a cadence. The rhythm of day following night, the change of seasons and also beating of our little micro-managing hearts. Perhaps your work also follows a rhythm - Sprints, Quarters, Financial Years and so on.
The thing about software is that it is the only industrial artefact that we produce that is crafted entirely by hand. It is therefore part industrial and part artisanal. While artisans are free to work at their own schedule, there is no factory that doesn’t operate with a given cadence. And so your software creating factory, your software ‘engineering’ team must also operate at a cadence.
What does this have to do with micro-management?
One of the easiest ways to stop micro-managing is to do all your management at a given cadence. Instead of popping your head over the cubicle wall and asking questions whenever the fancy strikes you, set up a regular schedule for this. On projects that are going well, weekly is enough. Where your attention is needed more frequently, daily will also do. If you need to do a cadence meeting more than once a day you’re doing something wrong.
What does a cadence meeting look like?
All my cadence meetings follow a similar pattern
Review the last cadence meeting's notes and action items. Read the cadence update which should have arrived before the meeting.
Review the relevant dashboards, metrics and trackers.
Discuss any issues in executing the action items.
Identify issues and either discuss them until solved or work out a plan.
Note down action items for the team to execute before the next cadence meeting.
That’s basically it. Super simple and works for anything.
True story - Cadence works for anything. Frustrated with our slow hiring, we established a cadence meeting for Engineering Recruitment.
Within a few cadence meetings we’d ironed out a lot of the kinks in the pipeline, each hiring manager was aware of the metrics relevant to them and no blocker or escalation went more than a week without being addressed.
Cadence Meetings allow the team to execute without constant supervision knowing there is a safety net - any poor decisions or escalations will be reviewed by their manager regularly and on the record. This keeps the manager honest as each decision is noted at the time it is taken.
Are you doing it right?
If you’re doing it right the cadence meetings will, in a few iterations, become deadly boring.
The first few meetings will be overwhelmingly confusing. There will be no clarity on the metrics you want to look at. There will be poor problem definition and no solution in sight, let alone action items. Enjoy this time - this is where you get to do problem-solving. After a few iterations you will understand the problem definition and the dashboard and metrics that reveal this problem objectively. Get here first because - that’s a whole other post on feedback loops. Suffice to say for now that you should be able to ‘see’ the problem you’re trying to solve on a dashboard first, before attempting to solve it.
Once you can see the problem you can start working on solutions. Once a solution has been agreed on, let the team do the work. Sure you can discuss the problem on Basecamp whenever you want but that should come from the team. If it doesn’t, there’s nothing to do until the next cadence meeting. If you’re uncomfortable, reduce the time to the next one but don’t interfere between meetings.
At the next meeting, review the dashboard and any decisions taken by the team in the interim. Ask them to work through their reasoning and provide your sage guidance at this point. Over-rule any decision that won’t work. Not micro-managing doesn’t mean poor decisions can pass. Discuss whether the solution is working - your dashboards will tell you this objectively. If they don’t yet, change the dashboard. More solutioning, more noting down of action items and voila - nothing to do until the next cadence meeting.
Rinse. Repeat. After a while the dashboards settle, the problem is well known, the solution is agreed upon and execution is happening. Now most decisions are micro-decisions. You don’t need to know about them necessarily.
At this point the length of the meeting will reduce automatically. You will also want to decrease the frequency of the cadence meeting. In the best case, the cadence dashboards are just emailed out and no meeting is necessary any more, though this usually means that problems will re-appear the moment you take your eye of the ball, so don’t rush into turning these meetings into emails.
Cadence is how you scale as a manager.
The best teams have leaders who have a balance between outward and inward focus. Not having a cadence means that your focus gets drawn unconsciously to the inward at the expense of the outward. Cadence frees up your time and mental burden to lead the team to bigger problems to solve and more impact.
Decision making is a skill like any other and it is reinforced through practice, through failure and through guidance. If you’re involved in every decision at every point the team never gets to use this muscle and it atrophies, taking away your leverage.
The price you’ll pay is a few bad decisions, but over the long term a team that’s growing in ability is compounding leverage. This trade-off is a no-brainer.
Cadence eats genius for breakfast.
In the next and final part of this mini-series on micro-management I’ll tell you about what I call ‘blast radius’.
I've tried to follow this advice from @_svs_ on cadence checks since Jan/Feb. This works amazingly well if you can process information mentally quickly.
Things which I tried+their outcome:
1- Scaled up an IC massively by defining the project by only 2 metrics. We measured the performance 1x a month
2- Asking team to do weekly deep dives on engineering, ML, data trade offs they've made
- This has seen some resistance on how frequently this should be done, but that is tunable
3- Hiring: Maintaining a steady source of new candidates - this didn't go well, but that is okay, since I'm the only person working on this full time (no HR/Recruiter help)
4- Dev Releases: Encouraging devs to make releases on a predictable 2 week cadence, which enables everyone to plan their PR, hiring time, study time much better -- mixed success so far, scoping things to 2 week cadence is hard for some devs
5- Data Processes: Weekly cadence check helped org scale this 4x, during the pandemic, which completely fell apart when we all went WFH
What I noticed/learnt along the way:
1- Frequency of check is quite important, higher frequency e.g. weekly work best
2- Repeatable simple checks, are great for monitoring, but not for raising the bar. They can happen with this, but I've not been personally able to do so yet. Most bar raising work happens in ad hoc cycles right now
3- Needs some time (min. 2-3 months) to make the cadence check work, don't abandon during early failures/mistakes
I hope this comment helps readers get more examples on why this advice is so effective and efficient at the same time!
Amazingly insightful. Will follow the tips :)