DaedTech

Stories about Software

By

Mistakes Dev Managers Make

Editorial note: I originally wrote this post for the NDepend blog.  You can check out the original here, at the site.  If you like this post, head on over, and check out more at the site.

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 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.”

GrabbingTheWheel

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 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, but 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

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.

35 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Brutus Maximus
Brutus Maximus
8 years ago

Oh man …I wish my manager would read this.

Erik Dietrich
8 years ago
Reply to  Brutus Maximus

Feel free to send him or her my way 🙂

Sean Cleetus
Sean Cleetus
8 years ago
Reply to  Brutus Maximus

I want to hear your managers’ story now 🙂

Luis
Luis
8 years ago
Reply to  Brutus Maximus

I know a manager or two that could learn from thos, but then again these types of managers normally dont change.

Helton Moraes
Helton Moraes
8 years ago
Reply to  Brutus Maximus

Now I’m feeling special, because I actually read this article out loud to my boss. He had just the day before expressed his feelings about “not having control” and *snap*, I’ve got this test to make a good point with him. He listened carefully, and we made some interesting trade-offs and adjustments on our previous workflow. Nothing like having a boss which is also your friend (and cycling buddy, actually). Deal with it B^)

Erik Dietrich
8 years ago
Reply to  Helton Moraes

The (former techie manager’s) struggle is real. I can totally empathize with the lack of control feeling and felt that myself when I was managing developers.

Helton Moraes
Helton Moraes
8 years ago
Reply to  Erik Dietrich

The trade-off ended up being: 1) team agrees on deadlines for sprints at the beginning, with dates set for deployment in some real customer (currently this mean a visit in the flesh); 2) the manager should be PART of the daily work (at least the standup meeting), and should watch for continuous integration, and run the code in its own IDE. That way we have tight feedback among team members, manager being one of them, and as soon as the project veers out of way (scope wise or time wise), management can communicate and call for corrective action. Much like… Read more »

Dhalonen
Dhalonen
8 years ago

Face it: it’s far easier to be a bad boss than a good one. The amount of effort is significant!

Miguel Ribeiro
Miguel Ribeiro
8 years ago
Reply to  Dhalonen

Problem is that you need to find a balance of absence and presence. You cannot be to present and micromanage things and cannot be to absent so the team doesn’t lose *trust* on you or the communication starts to degrade (most of the times, and mainly in teams spreaded between several offices, the manager is the “communication promoter”).
But yes, entirely agree with you

Erik Dietrich
8 years ago
Reply to  Dhalonen

I don’t think that’s unique to being a manager, but it’s certainly true of managers. There are a lot of ways to fail at that role.

Victor Cretu
Victor Cretu
8 years ago

It’s nearly impossible to be a good boss in software development. Software development is like horse racing.
As a boss, you are asked to place a few bets and win every single day. Can you do that ?

chaiguy
chaiguy
8 years ago
Reply to  Victor Cretu

Writing software *shouldn’t* be like a horse race though. If that’s how you’re approaching it, you’re doing it wrong.

Winning in software shouldn’t be a gamble. Don’t bet on your employees, enable them. Sure there will always be unexpected issues, but if you expect to have unexpected issues and plan for it, you’re already ahead.

Design well. Plan well. Stay out of your dev’s hair. Things will get done.

Victor Cretu
Victor Cretu
8 years ago
Reply to  chaiguy

More than 20 years ago I wrote an accounting and booking system using FoxPro. Today, probably 4 out 5 (young) developers have absolutely no idea what FoxPro is. Choosing the right technology IS A GAMBLE. Angular seemed to be a safe bet 2 years ago. Today is almost dead because Google decided to fundamentally change its principles. Google Window Toolkit (GWT) is another zombie. Isn’t funny how a company like Google buried 2 front-end technologies in less than 4 years? If they are not able to design and plan well then who is ?

chaiguy
chaiguy
8 years ago
Reply to  Victor Cretu

Ok yes, I totally agree that these sorts of business decisions are gambles. But they’re gambles because *business* is the horse race. Imo, this attitude should not filter down to the devs though. Yes, management involves risks and gambles, but an important role of a manager is to insulate the devs from all that so they can focus on their actual job. What I mean by gambling on your employees is, for example, gambling that your worker will get a story done in x story points when it was estimated at y. That’s the bad kind of gambling, because it… Read more »

Erik Dietrich
8 years ago
Reply to  Victor Cretu

In my experience, the key is to frame the role not in terms of making bets (meaning trying to predict the future in executive strategy meetings and the like) but in terms of enabling productivity for the development team. A good manager clears problems out of the way, settles and diffuses disputes, sets people up for success, etc.

Victor Cretu
Victor Cretu
8 years ago
Reply to  Erik Dietrich

The software development is a very dynamic domain. Every few years new technologies appear and make the old ones look dumb and inefficient. Should I throw away what I developed in the last years and switch to new technologies or continue with the old ones? That is the question a boss has to answer and the more they hesitate to find a solution the more they lose. In our days, with new technologies, a team of 5-10 developers can take down a company of 50 developers forced to deal with legacy code.

Brandon Wilhite
Brandon Wilhite
8 years ago
Reply to  Victor Cretu

Shouldn’t the (hopefully seasoned) architects and lead engineers be making the technology decisions? That’s my thought anyway.

Victor Cretu
Victor Cretu
8 years ago

What if they tell you that all the frameworks from the market are bad and the best thing to do is to allocate a budget for building an innovative one, “in house”. What would you do ? Would you allocate them the budget ?

Brandon Wilhite
Brandon Wilhite
8 years ago
Reply to  Victor Cretu

Ultimately it comes down to trust. Unless you have the ability to make that evaluation yourself you really have no other choice. Granted, that’s a hard pill for the non-technically inclined to handle (not saying that’s you as I don’t know you). Unfortunately, I don’t think there is any other answer.

Victor Cretu
Victor Cretu
8 years ago

I wouldn’t allocate them the budget, no matter how much trust I have. Simply, the numbers do not add up,. Picture this, in order to successfully complete My Project I have to firstly, succeed in the Framework Project. Because I have 2 projects now, I could say that doubled the risk. My chances to succeed in My Project just decreased by 50%. I also, got more work to do so, I have to hire more developers. Can I hire junior developers ? No! I need senior developers because I have a framework to build and maintain. Funny thing, although I’m… Read more »

Brandon Wilhite
Brandon Wilhite
8 years ago
Reply to  Victor Cretu

Btw I’ve enjoyed the conversation, thanks. I’ve seen the exact scenario you describe play out more than once (I’m a consultant so it’s not uncommon for me to come in near the middle or end of all that). It’s definitely expensive and it’s definitely no fun for *anyone*. Most of the time, as I think you are aware, the requirements aren’t really all that different that a new framework is required. Sometimes you may use a pre-existing in a different way or use a combination that isn’t common, but that’s different from rolling your own. I nearly wrote that in… Read more »

skyeye2
skyeye2
8 years ago

biggest team you have been? Let me guess.. one including you? lol
So many cliches from the point of view of someone is being managed..
About micromanagement: if you are in my team and I start micromanaging you, you’ll know it’s better you start looking for another job somewhere else..

Erik Dietrich
8 years ago
Reply to  skyeye2

It’s funny because a team of one isn’t really a team at all! Rimshot!

skyeye2
skyeye2
8 years ago
Reply to  Erik Dietrich

So that demonstrates you are talking about things you don’t know.. Quadruplet!!

tankerbob
tankerbob
8 years ago

Great Article. As a development manager my best days were when the team would tell me to ‘go away – they got this’ You have to trust them to have it and hopefully you’ve hired or inherited developers who are better coders then you are.

chaiguy
chaiguy
8 years ago
Reply to  tankerbob

I’m glad you can have this perspective. So many dev managers naturally come from a background in development and thus feel that because that is their background and past expertise, that that’s how they will be most helpful. In reality, management (even dev management) is it’s own role entirely. You are not developing yourself, you are *managing* the developers. (I like to think of managing as being more synonymous with enabling and supporting, rather than controlling.) I am a dev and have never been a manager, but the best dev managers I’ve had were at one time devs themselves, which… Read more »

Erik Dietrich
8 years ago
Reply to  chaiguy

That last paragraph is a GREAT observation, in my opinion. A manager working at that level of knowledge is in a sweet spot because he or she will be able to tell if people are trying to put one over, but won’t be looking to micromanage.

Erik Dietrich
8 years ago
Reply to  tankerbob

Absolutely! (And thanks for the kind words, by the way)

When I’ve managed development teams, I loved when the division of labor in no way asked me to offer up technical expertise (though I missed the tech). I’d be figuring out ways to clear out distractions, lobbying to outside departments on behalf of the team, planning out ways to advance the team members’ careers, etc. They’d be figuring out the tech. Management (overhead) exists to keep the team happy and productive.

Maxwell Cabral
Maxwell Cabral
8 years ago

I think this is pretty good but I really strongly disagree with the assessment of unit tests as a pointy haired boss goal. If you don’t have time to write tests baked into your development cycle you have failed to accurately judge the time to develop your solution and you’ve doomed your team to spend way more time doing excruciating back and forth QA cycles. You’ve also doomed new developers to being dependent on folklore and the quality of your documentation to describe the functionality of your project. Tests are for developer benefit.

Erik Dietrich
8 years ago
Reply to  Maxwell Cabral

Please let me clarify a couple of things that will maybe help clear up my message. First… personally, when I develop, I practice TDD, but as a manager, I’ve never felt it appropriate to mandate that developers do the same (or even write unit tests). I try to persuade them or sell them on the idea, usually successfully, but I view the manager’s role as one of looking for results. Having unit tests is not a first class goal — minimizing defects, enabling change, etc — those are first class goals. Unit tests are a great way to get there,… Read more »

Maxwell Cabral
Maxwell Cabral
8 years ago
Reply to  Erik Dietrich

But goals and company ethos are driven by what you measure. It’s hard to measure “quality” without the units that make it up. You might have software that crashes all the time, is bug ridden, but users can’t get enough of it. You might build a cathedral that your users hate because it doesn’t do what they want. Which is higher quality? “Quality” is subjective. Errors, conversion events, input and output, are reproducible and actual measures of quality. Every project I’ve worked on where “Quality” was the only measure usually ended up being of poor quality because it’s too vague… Read more »

animageofmine
animageofmine
8 years ago

For a dev managers, topmost factor in my list is to have technical background. He should have been a developer in past. Otherwise, he cannot contribute to the team, nor would he be able to appreciate the complexity of work his team is doing. He won’t be able to find the star of the team either. Like it is said, if the head is weak, whole body suffers.

Victor Cretu
Victor Cretu
8 years ago
Reply to  animageofmine

I had a boss who wasn’t developer in the past. His philosophy was very simple. If the company needs to many senior developers then it’s being badly managed. A good technology doesn’t need top developers. So, during that time I used only commercial technologies. It was one of the most efficient teams I ever worked with. Firstly, a boss should be pragmatic.

animageofmine
animageofmine
8 years ago
Reply to  Victor Cretu

Victor, Its good to know that you had a good boss. But you quoted something in your post. From what you mentioned, it sounds like your boss’s philosophy revolved more around management than technical stuff. Obviously, boss is a people manager and so he thinks of management, but if he is a dev manager, normally he is expected to care more about immediate goals and not too much about budget unless the hierarchy is too flat in the company and he has too many people reporting to him. I have worked with over 10-12 managers in my 6-7 years of… Read more »

bcweis
bcweis
8 years ago

I work as a dev mgr for multiple teams, and unfortunately I have to do bulk staff evaluations based on metrics. I have to have some quantification standard in place to measure effectiveness… which is very difficult to establish in software development. We use first-pass test case rates. That is, I have senior devs review unit test quality for the other devs, and then the unit tests are executed and give some % back as a “pass rate.” This allows us to establish a baseline of code quality to which we can measure. The key is getting good unit tests… Read more »