So you share just the big details in order to leave room for:
🔹 interpretation
🔹 creativity
🔹 alternatives
🔹 opposition
The team heads off to work on the project.
It wraps, but the team didn't execute as you hoped.
😐 The objective was missed
😕 A key stakeholder is unhappy
🙁 Deadlines passed
😣 Strategic alignment is missing
Now you have to go back to the team.
"The UI needs to be redone."
"We need to change course."
"Can I have a detailed timeline for this project?"
"You need to start holding a standup that these VPs attend."
Suddenly, you've morphed into the micromanager you dreaded.
And this is the Micromanagement Spiral:
🌀 Delegate a task
🌀 Give minimal direction
🌀 Be disappointed by results
🌀 Micromanage the details to course correct
This cycle will continue on and on and on
Until you can break it.
📢 Giving your team direction and context is not micromanagement.
📢 It's also not micromangement to expect proactive updates about the status of a project.
When those two elements are missing, you'll find yourself needing to micromanage details to correct the course.
So, you can avoid micromanagement by giving:
🔹 Enough direction
🔹 Clear expectations
🔹 What's been tried before, and why it didn't work
🔹 Details about stakeholder expectations or company politics
🔹 Assumptions and opinions
🔹 Timeline details
And avoid micromanagement by getting:
🔹 Project updates that are useful and frequent enough
In practice, it might look like this:
"I need to stay updated on this project in order to give updates to the executive team at our meetings on Wednesdays. How would you like to provide those updates for me?"
"We've already tried X. How will this impact your approach?"
Or this:
"I'd like you to research solutions and make a recommendation. When would you like to share your findings?"
"The CEO is expecting that we deliver before Sept 1. It must include UI changes, or the update won't be tangible enough. Who has an idea?"
The road to micromanagement is paved with good intentions.
Most of the time, trying to avoid micromanagement will lead you right down the path to being a micromanager.
The antidotes?
🔹 Direction
🔹 Transparency
Are you caught in a micromanagement spiral?
Use this thread to spot the signs.
🌀
RT to share with someone who's afraid being a micromanager, so they don't get caught in the spiral, too.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
We've all heard about (and rolled our eyes at) the out-of-touch software engineering manager:
"Can we deliver faster by adding more people?"
"I want to see more PR activity."
But here's an interesting study on the definitions of productivity from managers and developers:
165 managers & developers responded to these questions.
➡️ How do you define productivity?
➡️ (for devs) How do you think your manager defines productivity?
➡️ (for managers) How do you think your team defines productivity?
The results?
Unexpected.
Developers define productivity largely based on output and efficiency:
📊 Activity (tickets closed, PRs, deployments) (50%)
🏄🏾 Efficiency and flow (38%)
🛠 Performance and quality of projects delivered (35%)
🎙 Communication (24%)
🌿 Satisfaction and well-being (8%)
Scheduling your team at 100% capacity is a great way to ensure that nothing will be delivered on time.
There is some cool math behind why this happens.
Let's take this example: each customer at a bank takes an average of 10 minutes to be served.
One new customer comes every ~10 minutes.
With one teller window open, the wait time is FIVE HOURS.
Not minutes. Hours.
On paper, the example above sounds ideal. The teller can keep up with the flow of customers at a steady pace. But these are average rates, and "average" isn't reality.
Some customers will need 20 minutes to be served. And sometimes, three customers might come at once.