Scaling teams by embracing autonomy

Everyone knows that micromanagement is bad; it’s “common sense” right. So why is it so common that developers who become team leaders fall into the trap of becoming micromanagers? And why is it especially prevalent for accidental team leads?

Let’s start by looking walking through a scenario and see what happens. You’re working on a project by yourself, things start to take off, and there is more work coming in. More than you can handle by yourself, you recognise that you need to get someone else to work with you.

Bug Fixes

You set your new hire to task on some simple bug fixes. It should give them a chance to get to know the codebase, and they should have something done reasonably quickly. Plus it’s the sort of scut work you hate!

Pull Requests

They create a pull request for you to review, they’re pretty happy with what they’ve done. How you behave next will dictate your relationship with your new hire.

If you put them off, they will be sitting there waiting for you to do your code review. If you need to finish up what you are doing, that’s probably okay. But if you say something like “I’ll take a look tomorrow” you’re sending them the message that the work they are doing is not as important as what you are doing.

I think that pull requests aren’t particularly valuable and consequently, you shouldn’t spend too much time on them. When someone asks you to review their pull request you need to find out what they are really asking for. Do they want you to look through their code and offer suggestions for refactorings? Are they looking for guidance on the architectural intent of the project and whether they are following it? Or do they want permission to merge? I suspect it’s usually the latter.

Not what you wanted

Nothing is more de-motivating than being told: “it’s not what I wanted”. The chances are that it solves the problem, just not how you would do it. That’s different to it doesn’t solve the problem; if it doesn’t solve the problem, I would still merge it and deploy to a test environment and get them to demo it. This is sending a clear signal that they alone are responsible for their code.

Towards Autonomy

Okay, you’ve recognised that things aren’t working and that you are turning into the boss you hate! How do you enable people to be autonomous? Here are some things that I think helps enable people to be more autonomous and gain more control over their work.

Plan Together

This is simple; you need to enable everyone to partake in planning. There’s no point doing “planning” with a subset of the team and telling everyone else this is what we’re working on. If you want fully engaged team members, they need to be involved with the what. That needs to include roadmaps and weekly planning. In can be optional of course, but the invite needs to be there.

Solve Together

As part of planning, you should come up with some ideas about how you’re going to solve the problem you’re tackling. This will set expectations among the team of the general direction. Working through the preliminaries of how will also help tease our requirements.

Accept and improve

When you don’t like how someones did something, you need to accept it and then look to improve it rather than rejecting it. Discuss and highlight problems in their approach to tease out issues. Then go back to planning together and repeat.

Conclusions

Always enable, never block.

Share: Twitter Facebook LinkedIn