What traits do the best managers you've worked for have in common? [closed]

https://softwareengineering.stackexchange.com/questions/7966

management

16-10-2019
|

Question

I have been listening to Scott Hanselman and Rob Conery's podcast, This Developer's Life.

In the latest episode, they discuss personality traits:

1.0.4 - Being Mean.

What makes people mean in our industry? What about aggressive? Confident? What's the difference? Would you rather have a drill sergeant for a boss, or a zen master? We talk to Cyra Richardson and Giles Bowkett.

It got me thinking, what traits did the best managers you've worked for have in common?

EDIT: Just to clarify, as there have been a few close votes, I'm interested in whether there are traits common to managers of developers that are not necessarily those traits that a manager of some other profession requires.

As for whether this is programming related or not, well I don't want to ask this question on a site that isn't about programming because, frankly, I'm not as interested in what people who make cans of soup for a living want from their managers as I am interested in what developers want from their managers.

Solution

In my experience, it's been a combination of the following:

Measures by results/output, rather than input.
Motivating, inspirational leader that you can respect and look up to.
Sensitive to team members' needs - support/training/career, etc.
Quickly resolves conflict, diffuses difficult situations.
Understands your job - they may be able to actually do your job, but hired you to do that.
Handles/filters-out the stuff thats' not important or impairs the teams' productivity.

OTHER TIPS

Joel Spolsky calls it the "Abstraction Layer". Do what it takes to keep me programming. Let me know what's going on in the company, but keep me out of the politics. Eventhough I still have to do it, at least acknowledge that the request is bull sh!t.

Someone who will fight political battles for me and remove obstacles that prevent me from getting things done.

Period.

Being willing to listen to the people who work for them.

I've had very technically-inclined managers, and I've had some who didn't even know about multitasking ("oh wow! Where'd you learn that Alt-Tab trick?"), but the thing that all the ones I've actually enjoyed working for had in common is that they knew they didn't know everything, and were willing to listen when those of us actually doing the work they were supposed to be managing presented ideas, problems or suggestions about that work.

She/he protects his team and assumes his/her responsabilies

One in your team crash a server with production data. Your manager will take full responsability. He will eventually refuse to tell his upper manager who did the mistake and stand in front of his men.

They manage based on goals, not time, and are primarily concerned with me achieving those goals

Rather than being concerned with how long I'm sitting at my desk, they're concerned with what I need to accomplish a given task. If this means removing obstacles or hindrances, or allowing me to work long hours/weekends, they're willing to trade-off the time. If I get work done ahead of schedule and need some time for doctor appointments or family activities, they're flexible and understanding.

I certainly want to be held accountable at work, but it should be for what I achieve, not how much time I spend at my desk.

Keep me out of meetings that I don't need to be in. If managers could just manage to do this, they would be infinitely more valuable.

Recognition that I am hired and paid to make decisions.

They support you when you say NO

One of the most demotivating trait in a manager is the lack of courage to standup for his people and always bow in front of his own boss even if it means affecting the product or the team.

no yelling please...just don't. (no matter how stressed you are about the big deadline, stupid testers, etc.)

Someone who just lets me do my job.

Understanding what programming consists of. You would be surprised on how many managers know nothing about the matter.

Recognition that I am hired and paid to make decisions.

I am not a $7/hour food service employee. I am here to make decisions. If I'm told every detail of what to do, I might as well be a typist.

(Deep) Empathy Skill.

I have to go at this from the perspective of the worst bosses I've worked for - a good one would NOT have these qualities:

Inability to make a decision _ sincgle worst thing I ever dealt with was a boss who changed his mind every time someone talked to him. We changed direction 4-5 times a day on a three year project.

Steals the credit for things the team members do. Once my boss got a huge award that they gave out publicly. Everything they mentioned that he did, I actually did. Needless to say this is demotivating in the extreme.

Panics when things aren't going well. Even worse when panicing makes him or her become nasty. That's not helping get things done, really.

Back-stabs his own people. He gets the credit, we get the blame. ANd doesn't support us up the chain of command when he should.

Has no understanding of the process of developing software and doesn't even care to learn enough to know we are using C# (or other language of your choice). Thinks that everything can be done in a short period of time and that a simple change on the outside of a User_interface page means it wil not take long to implement. The kind of person who sits on a change until the day before the deadline and then says, "Oh By the way we need to do..." and what ever he asks for is something that changes the fundamental architecture.

Micromanages or doesn't manage at all. Both are equally bad. I've had too many bosses who didn't know there was a problem with one employee until too late and everyone else had to pay the price to fix the mess. I've also had bosses that I had to tell them to stop bothering me every five minutes or it would never get done.

Is politically naive. If your boss isn't doing well politically with the people above him, you will have trouble getting the people you need, you will have the worst spaces and you are in the group most likely to lose your jobs in a layoff or because it is a easy way to get rid of him. Bosses must be good at office politics.

Someone who thinks he can slash the hours of a project in half (because the client won't like that number) and we will be able to get it done in that amount of time with no corresponding change of requirements.

Credit where credit due and enough knowledge to be able to assign it

I'd have added listens well but upvoted that instead.

If there's someone who constantly takes credit for features found in libraries either developed in-house, open source or third party then that should get shot down, not rewarded.
If someone is being assigned all the bug responsibilities because he's actually writing unit tests and finding them then he should be rewarded, not punished. Finding bugs is not the same as writing them in the first place.
If a develop or a group of developers bust ass to make deadlines, they should be lauded, not the managers for coming up with the deadlines in the first place.

They trusts their people to get the job done and don't try to "herd cats".

Give their people room to make mistakes(not huge ones obviously) and learn from them.

Someone who listens well

and

Someone who makes it a point to actually talk to me at least weekly

I've had good managers and bad. These are some traits I've noted in bad managers:

Get's out of the way so you can do your job

A good manager will see to it that you have the right equipment to write code.

Micro-manages the wrong details

This sort of manager will chew you out over failing to attach a signature to your email while ignoring the extra work you did prior to that email.

Has no interest in the development process

This is really a bad sign for a manager in charge of software developers. He doesn't care about investigating other development approaches, will not know what version number the next release of the software should be, will not read blogs like Joel on Software or anything related to managing developers, like Peopleware.

Thinks that he's there for me to report to

This sort of manager gets off on having people report to him about everything.

Misallocates time

Given a month to deliver a development project from start to completion this manager will allocate 3/4 of the month to the design and requirements team to generate 1000 line word documents and expect the dev team to implement it all in a week. He'll also iterate on requirements until they're 'perfect', adding copious amounts of detail until the document becomes unusable. But then later on in the development process you'll find bugs in the design and requirements documentation and realize that the emphasis on trying to write the perfect document was a mistake.

I think the two most important characteristics are a basic understanding of management principles, and being "one of us." Unfortunately, the two don't tend to occur together too often, but when they do, you've found a good person to work for.

Where I work, our project manager is a former developer. He's good at prioritizing and directing work--the stuff a manager needs to know--but he also has a pretty good idea what's going on when I need to ask a question about how to implement something that requires both management-level vision from him and technical input from me.

The boss also has both these skillsets. He's actually a current developer, who occasionally works on the codebase and makes commits, when other responsibilities don't drag him away from it. He makes sure we've got a good working environment, because he knows intuitively what a good working environment is like for us: it's the conditions he would want to work in!

Fights for me. I shouldn't have to get into it with IT. Gives me the tools I need. Communicates company policy down. Makes decisions when asked to and stays out when not.

Disclaimer: I have previously been in managerial roles, but currently am not. From that I can definitely say it can be pretty hard being on the other side of the table too.

Someone who is clear in what needs to be done, lets me work out the technical details, provides context when needed, and doesn't change requirements when I'm more than halfway done.

Two things:

1) Is (or fairly recently was) a developer him/her self.
2) Manages upwards as well as downwards.

Point 1 will give you, as a developer, a manager who truly understands what your job is and consists of, and understands what you need (and also don't need) to do your job to the best of your abilities. If they're not a developer now (and they really shouldn't actually be a hands-on developer now as they're a manager - and that's a full time job itself) they should have previous development experience, but that should be fairly recently (ie. in the last few years) so that they're at least familiar with modern development languages, tools, methods and techniques.

Point 2 will give you a manager who accepts his responsibilities, shields his team from the office politics and needless distractions and fights for his team to be provided with the things they need (thus enabling Point 1) and can manage expectation from the business and those above him (This is even more important in a large corporation where many levels and layers of management exist between you (the developer) and the business decision makers (senior management)).

In a nutshell, having trait (1) gives you a manager who understands what you need to get your job done, and having trait (2) gives you a manager who will provide what you need.

Joel Spolsky's Talk at Yale (and the related "Command and Conquer and the Herd Of Coconuts" article) puts it very succinctly:

In talking about the (bad) management at Juno:

"The assumption there was that managers exist to tell people what to do."

In talking about the (generally good) management at Microsoft:

"Managers exist to get furniture out of the way so the real talent can do brilliant work."

I want someone who is capable (and has the courage to) of recognizing and getting rid of the deadwood. These people are harming the product and slowing down the completion, get them out of my way! All too many managers either can't recognize who is a bad developer (or think the one with the messy desk is bad or the guy who appears to be starting off into space alot even though he may actually be the smartest or most productive dev) or don't want to have to be the one to tell someone they are being let go and so let the deadwood stay year after year causing harm and discontent among the competent.

I don't want to be embarrased by a manager who doesn't even know what languages or database backend or other critical tools we use. I had one ask (in front of the client)what language we programmed in after being involved in the project for 3 years! I don't expect people who have been in management a long time to still be current on the hows of everything, but they should at least know what are we using. And they should be smart enough not to ask stuff like that in front of others if they don't.

I want a manager who has courage. Don't accept that unrealistic deadline without pushing back, don't let people bully your employees or let rouge developers go along their meery way without being brought up short. Don't fail to tell me if I am doing something wrong because you are afraid I might get upset. Managers exist in part to handle the bad news, I want one who can.

I want a manager who understands I have a home life, who understands that exhausted devs make mistakes and it takes longer to do a project working 60 hours a week than 40.

Most of all I want a manager who recognizes good work and is verbally appreciative both to me in person and up the chain to his or her bosses. Although I really hate it when they think the bad work is good work and reward the wrong people!

Friendliness would be something I'd put up there. I don't like having a sense of dread if my boss decides to visit my cubicle every single time. My performance may be a little better if I feel like I'm helping out a friend that asks for a favor here and there at times, e.g. to get a project done for a deadline I may have to stay in the office for some number of hours that I may not otherwise want to do.

Competence on managing multiple things would be another aspect that I'd look for though this may be seen as an obvious trait to some extent. Conflict resolution and reconciliation skills would also be something I'd want to know that my manager can handle as there may be times where it is either developer against developer or developer against analyst in terms of issues that require someone to be right which may be neither in some cases as some aspects to the work can have multiple interpretations.

Someone who understands that development is not factory work. Putting in more hours per day is not likely to get significantly higher yield. Programmers need to pick their nose up from the grindstone pretty often and just not think about what they are working on to solve a problem and get things done.

A good manager is willing to let me say no. They realize that software development is a wicked problem. Thus, even if the manager is more compotent than I am technically, they realize that I might know the problem better simply because I'm the one implementing the solution. At the same time, they let me know when I'm missing context. Many times, managers might make decisions based on things they know that I don't. If that is the case, then they should fill me in on the details or at least let me know that they know something I don't.

I've worked in a few places now where the management was explicitly non-technical. My current employer has a policy that a manager making a technical decision is grounds for removal. (This is not some small company you've never heard of, roughly one third of you are running our product). Partly as a result of this policy, at least in my opinion, the managers here are much "stronger" than at other employers. Since they're not involved in the technical decision-making, there isn't the constant string of 'slightly to very wrong' technical decisions being made by management, and they only make large "product-line level" decisions.

The best managers that I've had are those who 'run interference' for the developers. A good manager can tell the difference between a 'mandatory meeting' and a mandatory meeting, and will let you know.

A basic management skill is to make the developers feel in control of their environment, this may be either a reminder or an illusion, depending on the company, but it's a vitally important skill.

Licensed under: CC-BY-SA with attribution

Not affiliated with softwareengineering.stackexchange