Managing a team of software developers is a tall order. This is doubly true when the line management includes both org chart duties (career development, HR administrivia, etc) and responsibility for the team’s performance when it comes to shipping. In this case, you’re being asked to understand their day to day performance well enough to evaluate their performance and drive improvement, in spite of the fact that what they do is utterly opaque to you. It’s like being asked to simultaneously coach a team and referee the game for a sport whose rules you don’t know. As I said, a tall order.
I’ll grant that, if you’re a dev manager, you may have been technical at some point, perhaps even recently. Or maybe not, but you’ve been around it long enough to pick up a lot of concepts, at least in the abstract. But in neither case, if you were asked what, exactly, Alice coded up yesterday, would you be able to answer. Whether it’s due to total lack of experience, being “rusty” from not having programmed in a number of years, or simply being unable to keep up with what 8 other people are doing, their work is opaque to you.
As with coaching/refereeing the game that you don’t understand, you can pick up on their body language and gestures. If all members of the team appear disgusted with one of their mates, that one probably did something bad. You’re not totally without context clues and levers to pull, but it wouldn’t be hard at all for them to put one over on you, if they were so inclined. You’re navigating a pretty tough obstacle course.
And so it becomes pretty easy to make mistakes. It’s also pretty understandable, given the lay of the land. I’ll take you through a few of the more common ones that I tend to see, and offer some thoughts on what you can do instead.
Micromanagement
The opacity of the development team’s labor creates a situation in which it’s easy to feel as though you don’t have control. And a perfectly natural impulse in such a situation is to overcompensate and try to exert as much control as possible. The overwhelming majority of folks that micromanage don’t think to themselves, “I want to be an insufferable control freak,” but rather something along the lines of, “I just need to get really involved for now while we’re facing this deadline, and then I’ll back off when things settle down.”
The trouble is that this absolutely puts the brakes on team efficiency. It may feel more efficient to you as a manager because you’re fully aware of all moving parts. But the reality is that you’ve simply become a bottleneck. You have to let go and accept that you can’t control, or even be aware of, everything that happens with the team. Not by a long shot. You need to trust your team, and if you can’t trust your team, you have bigger problems than your next deadline. So keep calm, have faith in your team, and let them work.
Poorly Timed Meetings
Forcing developers to spend their time explaining things to you in excruciating detail isn’t the only way way you can torpedo their productivity. You can also do this by throwing meetings on their calendar at the wrong time. Programming is an activity that requires participants to be in a state of flow in order to be at their most effective. And flow doesn’t just happen with the snap of a finger. It’s a fickle muse.
Many developers experience a sense of joy when they look at a day uninterrupted by meetings because they know that it will be maximally efficient. If you start scheduling meetings for them, you can put a serious damper on their mood and their productivity. But not all meeting times are created equal. First thing in the morning, before or after lunch, or right before leaving tend to be fine, since those are not times that are going to interrupt their flow. But slap something on their calendar for 10 AM and for 2 PM, and you can pretty much insure that they won’t really get into their work at all that day.
Having spent portions of my career in both managerial and software development roles, I know firsthand how easy it is to stop thinking of when developers are most productive. Paul Graham has a great article on the managers’ and makers’ schedules. It’s an easy and common mistake for any busy dev manager, even a former techie, to book meetings according to their own schedule openings and desire for information. But the team pays a heavy price for this, so conceive of ways to minimize meetings with the dev team and push the needed ones to the edges of the day.
Too Clever with Incentives
I’ve alluded to this in past posts, but be careful of how you incent the development group. The classic example of a problematic goal for a dev manager to set is automated unit test coverage. Think of it this way. Why do you set a goal like this? Is it because you’ve done some research on how to have better software quality and fewer defects, and a number of articles, blogs, and popular speakers tell you that good software groups have high test coverage? Are you (someone who does not write code for a living) trying to figure out how your developers (who do write code for a living) could be better at their jobs and then forcing them to do it that way?
This goes back to the issue of trust. Why don’t you let them figure out how best to do their jobs? If the goal is fewer defects or smoother releases, why not just state those goals and let them figure those things out? I understand that you’re both trying to help and confer the benefit of your tenure in the industry, but joy does not wait at the end of this path. If you make the goal test coverage and incent them accordingly, they will succeed… in having a lot of test coverage. It won’t have much impact on your actual goals.
So don’t overthink it. Tell these smart humans what you want, and trust them to get you there.
Trust is the Key for Dev Managers
The theme has come up over and over again, but it’s worth stating as a conclusion. You have to trust the development team. It’s the only way you can scale and be successful.
What do you do if you can’t trust them? Well, that’s a personnel issue and that’s why organization leadership positions exist — to make hard decisions. You need to figure out how the folks on the team can become professionally trustworthy and you need to figure out where you can go to find and hire folks that are trustworthy. Your main responsibilities should be finding people you can trust, hiring them, and clearing all distractions, yourself included, out of their way. You do your job, and they will do theirs.
Comments:
Comments are closed.