I tend to agree that managers of engineers should have engineering experience. I think my reasons would differ from those of the author and many other engineers: it's much less charitable toward engineers. One of the best reasons to select managers who have been engineers, in my opinion, is because they know how much bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices. It's important to know what the work of an engineer really entails: that includes the aspects of it that negatively impact the business and how as much as it does the aspects that contribute value and how.
This is a valid point. In my mind, ideally, at least one or two trusted members on the team can help with this since they're even closer to the actual engineering taking place. It's helpful for management to understand the tradeoffs that are discussed, so I agree that some experience is very helpful, but hopefully the team has a few mature members as well.
I've seen such a thing, taken to an extreme where lazy, underskilled developers were running the show; overcomplicating, underdelivering, yet showered with praise -- and it's horrible to witness. A word of warning for anyone entering such a world: you will not change this environment and any attempts to do so will trigger an immune system response. The developers and clueless managers will circle the wagons in defense of the existing culture.
Lesson learned: don't interfere with "resume-driven development" organizations.
I suggest the following interview question: "Tell me about the technical capability of your management chain."
> I tend to agree that managers of engineers should have engineering experience.
What about managers who have had experience like a decade ago and don't do much tech experience anymore.
I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.
Half knowledge and false sense of technical prowess is more dangerous imo.
A manager should not be dictating architecture unless it’s some really small operation, and even then, it’s dicey. Rather, anyone who is capable of writing up a white paper that describes the problem, solution and rational for the choices should be able to propose a solution, and then have a meeting to discuss and decide whether to move forward.
A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that’s not in the greater objectives or roadmap.
Most of the technology in use today isn't that different from what it was 10 years ago. It's a bit faster and has slightly different packaging. Any manager who last did engineering as an individual contributor ten years ago should be perfectly fine engaging in a technical discussion today at the level a manager should be doing so.
> What about managers who have had experience like a decade ago and don't do much tech experience anymore.
Do you think any of the "bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices." will change in 20 years?
Its been almost 20 years since first coined and we _still_ have bike shedding problems
My own experience in this department has been managers with engineering experience but no management training or experience. Sometimes it’s orgs that promote bad engineers into middle management to get them out of engineering. Sometimes it’s orgs promoting their best engineers into management roles for which they are a bad fit, or just ill prepared.
A number of the examples in the article are just bad management, and things I’ve heard from managers with years of engineering experience.
> It’s better to have no management than unqualified management.
If you’ve ever been on a project with more than 1 or 2 people without a manager—or where the manager doesn’t do their job—you would know how insane this sounds. It does not work. Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.
That's not true in general, I've been in environments where a team of 10+ very motivated individuals worked together without a manager. It's not common though.
The individual tasks a manager does are important - my point is they can be handled under many different roles.
All of those roles are quite different from the traditional manager - for example none of those "managers" had strong authority over the developers day to day work the way a manager typically would. Nor did they speak on behalf of the developers.
The best teams I've been on have done well without much management at all. Mostly the managers were there to shield the team, the rest of the time the managers just got out of the way.
On the very best projects, individuals will step up and lead for a while, then decide to do other things and let someone else run the show a little. Maybe it will be feature ownership, or to handle a different phase of a product in its ship cycle. (Meanwhile there will be managers behind the scenes, hopefully not many, making sure that forms are getting filled out, HR duties are attended to, and nonsense meetings are canceled and kept canceled).
Most of the places I've worked could have used less management. A lot less.
I don't think 'no managers' is a good idea. There are managerial 'things to be done' in every project.
As a thought experiment, if management were 'just a role' and people could switch into for a period of time and then go back to their 'real jobs' with no loss of pay or prestige, that might lead to some interesting effects.
(warning, anecdata:I've worked on teams where the 'manager' role was cycled among engineers/testers/designers etc throughout the project lifetime, and it worked well. I've also seen managers come back to being full time developers, and their perspective from the time of being managers really helped with their effectiveness as developers)
I find a good manager who facilitates the bureaucratic nonsense I don't want to deal with to be worth their weight in gold. They don't have to understand the details of what I do and build, so long as they support my work, are willing to shop it out, and give solid feedback.
I've worked with managers who thought they were somehow superior to the people they manage. This seems to be a common issue. They tend to experience a high attrition rate.
Historically for me, any time I've worked with managers who either managed my team or projects I've worked on, whether they helped or harmed things depended pretty much solely on "does this person have management training/experience, and a desire to be a manager".
I've worked with both engineers-turned-manager and "business" managers, and both have had ups and downs. But the tech industry's love of taking individual contributors and pushing them into management roles without any management training or even interest in managing people seems to be the failed experiment.
Sounds like someone that hasn't ever had a good manager. A leader that can provide good air cover is a serious benefit in a large company. That ability has little to do with whether they have engineering experience or not.
There is value in keeping negative attention away. There is also value in attracting attention to technical needs. If you need someone in another part of the org to do something technical to make your life easier (or even unblock the project), it's difficult to get the job done without a technical manager. You can usually get the job done with a non-technical manager who can listen and delegate well to a good technical leader, though. The problem is that a non-technical manager won't necessarily know who is a good technical leader and who is just a loud engineer.
My experience is that a good non-technical manager will develop a relationship with a member of their team that fills that gap. Most of the "good" manangers I've worked for were good because of their soft skills.
I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.
>I mentioned that approach, yes. But it can backfire if the team member is makes big mistakes. The non-technical manager will have a hard time identifying bad decisions before they blow up.
Why do you assume an out of date and no longer practicing manager will have a better chance of catching errors than causing them? There is a reason you hire experts and that reason is not so you can ignore them. If you're afraid of a single point of failure then you foster a collaborative blame-free culture where the engineers cross check each other.
I've had managers who would agree with you and generally they were bad managers who hadn't realized they were no longer Senior ICs.
I think people who make and collaborate on strategic technical decisions need up close and personal perspectives on in the trenches technical work. I think non-technical managers have a very hard time detecting when someone is blowing smoke. I think former engineers can turn into non-technical managers fairly easily if they aren't proactively contributing actual patches and reviews to their projects.
Collaborative, blame free technical culture is ideal, yes, but it requires technical leadership and some amount of technical strategy. Someone (or some committee I guess) has to be able to decide when a project costs more than it makes. Only someone technical can actually estimate the projects. You can collaborate in and delegate that estimation, but there still needs to be a decision somewhere.
I've worked along-side and led multiple managers and have experienced various types of managers.
The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.
A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)
I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.
Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.
>have empathy and have more of people skill than technical or design skills
The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.
Experienced managers do have an idea of engineering problems because they have seen it before - seen it happen, seen it solved, et al. A manager that does not appreciate engineering problems either just graduated from a management course or is someone who never got involved deeply with a team.
A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.
Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.
In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.
> can't accept that the engineer can have some real objective concerns
This is the opposite of people skills. If a report has a concern that doesn't seem to make sense, it is the manager's job to help them structure a clear explanation of the problem, help identify the best solutions for said problem, and collaborate with stakeholders to pick the right solution based on trade offs they are comfortable with. To be fair, to an entry level report, that process--unless done in a truly excellent way--often does seem like a lack of sympathy or empathy for the developer's challenge.
Serious question: may I ask why, in describing a plurality of good managers, you chose to use a lot of singular feminine pronouns and no plural gender-neutral pronouns; while in describing a singular (one) bad manager, you avoided the use of a pronoun altogether in one sentence; used one plural general-neutral pronoun in another; and then switched from using the pronoun you previously extensively used when describing good things (singular feminine pronouns), to instead using the singular masculine pronoun? I was just curious if there was a story behind that or something.
Wow! I had to read this few times, aloud. I'd love to write like this. This is cool.
Anyway, made slight normalization to the plural/singular gender usage.
Yes. I'm usually called in when things escalate either with a team or with a client. So, one late evening (early morning for the client's timezone), I joined a client call with the team leads, including the project manager (hired about a month or so ago). The project managers keep eluding anything that goes to him, was evasive, keep blaming the team. I decided to cushion the blame, apologize to the client from the team and promised to be in direct call with him until the problems are solved. Luckily, I was able to rally the team, beg/borrow other guys from other team and turn around in few weeks. I confronted the manager (after talking to everyone in the project), asked him what he wants from the team, from his life, how does he really want to execute his role. Didn't go well. I think, I might have gotten him fired. In my defence, that was a good decision for the team and the company.
Serious question: Why does it matter? The masculine singular has been used through most history and in modern times it is as acceptable to use the feminine singular as a "general case" pronoun. His specific example was obviously about an actual, specific man.
My experience is the opposite: I find that managers who are not from a software engineering background are generally better.
In my experience managers from a software engineering background are usually lower skilled engineers who tend to overrate their own skill level and make bad technical decisions where a non-engineer manager would defer to the expert opinion of the people they manage.
I've had similar experiences -- a little knowledge is a dangerous thing. Both non-technical managers and technical managers who entered management after reaching the top of the technical ladder, are better than semi-technical managers.
I often institute a “just” $1 jar. Anytime “why don’t we just” or “it’s just” is uttered you have to put a dollar into the jar. This applies to engineers, managers, myself, everyone. The idea is breaking the habit of trivializing work that isn’t. Something like a dollar jar is fairly effective as a notifier but doesn’t necessarily replace the habit with a better one. Nevertheless the game itself seems to help even if dollars aren’t transferred into the jar.
Hmm isn't that just like a swear jar? You don't get rid of the swears or the trivializing but rather you just replace the particular words being used for the trivializing.
I think being called out for a bad habit is a step in the direction of replacing/improving it. In some cases it’s enough and the person caught figures out a better habit themselves. In other cases more techniques/actions are necessary. As it relates to this article the context was nicely set to illustrate the jar technique. Other contexts would need to be set to illustrate techniques related to situations where calling out is not enough.
Swear jar is a great analogy. Also, that'll be $2.
It's a game mechanic that encourages people to be more thoughtful about how they think about a problem. Not perfect, like the swear jar, but it has some value in changing behavior.
I like this idea. I wish more of the places I have worked had explicit guidelines around how to work as a team (e.g. don't trivialize work that isn't). It doesn't take many poor timed comments to shut down a team's discussion.
Sometimes we engineers do a poor job of communicating complexity: we have un-communicated assumptions that we think the listening party shares. Which sometimes lead to this:
"You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."
I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.
"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",
OR
"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"
Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.
He might have a point if a simple API-change impacts 170 test cases. This sounds suspiciously like "no functional tests but let's go for 100% coverage with unit tests" - not necessarily the efficient thing to do, from a management perspective.
That product owner might have a good point. Far too many engineers I know think 100% coverage is a reasonable goal and spend way too much time writing unit tests that don't add much value or worse add negative value.
I don't mean to be too flippant, but isn't this whole article an instance of exactly what the author is complaining about? Let's have good managers rather than bad ones. Good managers trust their reports to tell them the constraints of the work and factor that into the team's strategy. Being conversant in the underlying task helps a lot with that, but there are plenty of managers who come from an engineering background who make the same mistakes the author laments.
That's what I was thinking. Really, the problem with most managers is that they are not empathetic with both the business side and the tech side at the same time. Good managers know how to set expectations and communicate with correct language when talking to either cohort.
In my experience management was either good an bad. I think that culture was the most important thing at the end of the day. Engineering is not everything when productivity is important as well as environment.
In some cases/team there is the need of an extra effort in order to balance resources AND people.
If I could pick a manager from a pool I will probably take someone with experience in people first and docker later...
At the end manager that are open to listen to the team and the customers will probably take the right choice in term of technology.
Stop calling it engineering...engineering is a degree that requires an incredibly rigorous formal training and education. Call it what it really is, there's no shame in the word developer or programmer, wear it with pride, but don't just appropriate words, it is beneath you.
What does formal training or education give you that many years of diverse and relevant experience coupled with professional mentorship and self-learning doesn't?
This sounds like the rantings of someone who has had some pretty bad managers and has never managed anyone else.
My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.
Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.
Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.
Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.
As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.
I've thought about that a lot and my conclusions weren't what I expected as a programmer.
The issue is that, someone has to talk to the internal customer [0].
Now if a programmer do the talking with the internal customer, then I believe, he will naturally become some sort of a surgeon ala Mythical Man-Month [1].
Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
Problem is, I believe the surgeon method cant work in practice for 2 reasons, 1) programmers dont want someone who tell them how to code, 2) even if people would want a surgeon, since the surgeon both need to be a great programmer and a great politician because he will naturally speak to the internal customer (because eh, hes the surgeon), hiring for that position becomes difficult - and you'll end up generally with a great politician that sucks at programming, which makes (1) even more pronounced.
The only way you can get rid of the project manager is to make the team the internal customer. That's the case at Valve [2] I believe.
In the mean time, the best thing to do is to work with project managers who were engineers before.
[0] I know what you think: a project manager isn't only talking to the internal customers. Yes, that's correct but the rest of his job is similar the one of a secretary. Nothing that would put guy on top.
I think there is value of management in all cases wrt processing corporate beurocratic paperwork and even for resource allocation of staff to initiatives.
You get into trouble with non-SME managers that start directing the way people solve a problem or prioritize what work gets done.
Something I have wanted to ask the HN community, that this article brings up: what exactly does a scrum master do?
From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
But what I can't figure out, is what they are actually supposed to do. At best, I see two points:
1. They do the traditional work of a project manager but on a team level, and communicate status up.
2. They are supposed to be some kind of "thought leader" on agile methodologies.
Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?
I've never had a scrum master across 7-8 companies. Usually it was a rotating role, or a manager/tech lead. But certainly not one person dedicated to it.
spotify seems to have a few professional scrum masters and it seems to work for them. I'm less interested in typical cynicism and more interested in how this gets done -well-. Any spotifier's care to comment on having fulltime scrum masters?
edit: It seems they are called "Agile Coach"es.. is that any different?
>I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.
Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.
To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?
Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.
In my company, each team has a scrum master (a SM being part of 2/3 teams). They have near-zero technical knowledge, and this is what they do (no particular order):
- Give an organisation to the team, and make sure that this organisation does not decay with time
- Help the devs work faster by helping them with the methodology
- Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task
- Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...
Minor tasks:
- Organise meetings/demos
- Lead the meetings, make sure they're productive
We're a service company without management, "communicating status up" is a concept that doesn't exist.
> This is probably the most important task - Help the client to lead his project
For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?
You need experienced managers as the size of an organization grows. For development teams you need an engineering manager to work with product to design stories, orchestrate work with other teams, and to provide technical mentorship.
The author conflates "all managers" with "project managers." and implies this is some artifact of the hegemony. My experience with project managers is that they are largely an artifact of waterfall-style software development and are not as necessary today in agile environments. But they can be helpful in the orchestration of large-scale projects.
I've personally never been in a situation (I've worked in software development for over 25 years) where we were hiring an engineering manager, and hired a "business type" instead. I'm hiring a development manager now, and the first step in that process is a coding interview. They cannot go further unless they pass that.
This whole article reads more like an us-vs-them rant than anything else.
Yea, I picked up on this too. I was pretty confused reading through the rant. Is his beef with his engineering managers or with his project manager(s)? It looks like he's frustrated with project managers.
My rule of thumb for "how you know you need a project manager": As a manager of engineers, if you find you have more E-mails than you can possibly respond to, or more meetings than you can possibly attend, or more people "pinging" you than you can possibly satisfy, then you need a project manager.
If you're an individual contributor engineer, you probably are not in the position to even know if you need a PM or not, especially if your manager is doing a good job.
Maybe I've just gotten extremely lucky, but in the 15+ years I was doing software development, with one exception (a CEO where I was employee #1), I never had a "non-technical" manager to whom I reported. Where are these companies that hire someone who literally knows nothing about engineering to lead a group of engineers? I'm not saying it doesn't exist but I've never seen it.
I've seen my share of non technical product managers, project managers, etc. but not engineering team managers. In all cases my engineering leadership were technical all the way up to at least the SVP level.
EDIT: So, I got to the end of OP's rant and it looks like he's shifted his target from "managers" in general to project managers. He might even be confusing the two.
A. Engineering Management shouldn't micromanage, but a manager can be invaluable in helping resolve interpersonal conflicts and escalate issues. They can be the "bad guy" when dealing with someone the team reports is consistently underperforming or engaging in poor behavior.
B. Are you an engineer or a technician. An engineer "just" creates fixes. A technician will implement it. Lines blur in programming more than other fields, but some "engineers" make a big deal out of just figuring out solutions that have been solved many times before, like making a backend call.
149 comments
[ 3.0 ms ] story [ 228 ms ] threadI've seen such a thing, taken to an extreme where lazy, underskilled developers were running the show; overcomplicating, underdelivering, yet showered with praise -- and it's horrible to witness. A word of warning for anyone entering such a world: you will not change this environment and any attempts to do so will trigger an immune system response. The developers and clueless managers will circle the wagons in defense of the existing culture.
Lesson learned: don't interfere with "resume-driven development" organizations.
I suggest the following interview question: "Tell me about the technical capability of your management chain."
What about managers who have had experience like a decade ago and don't do much tech experience anymore.
I am stuck in such management chain at work where some guy up top thinks he is technical enough to dictate solutions based on couple conference youtube videos that he watches.
Half knowledge and false sense of technical prowess is more dangerous imo.
A manager should have the big picture and communicate it to the team. Then you could avoid a team member wasting time on something that’s not in the greater objectives or roadmap.
Do you think any of the "bullshit engineers engage in with respect to fad chasing, bikeshedding and other negative practices." will change in 20 years?
Its been almost 20 years since first coined and we _still_ have bike shedding problems
A number of the examples in the article are just bad management, and things I’ve heard from managers with years of engineering experience.
YMMV
If you’ve ever been on a project with more than 1 or 2 people without a manager—or where the manager doesn’t do their job—you would know how insane this sounds. It does not work. Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.
Someone has to set meetings, someone has to call out issues, someone has to communicate with upper management and other teams.
No-manager really means distributed management or an informal manager. Because the essential work a manager does has to be done by someone.
What is a manager?
I've worked on many successful teams (including projects with 100+ devs) without formal managers in the typical hierarchy sense.
You just need a combination of program managers, project managers, product managers, and architects.
All of those roles are quite different from the traditional manager - for example none of those "managers" had strong authority over the developers day to day work the way a manager typically would. Nor did they speak on behalf of the developers.
No, you need someone to coordinate them. It does not need to be your manager. Plenty of matrix and matrix like organizations which have split the two.
Managers just need to enforce who that person is and resolve people (not product or business) disputes.
On the very best projects, individuals will step up and lead for a while, then decide to do other things and let someone else run the show a little. Maybe it will be feature ownership, or to handle a different phase of a product in its ship cycle. (Meanwhile there will be managers behind the scenes, hopefully not many, making sure that forms are getting filled out, HR duties are attended to, and nonsense meetings are canceled and kept canceled).
Most of the places I've worked could have used less management. A lot less.
As a thought experiment, if management were 'just a role' and people could switch into for a period of time and then go back to their 'real jobs' with no loss of pay or prestige, that might lead to some interesting effects.
(warning, anecdata:I've worked on teams where the 'manager' role was cycled among engineers/testers/designers etc throughout the project lifetime, and it worked well. I've also seen managers come back to being full time developers, and their perspective from the time of being managers really helped with their effectiveness as developers)
I've worked with managers who thought they were somehow superior to the people they manage. This seems to be a common issue. They tend to experience a high attrition rate.
I've worked with both engineers-turned-manager and "business" managers, and both have had ups and downs. But the tech industry's love of taking individual contributors and pushing them into management roles without any management training or even interest in managing people seems to be the failed experiment.
Why do you assume an out of date and no longer practicing manager will have a better chance of catching errors than causing them? There is a reason you hire experts and that reason is not so you can ignore them. If you're afraid of a single point of failure then you foster a collaborative blame-free culture where the engineers cross check each other.
I've had managers who would agree with you and generally they were bad managers who hadn't realized they were no longer Senior ICs.
Collaborative, blame free technical culture is ideal, yes, but it requires technical leadership and some amount of technical strategy. Someone (or some committee I guess) has to be able to decide when a project costs more than it makes. Only someone technical can actually estimate the projects. You can collaborate in and delegate that estimation, but there still needs to be a decision somewhere.
I've worked along-side and led multiple managers and have experienced various types of managers.
The good ones usually stood out. A good manager is usually the ones that shield their teams from the onslaught of clients' un-managed demands. She is the one that liaises effectively between a looming deadline and the sanity of the team. She is the one making sure the clients are making their timely payments when the work is delivered/deployed or milestones met. She is the one who knows the right way to calm down an angry client when something is not happening the way it should - missed deadline, bug regression. A good manager knows her limitations, and also her power.
A bad manager is usually the one that instigates one against the other. Takes credit and sweet talks with the upper management. She blames the team when things go wrong. A manager, who reports to me, once told me, "why should I be the one to say anything now, the client is pissed and we missed the deliverables. I'm not responsible." (btw, he was fired the following month.)
I believe I'm technically sound, know a thing or two about design and I've led multiple projects with multiple project/product managers. I love the ones that are ready to go with me frontal assault on problems and challenges.
Engineering managers are a good fit for an all-out engineering team. But at the end of the day, I believe managers need to be better human characters, have empathy and have more of people skill than technical or design skills. Design/Engineering — that is what the team is for.
Edit: Plural/Singular Gender normalization.
The problematic ones i've seen had some people skills, or they were thinking they had. The problem was when they did not understand engineering problems, and were thinking that everything was a people problem/issue. So they either assume that the developers are lazy, or they simply can't accept that the engineer can have some real objective concerns. So its either they don't understand however hard you try to explain or they try to understand it is a people/personal problem, when it is not.
A manager has to answer to multiple people — clients, upper management, stakeholders, Jira. Unfortunately, she is totally dependent on this teams to get things done. She is utterly handicapped when it comes to doing anything useful, read, "engineering". Which is when most managers break and shows their character — they either break, blames people, do not listen, do not understand or they figure out who can help, seek help and find the right person to get things done.
Well, engineers, sometimes get it easy — they just have to solve a problem and make 2+2 = 4. They answer to one person; perhaps the manager. Think of the manager and to whom she is reporting and taking the fall. If the team does not get things done, they're the ones usually blamed.
In the early days of my career, I used to think that managers, middle managers are pretty useless. Now, I believe everyone has their roles to play a part in the whole machinery of 'the cogwheel'.
This is the opposite of people skills. If a report has a concern that doesn't seem to make sense, it is the manager's job to help them structure a clear explanation of the problem, help identify the best solutions for said problem, and collaborate with stakeholders to pick the right solution based on trade offs they are comfortable with. To be fair, to an entry level report, that process--unless done in a truly excellent way--often does seem like a lack of sympathy or empathy for the developer's challenge.
Anyway, made slight normalization to the plural/singular gender usage.
Yes. I'm usually called in when things escalate either with a team or with a client. So, one late evening (early morning for the client's timezone), I joined a client call with the team leads, including the project manager (hired about a month or so ago). The project managers keep eluding anything that goes to him, was evasive, keep blaming the team. I decided to cushion the blame, apologize to the client from the team and promised to be in direct call with him until the problems are solved. Luckily, I was able to rally the team, beg/borrow other guys from other team and turn around in few weeks. I confronted the manager (after talking to everyone in the project), asked him what he wants from the team, from his life, how does he really want to execute his role. Didn't go well. I think, I might have gotten him fired. In my defence, that was a good decision for the team and the company.
I don’t think it matters from a content perspective, but is a bit more confusing so I had to spend a few seconds thinking about it.
I had a similar thought as OP as to whether this was significant.
But it wasn’t a big enough deal for me to comment as I figured it out, reach much the same conclusion as you did.
In my experience managers from a software engineering background are usually lower skilled engineers who tend to overrate their own skill level and make bad technical decisions where a non-engineer manager would defer to the expert opinion of the people they manage.
However the timeline I've experienced is different:
* You have a great engineer or lead who knows the project inside and out
* They are promoted to management.
* They still know the project inside and out plus were recently coding so they dictate how things are done technically. It works great.
* They get put on a new project which they don't know inside and out.
* They dictate how things should be done technically because it worked for them in the past successfully. It works horribly.
So what's the benefit?
It's a game mechanic that encourages people to be more thoughtful about how they think about a problem. Not perfect, like the swear jar, but it has some value in changing behavior.
"You could prepend the words “it’s just” to anything, it’s not going to change the fact that you sound completely ignorant and will ignore any challenges that your team communicates to you."
I have often found it effective to counter "just-justifications" with the right representation of complexity. E.g.
"Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",
OR
"Yes, it's just a library change, but there are 450 sites in our code that use the library and out of those, 50 involve financial calculations"
Almost always, the manager appreciates this because you would have brought to his attention a problem that would otherwise gone under his radar.
"See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...
IMO, a manager should understand the complexity of the work of his employee at an approx. ball park level.
I don't mean to be too flippant, but isn't this whole article an instance of exactly what the author is complaining about? Let's have good managers rather than bad ones. Good managers trust their reports to tell them the constraints of the work and factor that into the team's strategy. Being conversant in the underlying task helps a lot with that, but there are plenty of managers who come from an engineering background who make the same mistakes the author laments.
In some cases/team there is the need of an extra effort in order to balance resources AND people.
If I could pick a manager from a pool I will probably take someone with experience in people first and docker later...
At the end manager that are open to listen to the team and the customers will probably take the right choice in term of technology.
The author apologizes for speaking in unqualified absolutes, but does so constantly.
Even if the author is right, this article reads as pretty childish.
My schooling was Computer Engineering, my career started as a Software Engineer and has wound all the way up to Director level. I’ve been on both sides of this equation for a long time.
Your typical “just a manager” has to spin so many plates and babysit so many people that most real “engineer types” would loathe the job and frankly, not be very good at it. I struggled mightily as a team manager where there were a lot of competing priorities, personal issues, and directions that I needed to follow. As I got higher up the chain of command the job got easier, I had less direction I had to conform to, I was thinking architecturally and in longer terms– and I didn’t have daily interpersonal drama to deal with.
Management isn’t for everyone, engineer or not. It’s a lot like parenting: Most people are just making it up as they go, trying their best, and the best ones generally put others before themselves.
Put the idea that Engineers should be these lone wolf rockstars that just to get to do what they want, regardless of corporate objectives or market positioning is ludicrous.
As an engineer, I can confirm that we’re just as short sighted and dismissive of other people’s work as they are to us.
The issue is that, someone has to talk to the internal customer [0].
Now if a programmer do the talking with the internal customer, then I believe, he will naturally become some sort of a surgeon ala Mythical Man-Month [1].
Mills proposes that each segment of a large job be tackled a team, but that the team be organized like a surgical team rather than a hog-butchering team. That is, instead of each member cutting away on the problem, one does the cutting and the others give him every support that will enhance his effectiveness and productivity.
Problem is, I believe the surgeon method cant work in practice for 2 reasons, 1) programmers dont want someone who tell them how to code, 2) even if people would want a surgeon, since the surgeon both need to be a great programmer and a great politician because he will naturally speak to the internal customer (because eh, hes the surgeon), hiring for that position becomes difficult - and you'll end up generally with a great politician that sucks at programming, which makes (1) even more pronounced.
The only way you can get rid of the project manager is to make the team the internal customer. That's the case at Valve [2] I believe.
In the mean time, the best thing to do is to work with project managers who were engineers before.
[0] I know what you think: a project manager isn't only talking to the internal customers. Yes, that's correct but the rest of his job is similar the one of a secretary. Nothing that would put guy on top.
[1] https://ia801903.us.archive.org/19/items/mythicalmanmonth00f...
[2] http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...
You get into trouble with non-SME managers that start directing the way people solve a problem or prioritize what work gets done.
From what I have observed at one business, there is one scrum master on every team. Many of them know nothing about the business that business does, and have no technical background. I have seen developers spend sometimes an hour or more a day explaining to scrum masters what they just built, so that they can then go "communicate that up" to upper management or project management in opaque meetings developers aren't allowed to attend.
But what I can't figure out, is what they are actually supposed to do. At best, I see two points: 1. They do the traditional work of a project manager but on a team level, and communicate status up. 2. They are supposed to be some kind of "thought leader" on agile methodologies.
Can HN help shed some light on what this role should do? Perhaps my background has just been a bad experience in this regard. I suppose where I get stuck is, this seems to be the work that a dev lead used to do. Why make a full time job for a non-technical person to lead a technical team, below the management level?
Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.
edit: It seems they are called "Agile Coach"es.. is that any different?
Your scrum masters really aren't. The SM role is supposed to be a few minutes a day, and focus more on how people work rather than the technical details.
Examples are things like telling management that the team has often missed deliverables because a key resource (some piece of hardware, etc) is often unavailable. Or even telling managers that their employees think one of the manager's policies sucks.
To an extent, it's about holding the team accountable as well: Why are some people working on a lower priority item when no one is working on a higher priority item?
Don't get me wrong - I'm no fan of scrum, and am not saying a SM is needed. But, as with management, a good SM is a valuable contribution to the team.
- Give an organisation to the team, and make sure that this organisation does not decay with time - Help the devs work faster by helping them with the methodology - Help identifying & solving problems (a problem goes from "a dev spent one hour more than expected on this ticket" to "the client has no vision on what the product should be"). This is probably the most important task - Help the client to lead his project. This is a huge part too, the client does not know how to lead a project (they just came to us with a business problem they want to solve): there's no way the project will succeed if the client doesn't manage to have a clear vision for his product, prioritise tasks, build indicators, get user feedback...
Minor tasks: - Organise meetings/demos - Lead the meetings, make sure they're productive
We're a service company without management, "communicating status up" is a concept that doesn't exist.
For someone to do this, they would have to have client communication skills, at least somewhat thorough understanding of software development or the process, and an understanding of the client's business. I see this as a good thing. However, your example sounds to be a company that has external clients that you write software for. Do you not have account managers/principle types who interact with the clients, or is that more or less what a scrum master does there? Just curious, if you were an internal only dev shop that just develops software for stakeholders at your own company, would you see the role of a scrum master as significantly different?
The author conflates "all managers" with "project managers." and implies this is some artifact of the hegemony. My experience with project managers is that they are largely an artifact of waterfall-style software development and are not as necessary today in agile environments. But they can be helpful in the orchestration of large-scale projects.
I've personally never been in a situation (I've worked in software development for over 25 years) where we were hiring an engineering manager, and hired a "business type" instead. I'm hiring a development manager now, and the first step in that process is a coding interview. They cannot go further unless they pass that.
This whole article reads more like an us-vs-them rant than anything else.
My rule of thumb for "how you know you need a project manager": As a manager of engineers, if you find you have more E-mails than you can possibly respond to, or more meetings than you can possibly attend, or more people "pinging" you than you can possibly satisfy, then you need a project manager.
If you're an individual contributor engineer, you probably are not in the position to even know if you need a PM or not, especially if your manager is doing a good job.
"... teams with great managers were happier and more productive..."
In my opinion, it's not about having no managers---it's about having managers with the right mindset, qualities, and behaviors.
I've seen my share of non technical product managers, project managers, etc. but not engineering team managers. In all cases my engineering leadership were technical all the way up to at least the SVP level.
EDIT: So, I got to the end of OP's rant and it looks like he's shifted his target from "managers" in general to project managers. He might even be confusing the two.
B. Are you an engineer or a technician. An engineer "just" creates fixes. A technician will implement it. Lines blur in programming more than other fields, but some "engineers" make a big deal out of just figuring out solutions that have been solved many times before, like making a backend call.
This is my perspective as an engineer.