Startup Engineering: Managing, not Micromanaging
This post was triggered by a recent question posed: “How does a manager balance between not micromanaging but still being involved enough to be able to catch problems early on?” Which is of course a good question. The cop-out answer is “it depends,” which is true but not very helpful.
Nonetheless, it does depend: on the manager, on the team, on the company, on the work being done, on the process, on the schedules, and so on ad infinitum. But there are some guidelines and ways of thinking about the problem that are useful across the board, I believe.
First, though, let’s define micromanaging. There’s a reasonable Wikipedia article that provides several definitions and a useful summary of symptoms. The Harvard Business Review published a good piece last year that has a fairly broad, useful look at micromanagement. But to some extent it’s in the eye of the beholder, and that’s one of the difficulties. Let’s try out a different sort of definition:
Micromanaging: when a manager feels the need to sweat the details because there’s a lack of trust and communication between them and their team.
In truth, what you think you need as a manager in order to keep track of progress might be what you as a developer would consider micromanagement. Hence our first guideline:
Define expectations for upward communication
As a manager, you’ll have certain expectations for what sort of status reporting you want, and you can’t expect your team to automatically know them. Not only that, but what you want may change from project to project based on deadlines, resources, complexity, and importance. Sit down with your team periodically and remind them what you need. This includes both project/task status as well as technical decisions being made. But at the same time:
Exercise empathetic understanding
That’s just a fancy way of saying that you need to think about it from the team’s point of view. Putting yourself in their shoes, does what you’re asking for feel right? Keep in mind that these are adults you’ve got working on software development, and if you don’t trust them to do their jobs then you’ve got a different set of problems. In the context of the project and work at hand, what sort of visibility do you really need?
Take into account how things are going
If things are generally going okay, then it’s quite possible you need fewer updates than you’re actually comfortable with. If you’re an agile team with weekly planning meetings and retrospectives, ask yourself if perhaps you don’t need an update more than once a week. You want the fewest updates possible: less for your team to do, less for you to read. Keep in mind that management nirvana is an entirely self-managing team.
On the other hand, if things aren’t going smoothly — whether a project is behind schedule, or the team’s having trouble, or some other reason — then of course it makes sense to ask for more frequent updates. And in crunch time, a quick end-of-day standup every day may be reasonable.
Teach proactive messaging
If you find yourself having to ask for an update frequently, either you haven’t set expectations correctly, you’re micromanaging, or your team just hasn’t gotten good at being proactive about communication. In the latter case, you may need to provide reminders and corrections occasionally to remind team members to watch for signs indicating it’s time for an update. Examples, among many others:
- They’re blocked and can’t move forward.
- They just realized something is much more work than was estimated.
- They just realized a task was missed during planning and needs to be added to the project.
- Something important just broke.
Remember that a common engineer trait is to see something, think “Oh darn” and just start fixing it. The first instinct is often to tackle the problem, not walk over and update someone (or send a Slack message, or whatever your company’s communication habits may be). Then, engineers being engineers, they’ll be lost in a fog of hacking code for the rest of the afternoon, and in the morning you’ll be surprised by having lost half a day unexpectedly. When that happens, remember it’s (probably) not malicious, and remind the team that your job is to know what’s happening, and you need their help to do that or else you can’t shield them from the outcome. Remind them that you’re trusting them to keep things going, and they’re trusting you to help them do it. Your goals are the same: help the company succeed.
Use your tools fully
Often, a lack of clarity is due to not taking full advantage of the tools available. Whether you’re using Pivotal Tracker, Jira, Trello, or any of the myriad project tracking tools out there, all of the information should be there to tell you whether things are going according to plan. Perhaps the team’s velocity is off, or a story’s been stuck in progress for twice as long as it should, or new stories are being added mid-sprint — that’s all clear if you’re using your tools properly. Small stories, discrete work, is key. If you have stories that occupy an entire sprint, for example, you’re unable to tell whether progress is being made until the end of the sprint, which doesn’t do you any good.
As an engineering manager, you may have project managers (or product managers filling that role) who track the progress. That’s fine, but it’s doesn’t absolve you of watching what’s going on. You might rely on a daily update from the project manager, but even then you should be checking in every couple of days to get your own view of things.
Similarly, on the technical side you’re likely using Github or an equivalent. You can see the code changes, pull requests, merges, and what’s happening where. Connect your source control to your tracker so you can see why things are being done and which code changes relate to which tasks. It makes it much easier, for example, to keep an eye on code changes being made by a junior developer who needs extra guidance.
Carefully gauge technical quality concerns
So what about your technical concerns? You’re an experienced engineer-turned-manager, and you want to make sure the team is building high-quality software, right? This is where “it depends” is particularly strong, because it depends on your team’s strengths and your own. If you’re a senior developer, still fairly hands-on, and you’ve got a small, junior team at a startup, then you need to be reviewing the code before it gets merged, and providing feedback. However, if you’re reviewing every change from a team of experienced engineers, guess what? You’re micromanaging. So the question is:
Know your team
Obviously, you need to know everyone’s strengths and weaknesses and their level of experience in applicable areas, to be able to effectively manage them. Given that, you should have a clear understanding of where you need to mentor — but you need to stop short of micromanaging. For example, when you’re reviewing code and you’re tempted to comment on something, stop and first ask yourself whether you’re commenting to correct a problem, or because it wasn’t done the way you’d do it. If it’s the latter, don’t comment. If you feel strongly enough about it, go talk to the engineer and ask what they think about your idea, but let them keep their way if they want. Unless it’s a true problem or quality issue, teach and suggest, don’t dictate. And this goes double with your senior folks. They’re on your team to do senior-level work, and if you can’t trust them to do it, then you have bigger worries.
Deal with it when you’re not the expert
One of the most difficult things is that over time, as a manager, you’re likely to get rusty and your skills may get out of date. If you’ve been a senior engineer for a while, this will make you uneasy at first. And if you’re not careful, you’ll fall into one of the easiest micromanagement traps: asking overly-detailed questions. In a way, this will be an attempt to prove yourself. If you can ask discerning questions, then the team will know that you’re on top of things. Unfortunately, this backfires and just annoys the team, and trust me, you’re not fooling anyone.
It’s a fine line, because you do need to ask enough questions in order to understand the choices being made and why, and the more important the decision the more you need that knowledge. But you can learn enough to feel confident in your team’s decisions without digging into every detail, and especially without challenging decisions when you don’t really know enough to have earned that right.
Side note: this really shouldn’t be anything new. Nobody can know everything. If you’re never encountering anything you don’t know well, either your team’s working on really easy stuff or nobody’s doing their spare-time reading to discover what’s new out there!
In the end, it all comes down to two-way trust. You need to trust your team members to do the right thing within their abilities, and you need to understand where their limits are. You must have a view at the appropriate level based on the junction of their limits and their projects so you can watch for either schedule issues or technical issues without having to second-guess everything. And you must trust your team members to raise a hand when they need help.
Which goes to the flip side: you need to have the trust of your team. That’s managerial: do you have their backs, so they know you’re not going to shoot the messenger or find a scapegoat? And it’s technical: do you know enough to understand their problems, raise relevant questions, and accept their decisions without second-guessing? If you’re not a technically up-to-date manager that’s more challenging, and ultimately it means you’ll have to put more trust in the team.
Without this two-way trust, you’ll wind up an annoying micromanager and your team will start hiding things from you. And it’s very difficult to come back from there.