On Managing Developers

An anonymous reader writes: A columnist at TechCrunch takes a crack at advice on how to manage developers. He has some decent starting points. For example, "Basically a manager's job is to make other people more productive. What's one really good way to do that? Do the work that is getting in their way. Which means: find out what kind of important work your developers dislike the most, and do it for them." Also: "[D]on't bull$%^& anyone, ever. ... Speak the truth as you see it. Speak it diplomatically, don't get me wrong; but be trustworthy. Only then will you be able to trust others." But some of his statements are open enough to be nearly devoid of meaning: "Any particular process artifact is probably irrelevant. The finest tech team I ever worked on began every day with a daily standup; so did one of the worst, most dysfunctional teams I ever encountered. ... [T]he systems and processes you choose for any given project should be fluid, and flexible, and depend in large part on the team and the context." If you are or have been a developer, what qualities have made your managers good or poor? If you've been in position to do the managing, does you experience jive with this guy's?

Comments

If it were easy

[Crashmarik]

Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.

Re:If it were easy

[Anonymous Coward]

Pretty much this.

I've been a first-line development manager for twenty years (one of the reasons I am still "first line," is because I have zero desire to lose my tech edge, which would be a requirement for moving up the food chain. I loves coding).

In that time, I've learned a lot; much of it by screwing up.

"Good judgment comes from experience. Experience comes from bad judgment."

Honesty is a biggie. That's probably one thing that makes the difference. I'm dead solid honest with my team; including up front about how my first duty is to the corporation, but part of my duty to that corporation is to maintain a cohesive, productive team. That sometimes means that I'm honest to my supervisors when they make dumbass decisions or impose bad process.

That also means courage, personal integrity and a good self-knowledge. Insecure managers are a blight.

We need to manage ourselves first. An unpopular opinion that doesn't sell many books.

Re:If it were easy

[Ol Olsoc]

Honesty is a biggie.

And once you can fake that, you got it made.

Re:If it were easy

[Livius]

But very few people can fake that for their entire career.

Actually being honest is less work. It just takes a minimum of courage.

Re:If it were easy

[Kjella]

Everyone would be great at it. Anyone that thinks you can find the secrets to being a good anything in a couple of paragraphs, just doesn't know very much about the topic.

I don't think you can learn the how in a few paragraphs, but sometimes you can learn about what developers expect from a manager. Let's face it, a lot of managers just ended up there by being put in charge and is learning by doing whatever they think a manager should be doing. And sometimes not even that because they're still techs at heart and want to dive into problems, not manage them. Others have just gone the management 101 school and don't have anything but generic theory.

In particular, there's a massive difference between production work and creative work when it comes to estimates. If I need to get my car repaired or order catering, I expect a rather good time and cost estimate because it's standardized inputs and known quantities of work, at least for the most part. And you can fairly easily scale production with overtime, extra shifts, rush orders etc. to meet deadlines. And if a part is not in stock or you burn the cake there's a fairly standard and known fix.

Most time I've wasted with management is discussing timelines or estimates that are as good as it gets and they're not going to get better by repeating the question. In the end you just fudge it up by a factor of x you hope is big enough and give them a number, because that's what they wanted. This is particularly true when there's bugs or problems that I really don't know where is, what the root cause is, how long it'll take to fix or even if I can fix it since it's in third party code/systems/tools.

The best managers understand enough about computers to know this variation is natural and are pragmatic about working with it and working around issues when they arise. Those who come from a production industry seem to think you can beat a square peg into a round hole and act like I'm in the one being intentionally obtuse. "Can you do it man, yes or no?" which makes sense if you got a painter with three walls left to paint. It does fuck all when you got a developer who has no idea what to fix, but it's probably a one-liner when he finds it.

Furthermore, those who don't understand that you want me out of that meeting and working on plan A - getting it done - while you work on a plan B, what to do if it doesn't get done on time or fixed in a reasonable time. I've had to sit through rescheduling sessions which were almost as pointless as the original scheduling sessions, the problem is that you don't have good data on how long it'll take. And rather than accept that you just double down on the developers and their poor estimating ability and demand that this time, you need correct estimates. In their eyes, we're the hopeless ones...

Re:If it were easy

[Ol Olsoc]

Actually being honest is less work. It just takes a minimum of courage.

Very true, But I have found that probably 99 percent of humans lie very easily in self interest. That led me to be a very meticulous documenter. Which was also what taught people that lying to me was not even remotely in their self interest.

My approach

[CaptainJeff]

Here is my approach to managing engineers.

1. Get the right people.
2. Get the right work.
3. Get obstacles out of the people's way.
4. Get myself our of the people's way.

I'd make at least one change

[Registered Coward v2]

I would disagree with "Which means: find out what kind of important work your developers dislike the most, and do it for them." I would say:

"Find out what non-essential stuff is interfering with real work and protect them from it."

There often is work that is important that must be done but is not exactly fun, such as documenting code, helping tech writers prepare user manuals, listening to users and getting feedback on the UI, etc. Developers may dislike that work but they are the ones that need to be involved with it or do it. Sometimes it's the manager's job to point out stuff that needs to be done and find a way to get it done; even if it isn't what they want to do.

My best manager

[Lorens]

told me that his job was only partially to tell me what to do (because I should know most of it) and mostly to shield me from the bureaucrap so that I could concentrate on doing it. I try to emulate that.

Two other nuggets I aim for:

- a good manager tells his people what *his* objectives are, and explains to them how that translates into the objectives he's giving them.

- there are different kinds of management for different people, and a good manager must adapt. A newbie or an incompetent *needs* micromanaging (but beware of giving the impression of thinking either one is incompetent). As they get older/wiser/more experienced the manager can go more and more hands-off, until with a senior engineer/whatever the manager should be able to just discuss strategy and budget and priorities and such.

"What's ONE really good way to do that?"

[turkeydance]

superior compensation. period.

Not specific to Software Devs...

[asylumx]

Learning how to manage software developers is exactly the same as learning to be a good manager in general. I manage software developers. I'm not perfect, I wouldn't even rate myself very high, but many of my employees have told me fairly often they appreciate what I do for them. They things they seem to appreciate are: being as transparent as possible, being interested in their personal interests and development, going to bat for them when they need something (new PC, training, etc), giving them honest and quick feedback both good and bad, and not being willing to place blame but instead just looking for solutions. None of those behaviors are specific to managing software developers, but instead are some things good managers do in general.

I was a software developer before this so while I'm not up to date on the tech they are currently using, I understand the types of struggles they face. That helps, although I'm fairly sure if I went tomorrow to manage a team of mechanical engineers that I could become effective fairly quickly in that role, too.

Don't get me wrong, I'm don't think I'm a great manager, but I have had one or two great managers and I'm trying to borrow the things I thought they did well and my employees seem to respond to that.

Advice

[Anonymous Coward]

Two of the SDEs I manage told me in their last review I was the best boss they've ever had. Here is my advice:

1) Do not judge anyone on anything except on whether they get their job done. If someone quickly does a good job, I don't give a shit whether they take the rest of the day off.
2) Lead by example. Do the things you want your guys to do. That means the hard things.
3) Imagine your team as a machine. You're the oil. Be where there is the most friction and smooth it out.
4) Sacrifice yourself for your team. If you can't get a reward from the company for someone who deserves it, buy it yourself.
5) Understand the perspective of your boss's boss, and explain it often to the team.
6) Say you don't know when you don't know.
7) Fight for raises and bonuses.
8) Don't talk as a boss most of the time, but when you do, have a good reason to.

These guys worked on the project that won us a nomination by a government agency for Small Business of the Year. The morale earned from being a good boss repays itself in improved productivity and reduced turnover. Plus you make friends for life. It pays to be a good boss.

Let go and let them

[Spinlock_1977]

Until last month, I managed the 12 devs I had hired (I have 30+ years of dev experience). On my way out the door, 3 of them gave me a 'best manager I've ever had'. No one gave me a thumbs down, at least to my knowledge. My 'secret'? Honesty, kindness, and this one very important thing: I never imposed a decision unless they couldn't come to one themselves, or were going off the rails. Despite my sizable ego, I've found 'letting go' of control, and focusing on guiding the team, rather than telling them what to do, produces one very happy, productive team. And they' introduced ideas and solutions that never would have crossed my mind!

I left after a painful year of my naive boss and certain of his colleagues on the leadership team knocking us off course with their sophomoric meddling. Note to senior leaders: When you have a competent person running your dev team, let him/her do it. Just because you can spell Agile doesn't mean you know what it looks like.

Re:...and SHOW GRATITUDE!

[jblues]

Reminds me of the time years ago, I wound up in a bank. We got this company-wide email from someone in senior management, I don't remember who. Maybe the CEO or CTO. I read something like: "We've had a management consultancy in this week, and and their advice was that productivity could improve if staff were recognized and shown gratitude for their contributions. So thankyou!". . . . And that was the end of that.

Managers need to know how to code

[Karmashock]

Or whatever your people are doing. You need to be able to understand what your people are doing so you can know if they're doing a good job or not.

The whole TPS report thing from office space was a consequence of someone that doesn't know how to code or understand the product trying to keep tabs on people that were creating that product or service.

So they create artificial benchmarks and paper work and then judge the employees by how well they comply with the paperwork.

The problem is that the paperwork is not actually anything the customer cares about. It has nothing to do with the product or service. It is an arbitrary management mechanism. And it is FINE if the manager doesn't need it. If the manager can judge your work without it, than the paperwork might make his job easier.

However, if he can't judge your work without that paperwork than he literally can't do his job at all. He can at best APPEAR to be able to do his job. And the only people that would make that mistake would other people that also don't know how any of this shit works.

How is a non-doctor going to judge the quality of a doctors work? You can't.

Same thing. Managers have to have experience in CS if we're talking about developers... ideally they should be programmers themselves.

Again, if you don't have enough programmers with management experience, then it is easier to give programmers management training than it is to give managers programming training. So do that.