Let’s have no managers, instead of managers with no engineering experience | Hacker News Reader

Let’s have no managers, instead of managers with no engineering experience

medium.com

228 pointsfitpolar143 comments

> Business types with none to little engineering experience should never, under any circumstances, manage engineers

In my experience as a developer at a bunch of different companies, the worst managers have actually been the opposite -- they were ex-engineers who knew nothing about management and decided to become managers for the wrong reasons (small raise, more power, etc), and had no passion for management. The longer one's career, the more one comes to respect managers, I think, and understand what a skill it is unto itself. Many young engineers have times when they feel hostile towards management or even the idea of having a "boss" at all, but that just makes the situation worse. One needs to have a more collaborative attitude to succeed. Again, it's the ex-engineers who think managements is just "common sense" are the ones you need to steer clear of.

Curious if you have any advice for engineer->Dev manager?

I'll second that. The worst I've seen have always been engineers or developers who felt that seniority, in terms of years on the job, entitled them to a management role regardless of any ability or training for it. They inevitably engender a tremendous amount of friction and resentment in their peers and subordinates.

As for younger developers, I manage several right now. Showing them that a management role isn't about "bossing people around for the sake of it," but more about handling different areas of responsibility needed for projects to succeed - some technical, some not - really works.

In addition to that, it's been my experience that their Engineering skill diminishes over time, like any other skill that isn't getting the maintenance that it requires, and they seem to be largely unaware of that. Despite their now-undersized technical knowledge / capabilities, they can still be found forcing technical decisions against the better judgement of their departments actual technical leadership. I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him. We gamed that, of course, because we had to, but it was still tacking days on to "decision making" that we had to suffer through just to do our jobs.

Want to watch an Engineering team go from: can produce and deliver to doesn't have a clue? Just get yourself a couple of these jokers to be your Engineering teams management.

> I've also had this same style of manager become a rate limiting bottleneck by forcing _all_ cross-team decision making to route through him.

I've seen that work incredibly well when the manager in question did keep up on his technical skills.

It can result in a very well designed and consistent system.

It also burned out the dev manager in question after two and a half years.

A strong talented leader can make a huge difference. Applying the lessons of the past means a lot of engineering mistakes can be avoided.

Also, at some point, decisions do have to be made. There will be a disagreement on the team about a direction to take, and having a benevolent dictatorship becomes very useful. Especially in a corporate setting where forking and doing both paths can be disastrous (both paths get underfunded and fail), or just not viable.

I had former-engineer managers, who were the first to acknowledge that their technical skills weren't up to date. It makes a huge difference if you can explain a technical problem to someone who has solid base skills in the field or if you have to dumb it down to layman level.

Exactly.

Recently I interviewed with a company that had promoted their Senior Dev into a management role.

When a company VP emailed this guy to say a website form wasn't working, costing the company tends of thousands of dollars every day it was down, his response was, "Thank you for alerting me to this situation. I will process your request and respond within 2 business weeks."

Obviously, they'd taught him that boilerplate to help him adjust to interfacing with the business, but he lacked the common sense to realize the house was on fire.

They also said he preferred honing his coding skills and being perceived as a 'master developer' but couldn't quickly produce a list of in-flight projects, and that things were way behind schedule.

Having a bad manager who's a business type does not mean you don't need managers or all business types are bad managers. I mean, what's the sample size you're working off of? Less than 10?

I know it's unpopular on HN and elsewhere to stick up for business types at the perceived expense of engineers but managing people is a very hard thing to do, and the skills that make a great engineer too often make for bad middle-management, IMHO.

Totally agree with you on this point. It’s easy til it’s your job.

I’ve seen so many programmers put in positions of authority that were just disasters because many programmers are used to having full control of a system.

The transition usually boils down to people who believe in rigid control vs people who believe in tuning the environment to help others be more effective.

Rigid controllers are generally terrible managers. Environment tuners are essentially trying to serve other employees and the business by making it easier to do their jobs.

> The biggest misconception engineers have when thinking about moving into management is they think it’s a promotion.

> Management is not a promotion. It is a career change.

http://fractio.nl/2014/09/19/not-a-promotion-a-career-change...

“Not a promotion” except that you get more money, respect, influence...

While I won't go so far as to say "never, under any circumstances", I don't think you have to choose between engineering and competency though.

In a reasonably varied group of 6-8 engineers, one in the course of his career will have both desire and aptitude for management.

Probably even more than one.

I would like to get a bit of HN feedback on the matter. I am exactly the person mentioned here - an engineer who knows nothing about the management, but because company is growing and we're hiring new people I'm slowly transitioning towards a management position. Just like you've stated I know nothing about the management and all I have is a common sense to guide me which I'm afraid is not enough on multiple occasions.

I'm especially afraid of too much micromanagement, but I don't really know how to handle the process better. Here is my style of management, briefly summarized:

I have a very deep and detailed knowledge of all of our codebase, which is in it's entirety shared by noone else at the company. I've written half of it myself and the other half has been written by other people. Most of our hires have been hired between a year and few months ago (company is very young by itself).

What is the usual process for me is that I discuss the general direction and required features with top-level management, who is entirely nontechnical and make a roadmap in my head with plans for the "subprojects" which are more or less self-contained units of work, their time estimates and relative priorities with respect to company-wide deadlines.

Based on the last two, I dispatch the tasks to relevant people, waiting when they finish previous tasks. I try not to stress people with too many tasks at once, but treat "tasks" more like a priority queue, where when a person becomes available a current highest-priority task is taken out from a queue and assigned to a person, taking into account personal technical strengths and weaknesses as well.

Most of the time, when giving a task to a person, I already have solution implemented "in my head" and the process mostly revolves around me explaining the relevant part of the codebase to a person and detailing the solution I've envisioned with special emphasis on the parts where a mistake is more likely to be made. After the implementation is done, I take part in testing and perform a code review before merging the code in the production branch.

Sometimes I wish I would give people more freedom, but on the other hand maintaining project coherency and keeping a single direction for the whole team I feel requires for me to make final decisions quite often. I plan to hand off ownership of certain "modules" in some time in the future, but first I'm waiting for deeper understanding of the codebase to develop in the reports.

On the outside, to me, it seems that the process works. People are not complaining, team makes progress, features are done on time and seem to be of satisfactory quality. But like you can read above, I'm base strongly on detailed technical knowledge and basically "planning the work ahead" for the people.

I would really appreciate if anyone could share their experience with making that transition.

I would suggest to you that perhaps a good place to go from where you are is to start getting input into your solution from your new team mates. This allows you space to guage their quality, and make them feel like their input is important, as time moves on, you will then be able to understand where the good people lie, and hopefully allow you to give them more control.

This is the kind of thing that will probably lead to your team being able to grow and feel empowered, and hopefully mean that you can take more time to carry out more managerial responsibility, and give you trust in your team. A secondary advantage is that you let go of being the some holder of all knowledge, which could burn you out in the long term.

Also, perhaps allow code reviews in both directions, as it means that you can see how your input had made them look at other people's code and choices, hopefully giving your business the ability to self manage and to ensure that practises are followed consistently, even if your eye is not on the ball at all times.

This kind of thing had helped me make the transition, although I have to admit that taking my eye of the ball sometimes for too long has led to bad code in our projects and codebase. But that's where you go back and share that with your team, and those that may need greater support. Just remember you are one person, so don't expect to carry out all the work by yourself, empower those around you and give them greater fulfillment over time.

Thank you very much for sharing. I can see quite a few very valuable suggestions here. I'll try incorporating that in my way.

I gather those who report to you are on the junior side?

Junior to mid-level.

Well, the real answer is years of on-the-job experience, but to give you a super-brief version:

It's a common pattern that new managers want to treat direct reports as a set of extra hands. That's fine for the purpose of getting code out the door when developers are junior, but it's irritating at mid to senior level, and it doesn't help anyone grow or think for themselves. Your job is to train them to do those things.

Ask questions. Wait for the answers. Then ask follow-up questions to help them identify problems with their solutions. Self-discovery is more powerful than being told the answer.

Think about their career growth. Ask them about what areas they want to grow in and then try to give them those things.

Fill in the gaps on the team. Let others fill the gaps where they can.

Some of your reports have a year of experience in your code.

1) Do they not propose tasks for bug fixes and refactors?

2) Are engineers encouraged to propose their own solutions?

3) Do you only assign tasks you know how to do yourself?

1. Yes, that happens, although constitutes around 10-15% of work being done.

2. I am certainly listening to any suggestions, but don't necessarily actively encourage it before proposing a solution. Perhaps this is a direction I need to move towards.

3. Mostly yes, as overwhelming part of the complexity just comes from knowing how various parts of the system interact. From time we have an open-ended 'research' (where the outcome is not known upfront) project, but these have a very mixed success rate and tend to overextend the time budget.

You say it takes over a year for people to understand your whole system?

I'd recommend looking into why the ramp up time is so long.

Especially if you only assign tasks you know how to do, you are likely hampering your systems ability to become simpler.

For example, recently we took away 1000s of lines of nuanced code by using an out of the box cloud service (which none of us knew how to use). It offers a similar interface, and it's cheaper and easier to use. Took a week to play around and research if something else was more appropriate, took another three weeks, and we deleted 10% of our code.

I'm basically the same, maybe a little less on the actual technical direction. What I feel is the biggest disadvantage is that you are the bottleneck for anything to move forward. I'm not sure yet on how to solve that.

A few changes you could try: - have the developers make their own estimates - instead of explaining all relevant existing code, only point to where the relevant parts are or what terms to search for) - if there is a designer involved in the features, try to get them better at making specifications, so developers can work directly with the designer instead of having you in between doing 'translation'

I think you've confused project management with management. The two are not the same thing.

He's a line manager. What do you think he should do differently?

Cultivate a team spirit? You tell me.

It's your objection so you tell me, if you actually know what you are talking about.

You should think about how your behavior on HN might impact your reports.

I don't have much more experience as a manager than you do but here are some thoughts. 1. Share the roadmap with your team once confirmed by management 2. Don't force your implementation on the team but let them come up with it and use it as long as it is good enough 3. The time will never come that you feel that your reports are ready for hand over - it will only come by necessity when you are asked to take on more responsibilities so that you have no choice but to hand off this work. So, you may as well start the hand over today as there will never be a better time.

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

Yes, 100% agree!

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

It depends.

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.

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

I think it matters as much a clear writing and proper grammar matters.

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.

I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here.

Instead of an essay, I'll use a modern writing format: the pithy list.

1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success. It's a very complex juggling act that most people are thrown into with no training, because training for the technical aspects is so bad.

2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.

3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers? Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.

4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter! It contradicts at least half of what the prior argument said.

This is well-said. To add some anecdata, I work in a “managerless” organization. It sucks. It’s hard or impossible to make certain changes because nobody has any authority to do things that aren’t necessarily politically sexy (e.g. fixing bad security or setting up asset management). There’s also this expectation that if you want to do something, you can just do it. This sounds great on paper, until you realize that doing things like managing infrastructure is a full-time job for an entire team, and not a “once in a while” position for someone with little experience. I’d love to go the extra mile, but I only have 40 hours or so in my work week, and I’m busy with my actual assigned tasks.

There needs to be a good balance (obviously too much red tape is counterproductive). Having managers can be nice when it explicitly assigns roles and responsibilities to a group, because that means not only are there dedicated people for certain tasks, but presumably they have a modicum of power to get things done. It also makes it plainly obvious whom you talk to if you need, say, a new laptop, or a printer set up, or a VPN account. Without managers you get company-wide emails like “who controls our website? I need to update something.”

> I wrote 1000 words on this subject and prior spectacular failures of the "no management" style in Silicon Valley. I deleted it. No good can come of talking about it here.

Well, put it this way: I've worked in more- and less management-oriented companies, and have found that those that were less heavily managed were both better working experiences for me and more effective as businesses.

> 1. This article gravely underestimates the difficulty of engineering management. One must simultaneously handle HR functions, he roadmap of their team and other teams, and their reportee's opportunities for growth and success.

If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier. Some of those activities can be separated (e.g. having distinct "team tech lead" and "team line manager" positions), line employees can be empowered to do some of them themselves (personal development), and some simply don't deliver enough value to be worth doing at all (maintaining technical roadmaps).

> 2. This article's author forgets or is simply too lazy to look up previous examples of failure. Further, they're ignoring other attempts to systematize an "unmanaged" environment and what challenges people face there. It's unfortunate that they chose to pen such a long and effort-laden essay without doing sufficient research first.

I think it's entirely reasonable for them to write from their own experience rather than mixing first- and second-hand information in the same essay. Their essay makes a positive contribution to the conversation; concrete experiences of failure of alternative approaches would also be a positive contribution (far more so than low-content "they didn't research" complaints).

> 3. The author of this article also seems to totally ignore the coordination and management functions required of microservice organizations. Presumably because as an engineer who specializes in delivering one single single-purpose executable on top of everyone else's microservice architectures, they may not have a ton of experience with it. Who is doing this if not engineering managers?

You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action). Better to give teams responsibility for delivery of client-facing functionality and have shared ownership of any common code; you write the functionality you need for the features you need. If you have a layer that really creates enough value to be worth other teams using it as a product, treat it as an actual product (ideally make it an actual product that you sell), and have a client-vendor-like relationship. Otherwise, a certain level of duplication of effort ends up being much less of a cost than constant between-team coordination would be.

> Product managers can have some mechanical sympathy, but it's seldom their job to deeply roadmap out features.

You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".

(Of course occasionally a specific feature will require deep technical coordination with another team. But that coordination is best done by the person with the responsibility for delivering that individual feature - the line worker.)

> 4. This article ends suggesting that you don't need engineering managers to deeply understand the larger technical roadmap for your company and translate it to your team, but might find room for process custodians like scrum masters fix this problem? What? What even? This isn't even wrong. This is tantamount to suggesting the engineering itself doesn't even matter!

Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves - they're the people who will have the information they need to make those decisions. Software architecture is a lot more flexible than people tend to think; even on a large codebase delivering complex functionality, it's surprisingly easy to make radical architectural changes, and often the biggest impediment to those is well-meaning "architectural design" that exists solely due to management imposition rather than being driven by any actual functional requirements.

> If managers fail because the role is too hard for them, we can't expect to get better people, we need to make the role easier

Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.

It's telling to me that rather than elevate the role you're more inclined to destroy it.

> Their essay makes a positive contribution to the conversation

If this weren't a post-Zappos, post-Github, post-Uber world it might. As such it reads like a stale take from 2009, to me. But sure, we can just ignore the cycle of failure in the industry and keep writing the same stale think pieces. Hey check out my fresh new monad tutorial while you're at it, Monads are like burrito aquaducts where the black beans and delicious salsa flow from computation to computation across the continent.

> You're putting the cart before the horse there; in my experience a vertically-layered "microservice organization" like you describe is the product of overmanagement (Conway's law in action).

I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.

Please don't misrepresent my argument in your rush to dump on the idea of management.

> You don't need a deep technical roadmap, only a product roadmap, because you integrate with other teams at the product level, not the deep technical level. Even in the presence of relatively good management I've found that that's what works best. Think Amazon's famous "platform memo".

Funny then how Amazon has technical management. But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.

> Engineering matters, but planning of engineering has been a counterproductive activity every time I've seen it attempted. Planning and management should be done at the feature level; when it comes to the technical "architecture", trust your technical professionals to figure it out themselves

This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist, while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department.

P.S., I apologise for the brevity and potential grammar errors. I wrote this on mobile, figuring a prompt response was more useful than an expansive response.

> Or maybe we need to start recognizing that engineering management is a thing that has value, requires training, and is distinct from being an engineer with a strong personality.

I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

> It's telling to me that rather than elevate the role you're more inclined to destroy it.

What it should tell you is that in my experience, steps in the direction of destroying the role have resulted in better outcomes, whereas steps in the direction of elevating the role haven't.

> I've described, with the most pessimistic lens, 2 layers of management to the top of your company, with a focus on team collaboration. Having managers with strong engineering experience and technical sympathy decreases the depth of your organization, it doesn't increase it.

I was thinking about technically-vertical rather than organizationally-vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management. That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon. You want to be in a position where whichever team needs a piece of functionality for a given feature that's their responsibility can simply implement it, whichever layer of the technical stack it resides in - where the only responsibilities that could belong to other teams are product-feature level responsibilities, not technical-area responsibilities.

> But as an example of planning, imagine a platform team runs a flight of APIs. There are multiple clients to these APIs all shipping products. Each has their own feature needs. If those teams collaborate on dependencies and optimize around what they need, everyone gets what they need faster. Not coordinating or planning provides a random outcome in a space dominated by sub-optimal outcomes.

It's an appealing thought, but it just doesn't match my experience of how it works out in practice. The best outcome is often one that isn't imagined - is barely imaginable - until it emerges from the technical constraints (a la http://wiki.c2.com/?WhatIsAnAdvancer ). Letting API feature implementation happen just in time under the person who has a direct use case for that feature raises both the ceiling and the floor on the implementation quality: they're working under the best conditions for inspired insight to happen, and the fact that they're using the feature means their implementation will at least work and fulfil at least one use case, and then the second user of the feature can expand it to suit their use case while keeping the existing use case working (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable). The absolute worst case is that the API ends up with two parallel but different implementations of the same feature to fit two different use cases, which is non-ideal but not actually all that bad in the grand scheme of things.

Whereas planning and coordinating via management as I've seen it practiced just goes wrong too badly, too often. You agree on an approach that everyone who comes to actually use the API agrees is wrong, but no-one wants to revisit the decisionmaking process. Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - or worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

> This entire discussion is predicated on the notion that your managers are technical professionals facilitating this. It's weird how many people refuse to accept the idea that people can exist

I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation. Even if they did exist, I haven't ever seen an organization that was able to systematically identify, recruit, or train that skillset, and I do think they've been trying quite hard in various ways.

> while in the same forum glorifying hybrid roles like startup CTOs in the same forum who are obligated to do a lot of management functions AND be the basis of a strong technical department

I don't think I've ever been one of those people, but for what it's worth: most startups fail, and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier. Often startups simply don't do conventional line management at all, which works until it suddenly doesn't. Often startups don't have multiple distinct technical teams, which makes the whole notion of coordinating roadmaps between them moot.

TL;WR: We could go back and forth on this for a long time. I doubt we'll see eye to eye. But I won't back down on one thing: Ignoring the massive lawsuits and public scandal that "unmanaged" organizations have incurred and how easy it was for them to go wrong is a bad plan. Ignoring the systemic flop that holocracy has turned out to be is a bad plan. Pretending that medium and large software organizations can "run themselves" ignores what organizations with unprecedented success are actually doing, today.

But of course, what says "Sunday Night" like a good fisking?

> I'd say that's the real "just ignore the cycle of failure in the industry and keep writing the same stale think pieces" approach. We've had decades of talking about how vital good management is and how better training for management is a great idea, and to what avail?

Well it wasn't terribly actionable advice before, say, 2008, now was it? The number of people who could get a strong foundational education with industry focus in CS was quite low until the early 2000's, and most folks want at least 5 years experience.

So really, the only supply of technically proficient managers was folks who were unusually talented AND escaped the orbit of organizations that provided quality experience. So like, Apple? Sun maybe. NeXT? Early Intel was boss, and I knew some amazing folks from SGI.

I had a very negative experience of tech managers too, until I met Bruce Horn from Apple. My earlier experiences were a complete train wreck. I met him in 2006.

We've actually seen a really great wave of folks tackling the idea. Folks like Camille Fournier or Dave Smith producing really great material for consumption. I'm grateful to both.

> I was thinking about technically-vertical rather than organizationally-vertical. Cases where the implementation of a single customer-facing feature - the response to a single customer request - is handled by components that are the responsibilities of several different teams with their own management... That's how you'd end up needing to coordinate roadmaps between different teams, and I see that as indicating poor structuring of responsibilities, usually a result of a team taking exclusive control of an area that should be shared, which is usually a management phenomenon.

Pardon me, so you're suggesting you hire folks who can both implement the API and the distributed systems AND build the mobile client apps, and also the website?

That's how you get mediocre outputs.

> It's an appealing thought, but it just doesn't match my experience of how it works out in practice.

That much is clear.

> Or one manager brings a particular API under their control to expand their own importance, and prioritizes their own needs - or worse, deprioritizes work on it because they're not actually using that API for anything important but won't allow others to improve it. Or it emerges that what was initially assumed to be a single common feature actually has use cases that are so different that they should be implemented separately, but any team that proposed to fork off their own variant would be assumed to be empire-building (or, equally and oppositely, would be given insufficient support in their work), so everyone keeps muddling through with an awkward compromise.

I'm not sure if you fully understand the nuance of this conversation though. I'm not objecting to the notion that bad non-technical management exists. Or even that bad technical management has existed. I cannot deny you've experienced this nor am I interested in doing so.

I'm saying: we need to do better. It's important to do better. And it's worth noting that the really amazing companies we see out there that do huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think very highly of) etc? They don't do that holocracy thing or that flat organizational structure. Heck, they've even gone so far is to separate site reliability from product engineering entirely. And most folks who I respect as engineer say this separation is the right call.

Our industry has a history of improvement. Not just in terms of technical accomplishment, but in terms of organizational success. Once even small software projects were complete nightmares, now most things ship and we're used to seeing a slew of somewhat functional software products that are lacking not for features but for product-market fit! Now, a previously unimaginably complex baggage checking system that was a famous failure is actually a 1 semester college product for upper-division software engineering and DAMN if they don't do a credible job of it (even though Kids These Days(tm) still don't learn enough about how SLAs are met in industry).

Engineering management and planning has had a similar curve of improvement.

> (people say that you'll get stuck in a local optimum that fits the first use case but can't possibly be adapted to the second, but I just haven't seen that happen in practice; code that was written for a single use case inherently tends to be simple and malleable)

Aside: I've certainly had that happen! At Level we originally based the system around a primary spending account and secondary asset accounts because the staff and everyone who we interviewed had that configuration. We quickly learned that we had a biased sample and many people have multiple spending accounts. It took a very clever engineer to unkink our system to solve for that problem. Wish I had listened to our advisor, it would have saved us 3 months!

> I don't think good technical architects/technical planners exist - I've just never encountered anyone who was able to produce better results by making technical decisions ahead of time (across a wide variety of management styles and techniques) than leaving them to implementation.

I think you have a curiously warped view of architecture. That it spans quarters or even months into the future. It doesn't. Often times, it's as much about auditing the existing babel of engineer rodeo projects to find out what's closest to meeting the requirements and helping those engineers sketch out how to take it the remaining agonizing 20%.

> and that those that succeed often do so by doing things that don't scale; in any case a startup CTO is rarely doing all the activities you listed earlier.

I know several post-exit CTOs because we hang out and we all have similar stories about doing this. I also know a lot of would-have-beens who said they didn't care about things like hiring and "just wanted to code" or functioned more like VPs of engineering (which are a pure management function).

> Often startups don't have multiple distinct technical teams

Usually it's "teams" of 1. You have the mobile specialist, the API owner (often the CTO), the website specialist. This is a very simple version of the larger exercise, but it's often even more important to keep track of how things are progressing because you have so little tolerance of wasted time.

> Pardon me, so you're suggesting you hire folks who can both implement the API and the distributed systems AND build the mobile client apps, and also the website?

Not necessarily the same individual, but the same team. If a particular product needs an API and a distributed system and a mobile client app and a website, it should be the responsibility of a group of people that has that skillset between them who sit together, have daily standups together, and all of that. I would expect the distributed systems specialist to be willing and able to add a line to the website or vice versa; different team members have different specialities but everyone owns the product and anyone picking up a feature takes responsibility for delivery of that feature. If a feature requires two people's skillsets they can pair on it and collaborate directly; if it requires more than that, find a way to break it down into smaller features that can be implemented individually but will still constitute customer-facing product features. (This is something people often assume will be impossible, but it almost always turns out to be easy once you try, IME).

If there's a function that's sufficiently universal and valuable that you want to share it (e.g. server administration), you have to stop doing deep integration across that feature boundary and pare it down to a more product-like interface (e.g. your server administrators offer a way for your application deployment to specify which libraries it depends on, rather than managing directly which libraries are installed on which server) where a product-like roadmap is sufficient. If there's a one-off feature that requires deep integration with another team, that feature should be done by a pair with one individual from each team, who can coordinate directly with each other.

> I'm saying: we need to do better. It's important to do better. And it's worth noting that the really amazing companies we see out there that do huge, good work? Netflix, Google, Mozilla, even Amazon (who I don't think very highly of) etc? They don't do that holocracy thing or that flat organizational structure. Heck, they've even gone so far is to separate site reliability from product engineering entirely. And most folks who I respect as engineer say this separation is the right call.

I don't see the giants as the ones doing the amazing work - their big innovations happened when they were smaller - and within the class of giants I would loosely guess that the more effective ones follow a lower-management, more-segregated-teams style. (FWIW I think Facebook - conspicuously absent from your list - have been more effective among the giants, both in terms of making a better product and in terms of producing high-quality technical libraries). But we're getting beyond the level where I can really have an informed opinion; I haven't worked for enough large companies to have a statistically valid sample, and while in the absence of proper studies I'm inclined to trust to my own experience, I could've just been lucky at the less-heavily managed ones and unlucky at the more-heavily managed ones.

> I think you have a curiously warped view of architecture. That it spans quarters or even months into the future. It doesn't. Often times, it's as much about auditing the existing babel of engineer rodeo projects to find out what's closest to meeting the requirements and helping those engineers sketch out how to take it the remaining agonizing 20%.

My view is based on what I've seen people in "architect" positions do; I'd certainly say there's a lot of variation in what it means between different companies, but it's always been some form of making technical decisions earlier than during coding (even if just at the start of the week after scoping out a particular feature) and as such I've always found it counterproductive.

Pair-programming with a developer on the same team who knows the codebase well can be extremely positive if that's what you meant, and I suppose you could consider that person an "architect". But I find it's vital that that person not be any kind of formal manager: the easiest way for it to go wrong is when the junior partner gets intimidated and stops contributing.

All I can say is: good luck with GDPR compliance, my dude.

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

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

> "Yes, it's just an API change, but it requires 50 new test cases and impacts 120 existing test cases",

"See, that's exactly why we shouldn't write any/so many tests!" - A product owner I know...

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.

"Manual QA then? That will be even slower than automated..."

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.

> Sometimes we engineers do a poor job of communicating complexity: we have un-communicated assumptions that we think the listening party shares.

IMO, a manager should understand the complexity of the work of his employee at an approx. ball park level.

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.

Yeah, it's supposed to be a role for a dev to play for 10 minutes a day.

Unfortunately I've seen people with it as a job title. They were the absolute joke you'd expect.

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?

While I agree that it helps for a manager to have experience doing what they are managing, I would frame it differently. I've experienced poor engineering managers with engineering experience and good engineering managers with none, to the point that I've developed a more nuanced opinion about what makes a good (engineering) manager.

Great managers can manage things they don't understand and probably never will -- their role does not require domain expertise. I would argue that the hallmark of a poor manager is that they can't manage unless they are a domain expert, which they often use as a crutch to overcome lack of basic management skill. One of the greatest failure modes for software engineering managers with engineering backgrounds is the assumption that they can or will understand every part of the design they are managing. Not only is this unlikely in many cases but this delusion encourages them to dictate elements of engineering design that they are not intimately familiar with, invariably to the annoyance of the engineers that are tasked with doing the work and may have far more technical skill than the manager on the task at hand. For mundane software projects, an engineering manager with an engineering background may legitimately have the domain expertise, which is why it still gets things done despite being suboptimal for everyone.

This is really brought to light when doing complex, high-end software system engineering. In these cases my experience is that most experienced engineering managers with engineering backgrounds fail; because it is impossible to understand what your team does at a technical level, you can't lean on that. It is often difficult for very experienced engineers, now managers, to come to terms with the idea that someone working on "their" project has technical skills that they can't master or at least understand with a 15 minute explanation and a couple hours of research. Engineering managers, especially ones that were previously great engineers, must resist the instinct to technically master everything under their purview -- it doesn't scale. The advantage of non-engineering managers in these environments is that their management style doesn't rely on the assumption that they can technically master any part of the project, so they don't even try.

A big part of being a good engineering manager is letting go of what made you a great engineer. It isn't an easy thing to do.

It's just management, after all.

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.

I was recently a lead developer and asked to manage the team by the team. I noticed running the team can't be generalized in one size fits all, some people just want clear descriptions of projects to work and and some people want to over engineer and make a 1 day thing a 2 month job no matter how you say it should be done. Problem is how do you handle a engineer that says something can't be done in 2 hours? Well so far I have sat down with them and showed them it can be done in 2 hours, beyond that argue with me enough and I may be forced to rethink your employment. It hasn't come to that yet. most of the room follows my instructions and we are kicking butt, there's a small part of the room that wants to be dramatic about everything, their computer isn't good enough "needs 64 gigs of ram for their command line", the tools aren't good enough etc etc - basically they have management envy and that's my only struggle right now.

Not particularly directed at you, but it's certainly a dichotomy in that managers are the only ones responsible for "rethinking another's employment". I'm curious to know how often you would consider reflecting on / rethinking your own employment?

I say this because I was recently hired to work on a project where managers are obviously the only ones responsible for deciding how a developer should function within the organization. It is obvious the state of the project is anything but healthy at the moment. Attrition rates are astronomical and the code is beyond ugly in a lot of cases.

"rethinking employment" was a clever way of "firing someone who cannot take direction".

If you're suggesting a manager sometimes needs to self-reflect, sure, but a good manager does eventually have to make the call that someone isn't up to snuff.

There are several people in my department who probably should be "rethought" or let go, but management is too soft to make the call. It's actually more harmful to several, who could easily move on to other roles.

>most of the room follows my instructions

Be aware that this works only because you were technical lead of the project and recently active in a hands on capacity. It will likely fail you once you are on a new project that you don't know technically and your skills are years out of date. So learn to find, trust and nurture the experts on your team instead.

We're no google but I have lead the software department on techical decisions and scaling for the past 3 years as the company/startup tripled in growth. We are a tiny power rangers sized team, I probably just have angst in my comment as there is one particular employee who was recently hired before me stepping on that goes left when I "and everyone else on the team" says go right.

You sound more like someone who let a modicum of authority go to his head and projects a lot than a good manager, here. It might work now because you're directly familiar with the inner workings of this project, but you can't expect that in general.

To be honest im a passive aggressive push over, I believe in jumping in, failing early and finishing early, I asked if i could have my job back of just throwing head phones on and working but the ceo says EVERYONE is happy with me and he likes the processes im putting in place unfortunately I spend my weekday drives thinking about how to deal with a certain someone on my team who wants to act like he is ALSO manager and thats sort of why this article/blog triggered me.

Honestly you sound like you want to be dramatic about everything.

A certain quote or just trolling by?

This is a much longer story than I jotted down on my phone as a comment, also a tiny mutli million dollar startup but after the mostly negative comments I recieved on this post I'm starting to think there is easily a phsycological US vs THEM mentality between devs and management. I miss being able to complain, I still did the work but there was something magical about us banning together to complain about horrible management & lack of leadership. If you're going to fuss about a comment about firing and if you havent noticed some weak links at your other jobs then most likely youve been the weak link and to be fair thats fine when your job or title fits you appropriately but im talking about someone making double or triple the guy busting his butt, i was the busting his butt guy and im looking out for the rest of those guys. Theres one of many reasons I didn't go into a software job for the government.

A lead developer is certainly not a manager and is in no position to rethink someone's employment. A lead developer can lead and guide, and generally make technical decisions, but must do so with humility and respect. I've been a lead developer and have never used my "authority" to dictate what people do, but that's just my style.

Whatever your job title might be if you are the eyes and ears that generate feedback for the CEO and other management teams what are your ways of leading and guiding a lazy employee? Software developers or not it seems like as soon as everyone gets a degree they forget that we can still have toxic people in our field that slip through the hiring process and just bring everyones day down. When I say I would let someone go I mean I would suggest it and only after many attempts of me and the rest of the team trying to get through to them which seems pretty standard to me. I'd rather not work in a corporate place where I'm forced to work under or over negative people without options. Though I'm sure I come off as a typical grumpy jerk online I have to deal with being a passive aggressive person at work and I have noticed that has led to a employee or two attempting to take advantage of my hospitality and I end up working crazy hours to get things done for releases because I'm not the type of person to demand you stay late or work weekends. Everyone under me has a laid back job, I would also have a laid back job if I swapped one bad egg with a good egg or rebranded his position. I feel bad for the guys destroying work left and right while this other employee wants a red carpet laid at his feet every week to write a line of code. Maybe the 10x programmer doesn't exist but people who read about silicon valley and think free cupcakes and energy drinks should be everywhere certainly do.

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.

So what's the benefit?

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.

You owe the "just" jar $2.

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.

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.

YMMV

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.

Agree!

This guy has clearly been bitten by one type of bad manager. But let me assure you, there are many other types, and they often come from engineering backgrounds. You'll get all matter of micromanagement and communication issues that come from someone who is used to knowing all the intimate nuance of every issue. Also, even if you think they are a great manager because you have a great individual rapport, they may end up getting steam-rolled from above because they are bad at cross-functional communication or managing up, and guess who pays the price for that?

The fact of the matter is that management is its own skill, very contextual and difficult to master, and engineering experience is no silver bullet. Of all the best engineering managers I've worked with (both up, down, and lateral), only half had an engineering background. It depends on the project of course, but in general there are more important attributes than hard tech skills.

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.

This is just a rant.

The author apologizes for speaking in unqualified absolutes, but does so constantly.

Even if the author is right, this article reads as pretty childish.

There’s a balance. A group run by clueless managers is bad. Equally through a group run entirely by engineers that don’t think about or consider anything other than their engineering concerns is bad too.

A good manager knows how to find the balance between “what engineering wants” and “what everyone else wants” and gets the best outcome. The best managers don’t need to be expert engineers themselves but they know enough to have a good BS detector and enough to make decent decisions.

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.

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.

This spot on. I would take a manager who knows how to get best tech decisions out of their engineers.

My experience agrees although proper management training/mentoring can alleviate some of the issues.

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.

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

But you still have people doing the job of a manager.

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.

Sure, that work still has to be done. But if you start off by thinking of it as "the job of a manager" then you're assuming your conclusion.

> Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.

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.

So you’ve worked on successful teams without managers—they just had... managers, managers, managers, and architects?

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.

>Once you’re coordinating groups of people you need a manager to keep them working together towards a common goal.

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.

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.

Communicating complexity difficult.

I recognize the feeling when tasked with bringing a new developer up-to-speed. They don’t know anything about our environment and the brilliant decisions that led us to our utopian way of working. They ask an honest question and I, having forgotten the ingredients, brush off the question because I don’t have time to explain. Welcome to the team noob.

I also recognize the challenge when speaking with practically every CEO, COO, EVP, VP, and Director in a mid-sized organization. And the challenge can grow exponentially when the business involved views technology as an expense. Somewhere in the building there are a number of idiots who think a pointer is a device used for whiteboard presentations. How is this company profitable?

But solace comes when I realize the issue is my own.

Technical expertise is not the only expertise required by a company. It is highly likely that your organization has executives that don’t need to understand the productivity differences between vim and emacs. Imagine how frustrating it would be when attempting to ensure the company has enough funding for the next four quarters and you can’t get a single developer in the world to provide a reasonable estimate that doesn’t have a sixty-percent margin of error. I dare you to argue the benefits of a scrum master.

Your manager is just as anxious about having to talk to you. Give them a break and help them do their job. They’ll appreciate it and may care to understand your concerns moving forward. Who knows, they may be willing to help you do your job better (as if that's possible). Communication will be less frustrating when you stop viewing others as inferior. They feel the hostility.

The most successful amongst us are those that communicate by simplifying complex subjects down to an intelligible analogy. They sell. The world rewards those who sell. Just find another way sell your complexity, patiently, and with a touch of empathy. The rewards will follow.

I worked for a lot of different managers in my career, both good and bad. At one point I was team lead, but didn't like it too much.

It always comes down to this (in technology): A good manager serves his team, a bad manager thinks his team serves him.

A good manager realises that his team members know more about the tech than he does (even if he is technical). To get estimates, he asks the people who know.

A good manager makes sure each team member can stay focussed on their job.

I didn't like being team lead too much, because I don't like administration, and I don't like to handle shit that you don't want to distract your team. At the end of the day, I was always happy when I could write code. Therefore I leave the 'shit' job for someone who likes it, but I'm glad some people prefer the other.

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.

This is my perspective as an engineer.

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.

Author seems to lose the distinction between project managers and engineering managers. The tricky thing is that some engineering managers do perform project management functions, but that will make for one overworked manager. In mainstream FAANG-type companies what you will see is:

Project management - manage scheduling, deadlines, track progress, day-to-day or low-level interteam collaboration, resolve blocking issues. They'll usually use a bug tracking system and ensure that it's state reflects reality. They may also need to build out or modify various processes such as new releases or deployments, work with QA on a validation process, or when should code be considered good-to-merge into the repo. (Has there been code review done, CI testing, validation, etc).

Engineering management - HR functions (promotion, performance management), assignment of tasks or larger projects, working with project management on realistic schedule, working with product / business on requirements, interfacing with other teams on high-level matters, strategic work related to the team, and most importantly work that no one ever wants to or has any time to do. (This includes technical work.)

IMO you can have a small org without these two functions if everyone is a has extensive experience/willingness to managing themselves, but if it grows past that things will break very quickly. Modern large organizations deal with unfathomable levels of non-technical complexity.

Example? I’ve experienced too many instances of just-justification, where a manager has said something like, “it’s just JSON”, or “it’s just UI”, or “it’s just talking to the backend”. This not only unravels their credibility in knowing anything about software, but it also devalues the work that a software developer needs to do to build a working product.

Well, I've had engineer colleagues use that kind of language at me. It's a type of bullying really, and it doesn't necessarily correlate with technical cluelessness.

Didn't Google try this? It didn't work out for them.

https://www.forbes.com/sites/meghancasserly/2013/07/17/googl...

https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...

>But where they single handedly derail a project due to micro-managing and over simplifying developers’ implementation concerns.

All my managers have been engineers in the past. And over half of them fit this description.

I don't want to downplay the benefit of having some domain knowledge, but the problems described are not a symptom of not having engineering experience. Management requires a good amount of nontechnical skills, and too often a high performing engineer is picked for becoming a manager, with no training whatsoever.

This might be interesting in this context: https://rework.withgoogle.com/guides/managers-identify-what-...

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

On a related note, I just quit one of my contracts, but in this case a fellow developer was asked to become a SCRUM master a few months ago. The word "master" must have gotten to her head because that's what she thought she was. It turned into a micromanaging nightmare and she started trying to track my whereabouts and hours, even going so far as to tell me who I can and cannot talk to, as if she were a manager (but not even our CEO would treat me like that). I finally had to tell her she wasn't my manager and that we're equals. Well she didn't like that and told me "I'm the SCRUM master!" and that I don't understand the agile process. I had even talked to my actual manager about this the week before, who confirmed that yes, a SCRUM master is nobody's manager and cannot tell anyone one what to do. Things came to a head and now I'm outta there and all their objectives will now go red, all because someone who had some perceived power thought that they could skip years of training, experience, and wisdom, and go straight to "manager" (and a bad one at that).

I think we can all agree that bad managers suck and managers who pretend to be technical particularly suck. However it feels the me though like we greatly underestimate the difficulty of being a technical manager and grievously under train them. Google has gone past the one-off personal experiences and studied across lots of teams and projects[1] and being a technical expert wasn't even close to the most important trait. I'd like to see us spend less time proposing "no managers" as current ones aren't good and more time on figuring out how to make them good and give them training and support they need. Most of the ones I know want to be successful and are trying in their own imperfect way. If you think the most important thing is technical prowess just take a look at any academic CS department, run only by super technical professors it is often a case study in anti-patterns.

From Google's study on managers reported in nytimes[2]

  “In the Google context, we’d always believed that to be a   manager, 
  particularly on the engineering side, you need to be as deep or deeper 
  a technical expert than the people who work for you,” Mr. Bock says. 
  “It turns out that that’s absolutely the least important thing. 
  It’s important, but pales in comparison. Much more important is just making 
  that connection and being accessible.”

[1] https://rework.withgoogle.com/subjects/managers/

[2] http://www.nytimes.com/2011/03/13/business/13hire.html?smid=...

edit for formatting

Gets me thinking of one episode of the original Connections series.

There Burke talked about automation (keep in mind this was recorded back in 1978), and how it would make management simply sit around waiting while the mainframe in the basement churned out the action plan for the next week (or some such) and then implement it.

Effectively he envisioned that computation could eliminate the managerial class.

I think there is a slight correlation between having some expertise in the team that you're managing and your overall performance as the manager. Some points along this argument include empathy for engineers' work, and I totally agree with you.

However, and especially at scale, there is a humanistic factor in management that having technical background alone can't fix. How do you manage deadlines? How do you deal with engineers who over-engineer a feature and go down that deep technical rabbit hole, with no "done date" in sight? How do you deal with people having to take a sabbatical but having an important project deadline around the corner? Heck, I'd argue engineers like myself are pretty bad at this and still constantly learning. Don't forget that expectation vs reality distortion is real. Great managers are essentially brokers to keep expectation and reality in check.

I'm thinking about starting a tech cooperative where the members work on startup ideas [1]. Every member will have complete control to work on whatever they want, and there will be no managers or deadlines. I want to work with people who have enough motivation to fix broken tests and bugs by themselves. It's much easier when it's your own product.

This might not be the most effective way to run a company, but the members will all be self-sufficient, and we'll support ourselves with part-time contract work. Or some might have a full-time job and work on side-projects in their spare time. Eventually we might make enough money to pay for our living expenses.

The projects could be anything, and at the beginning we would focus on revenue. SaaS services, mobile apps, games, open source projects with some paid features (e.g. Sidekiq), or buying some websites from flippa.com.

Once we start making a bit of money, we can shift focus to non-profit work, and fun projects that are purely creative. I have a big list of things that I'd love to work on, and some of them are just fun ideas that won't make any money. But who knows, maybe those experiences will shine light on some new product ideas.

I want to find people who love learning and building things in their spare time. And I want to start a company where all the time is spare time. That's not to say that spare time is always fun. Responsible people use their spare time to do chores and fix stuff around the house. You wouldn't want to live with a roommate who always leaves dishes in the sink and leaves their clothes all over the floor. I want to work with independent people who don't need that kind of management, and build a lot of interesting things together.

[1] https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4...

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.

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.

[1] https://ia801903.us.archive.org/19/items/mythicalmanmonth00f...

[2] http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...

If there is one thing I learned it’s that “no managers” === “everyone is responsible”. That ends up as “no one is responsible”. Then chaos ensues due to no clear decision making and infighting because everyone is suddenly “boss”. As always YMMV.

This is indeed an important discussion. I was looking for some similar experience in the top few comments but couldn't find it, so I thought about writing my own. From my experience its about the person in the role, not the role itself. Two of the best managers I had were non-technical but they could read people. They kept their distance from the technical work but would step in when required to control. Ofcourse this also means that they hired good engineers to begin with. A good engineering team can run by itself when it comes to technical work.

No. Just no. I have been there to clean up the mess that results from this methodology.

A certain recipe for disaster in any development project is having no one who thoroughly understands the business and no one who can make a decision as to what gets developed and what does not. What this article is describing is just such a recipe.

Any significant development project which is attempting to address the needs of the enterprise needs an enterprise architect, and a project owner who can say no. If these can be the same person, all the better.

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.

The author’s example provide the counterpoint and the way forward with a non-technical manager.

In fact sports and arts organizations have non-technical “managers”. In theater and film, they are called producers.

If a non-technical manager keeps to the “producing” stuff, that is, HR, resource acquisition, inter-company communication, I’ve seen it go well.

As soon as the non-technical manager starts making “creative”, ie technical, decisions, that’s when things go poorly.

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?

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.

How about no managers with no management experience. I've seen countless senior devs promoted to eng/dev management roles who were either clearly not ready for the role or were simply not the personality to "lead".

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 have been saying this for years, but most consulting companies insist on managers who have no clue what they are talking about.

This also reminds me of MBA CEOs that delegate everything, and that also reminds me of Jack Dorsey that is CEO of two companies.

Or just have managers with engineering experience. Just saying. Cause it seems pretty straightforward to me.

Obligatory xkcd: https://xkcd.com/1425/

Also, I feel like this (we don't need no stinking managers!) is a perennial meme that pretty much doesn't work in practice? Queue the Valve Employee Handbook: http://www.valvesoftware.com/company/Valve_Handbook_LowRes.p...

Some more articles:

- Valve https://www.inc.com/david-burkus/how-this-company-runs-witho...

- Zappos https://qz.com/161210/zappos-is-going-holacratic-no-job-titl...

- https://www.fastcompany.com/3045509/myths-of-companies-with-...

- ? https://www.fastcompany.com/3045509/myths-of-companies-with-...

PS: From my own experience, managers are invaluable at removing distractions, communicating with stakeholders, setting high level priorities, and assisting with career growth. But it's not hard to see the place of frustration where OP's point of view comes from.

The article's argument is founded on the idea that non-engineers should not manage engineers. Since this idea reduces to nonsense at the limit, it seems worth being skeptical about it throughout its domain.

Limit: CEO -- it is not possible and no one would seriously suggest that a CEO must be expert in all disciplines they manage. Therefore at some extreme we must admit that functions can be managed by non-experts.

Taken a step down, does the most engineering leader reporting to the CEO need to have been a practicing engineer? If we examine this carefully, this is also a kind of nonsense. Such a person is usually managing a wide array of engineers working across multiple disciplines. We cannot expect them to be an expert in all areas that they manage, given that these will likely include some element of infrastructure, quality, security, performance, front-end, back-end, mobile, and potentially other disciplines. Even if you had a mobile-only team, it's not likely to find a leader who is an expert in both iOS and Android.

Ok, let's go down another level, to a director that manages a given domain of engineering, for instance an iOS engineering team. First of all, at scale most companies I've worked with do not even organize in this way -- they find it most efficient to build high-functioning teams that have most if not all of the disciplines needed to ship product in a given business problem domain. Since this is simply a repeat of the above issue, I won't cover it again, in favor of focusing on the specific issue of someone managing a discipline that isn't matrixed out like this, perhaps a backend infrastructure team. In a reasonably-sized team (50+ engineers), such a person has no time to be actively involved in the development process, and likely has not had time for this in several years at a minimum. Even if they do maintain side projects that use the technologies of the team their efforts are at best dabbling and cannot be compared to someone who is full-time engaged with those technologies. I would not trust such a person to make a reasonable estimate for degree of effort when it comes to any given specific project -- they are simply too far from the current state of the codebase and technology, despite their having been an implementor in the past.

Now we get down to the case of a manager of a team. If they competently manage more than 6-8 or so people they likely have no time free to be actively involved in development and effectively are in the same situation as a director, hopefully with more recent context. If they actively involved in development, then they are probably operating in a role that is best described as "tech-lead / manager". I would trust and expect someone in a role like this to be able to judge level of effort for work their team is doing provided they are actively working in that discipline (cross-discipline teams as described above will include a solid percentage of work that they are likely not expert in).

Hopefully it goes without saying that this is a minority of engineering managers, even correcting for the tree-like structure of most engineering teams.

Finally, as other commenters have pointed out, managers are required to spend a great deal of time (often 100%) in meetings and dealing with personnel issues. These require skills that are not specific to engineering, and as managers grow in their career, they will get stronger in these areas (and weaker in terms of their ability to engage directly with the work that "line" engineers do).

You should work with the grain of a manager's natural skillset trajectory, not against it.

Reply on news.ycombinator.com