
Let’s have no managers, instead of managers with no engineering experience - fitpolar
https://medium.com/@posttweetism/lets-have-no-managers-instead-of-managers-with-no-engineering-experience-e8b7cd29d398
======
dlandis
> 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.

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

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

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

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

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

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

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

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

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

~~~
Brajeshwar
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'.

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

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

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

~~~
lmm
> 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](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.

~~~
KirinDave
_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.

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

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

------
hliyan
Sometimes we engineers do a poor job of communicating complexity: we have un-
communicated assumptions that we think the listening party shares. Which
sometimes lead to this:

 _" You could prepend the words “it’s just” to anything, it’s not going to
change the fact that you sound completely ignorant and will ignore any
challenges that your team communicates to you."_

I have often found it effective to counter "just-justifications" with the
right representation of complexity. E.g.

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

OR

"Yes, it's just a library change, but there are 450 sites in our code that use
the library and out of those, 50 involve financial calculations"

Almost always, the manager appreciates this because you would have brought to
his attention a problem that would otherwise gone under his radar.

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

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

------
y2hhcmxlcw
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?

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

~~~
y2hhcmxlcw
> 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?

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

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

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

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

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

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

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

~~~
the-pigeon
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?

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

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

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

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

~~~
aviolette
Agree!

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

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

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

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

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

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

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

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

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

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

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

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

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

~~~
TomMarius
That's not true in general, I've been in environments where a team of 10+ very
motivated individuals worked together without a manager. It's not common
though.

~~~
the-pigeon
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.

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

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

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

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

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

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

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

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

[https://www.forbes.com/sites/meghancasserly/2013/07/17/googl...](https://www.forbes.com/sites/meghancasserly/2013/07/17/google-
management-is-evil-harvard-study-startups/)

[https://hbr.org/2013/12/how-google-sold-its-engineers-on-
man...](https://hbr.org/2013/12/how-google-sold-its-engineers-on-management)

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

------
mburger
This might be interesting in this context:
[https://rework.withgoogle.com/guides/managers-identify-
what-...](https://rework.withgoogle.com/guides/managers-identify-what-makes-a-
great-manager/steps/learn-about-googles-manager-research/)

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

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

------
chuckcode
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/](https://rework.withgoogle.com/subjects/managers/)

[2]
[http://www.nytimes.com/2011/03/13/business/13hire.html?smid=...](http://www.nytimes.com/2011/03/13/business/13hire.html?smid=pl-
share)

edit for formatting

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

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

------
nathan_f77
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...](https://docs.google.com/forms/d/e/1FAIpQLScfFzyzCWPresTMPSb4c13oUbcAZfeyit7muj5cCMvMu56Z2g/viewform)

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

------
quadcore
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...](https://ia801903.us.archive.org/19/items/mythicalmanmonth00fred/mythicalmanmonth00fred.pdf#page=41)

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

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

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

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

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

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

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

~~~
andrewjl
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?

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

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

------
plinkplonk
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)

------
pankajdoharey
I have been saying this for years, but most consulting companies insist on
managers who have no clue what they are talking about.

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

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

------
smnscu
Obligatory xkcd: [https://xkcd.com/1425/](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...](http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf)

Some more articles:

\- Valve [https://www.inc.com/david-burkus/how-this-company-runs-
witho...](https://www.inc.com/david-burkus/how-this-company-runs-without-
managers.html)

\- Zappos [https://qz.com/161210/zappos-is-going-holacratic-no-job-
titl...](https://qz.com/161210/zappos-is-going-holacratic-no-job-titles-no-
managers-no-hierarchy/)

\- [https://www.fastcompany.com/3045509/myths-of-companies-
with-...](https://www.fastcompany.com/3045509/myths-of-companies-with-no-
management)

\- ? [https://www.fastcompany.com/3045509/myths-of-companies-
with-...](https://www.fastcompany.com/3045509/myths-of-companies-with-no-
management)

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.

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

