Why? They need to understand enough software at a high level to be able to manage, instead of turning lower-level details into management problems.

But, they also need to find software development frustrating enough that they are happy to not have to do it every day.

Best managers I met had almost nil technical knowledge or if they did they were not advertising it very much. They were gardeners. They made sure you were occupied, you provided value, you did what you liked and all projects that needed staff were allocated staff. They will meet with you every week for mandatory half an hour 1:1 chat to make sure everything is heading in the right direction and have general sense of how happy you are and how happy others are about you. If the manager thinks you are doing well that's about how much supervision you are getting.

I like this style A LOT.

Or perhaps PMing (which in many scenarios can lead to better pay, and less prone to ageism, though arguably even more stressful than being a manager)

I’m mulling these potential paths myself, to climb the pay scale and fend off ageism.

My sampling space isn't large enough, but it's interesting to keep an eye on the personalities of the managers in your organization from that perspective.

I mean that only half jokingly. One of the reasons I like to work at smaller organizations these days is the pervasive belief in larger orgs that somebody has to fall into one of two categories. This is often rationalized as a way to identify strengths, however more often than not IMHO it's due to insecurity in ones own deficits.

In reality, you can be good at both and like both and switch between them. You might have a preference and still be reasonably good at both. You might decide one is weakness and put effort into learning it overcoming initial dislike.

Was this not the case before? What were EMs doing then? This is the only definition of EM that I've ever known.

In other words, the engineers would not notice if the engineering manager was not there (except they’d spend less time in meetings and reporting). And the company wouldn’t notice either — unless the engineers chose to use that extra time productively without being “managed” to.

Meetings like weekly 1:1s are supposed to be helpful for you as the engineer. They're a safe space for you to complain, and share what sucks about your job, and brag about what's going well. It's like work therapy, but a lot of the things that you complain about can actually become things your manager can fix over time.

Things like help in goal setting might not seem strictly necessary if you're self-driven enough. But doing good work doesn't help your career if nobody notices, and spending your time focused on Doing The Thing is time you're not spending playing a game of politics to make sure upper management is hearing your name all the time. Having a manager to establish a paper trail of what you claim your goals are, and then doing them, makes it easier for everybody above you in the organization to justify giving you a raise/promotion/etc.

I agree that, in a lot of situations, poorly-trained managers do more harm than good. But I promise it's theoretically possible for good managers to provide value!

Not trying to be a jerk here, but they're not meant to be a place just for employee to vent. They want the manager to do something about the problems. This is usually frustrating for both people, as the manager is often not empowered to fix the problem (such senior execs not having their shit together, other teams fighting, and all that usual fun stuff) and the employee gets tired of essentially asking every week for things to change, with no improvement.

Now, I would commend a manager teaching an employee to not see management as an enlightened therapist/advocate/accountability partner, but rather as just another kind of specialist in the organization with certain powers and access channels. Sadly, that seems unlikely in the age of Rands, Ask a Manager, etc.

The Technical EM is more about design, architecture and progress, and sometimes helping the team to get code out the door.

The Non Technical EM is more about this. The technical EM would communicate through a PR, say instead of having 1-on-1's.

Edit: They said in the article they used to give coding problems to engineering manager candidates, and then in the onsite interview, they found their managing ability is so far off of what they were expecting.

So they're making a shift from a Technical Managers to Non Technical Managers.

The managers I respected were all TLs who were the most important engineer on the project.

Going back to your point, the TL would be the best person to evaluate the engineers who work under them. 1:1s, growth discussions, etc should all be conducted with someone who knows your work intimately, which means the TL. Which means the TL is a manager.

There's still room for EMs to be more technical or more people/coordination-oriented. A technical EM would take responsibility for a smaller area (backend) and go deep technically into it, having the most impact as an individual contributor, knowing all the code, being able to debug any part of the system, being the go to person for everything in that area. Everyone in the backend would report to him.

An EM can also decide to be focused more on people/coordination. They'd take responsibility for a bigger area (backend, frontend, iOS and Android) and go wide rather than deep. If you ask them how to debug an iOS app that crashes in the background, they may not be the best person for that.

But in both cases, they're managers, not TLs.

It's nice that they are keeping this in mind. I was a technical lead for a new product in the company at my last job and had a new engineering manager hired over me. I ultimately quit because he wouldn't let me do my job, insisting on making every technical decision, and that he knew better. Many of them were poor decisions. He was a mid-level engineer with a big ego in a manager's position, and was given the power to do whatever he wanted.

I've been working professionally as a software engineer for almost 10 years now. By far the worst experience I've ever had.

Making sure that an engineering manager knows their limitations is very important.

If the manager ever feels they simply must over-rule a team lead, it is probably better to replace the lead than to impose a dictat as it indicates a problem working with that person.

When you start to hear the team discussing options and they raise all the concerns that you would have yourself without you saying anything you know they've heard you and are modeling your thinking. That puts the team miles ahead.

manager is ultimately responsible for his team decisions (of course bad managers do try to scapegoat that responsibility down onto the team when the stuff hits the fan) and being responsible for the decisions can't be separated from making those decisions.

the manager cannot override that.

unless of course, the manager is actually the boss. which invalidates the tech ladder, really.

don't confuse technical decisions (as GP stated) with management or product decisions. managers are not ultimately responsible for technical decisions in this model.

it will be equal only when the people on the technical ladder start to take hiring and firing decisions. Until that - the "parallel" ladder is just a pipe dream and the manager is the boss.

generally, employees fire themselves ...

But I mean, you're not wrong. In the environment you're thinking of, the "tech ladder" is a farce. Which is why the parent, as he said, left that company.

CircleCI has made the claim that they have a true tech ladder, and there's no reason to disbelieve them.

Disagree. This is the essence of delegation. You trust the person or team to decide the best path forward.

Do you think Tim Cook is responsible for the sum of decisions at Apple (yes)? Do you think he makes all the decisions(no)?

Good managers trust the team. If they don't, they'll repeat the team's work and ruin team morale and burn themselves out.

I've heard in the military officers that served in the enlisted ranks before commissioning are more effective and supported by their troops than those that come straight out of OCS; but this is just anecdotal. If it is true, I think engr/mgmt relationships operate quite the same way. https://en.wikipedia.org/wiki/Mustang_(military_officer)

While I agree that it's best to have an expert in the field managing you, from my time as a manager I believe the "soft skills" of communication, emotional intelligence, empathy, organization, etc. are much more important. The reason it's so hard to find great engineering managers is that it's difficult to find a "programmer's mind" and a "people-person mind" in the same person.

For one, I think it is extremely difficult to be a manager if you are an introvert. A huge part of your day as a manager is meeting and conversing with other people. If those interactions all take energy from you instead of give energy, it's going to be hugely draining to deal with that much interaction all day. At least that was what it was like for me, so I could just be projecting my experience onto others.

I am an introvert, and dealing with people (as a manager) was mostly neutral, not really draining or energizing. That part wasn't a big deal and I enjoyed it enough. The draining part is when you have to make tough calls, when you have to tell people things they don't want to hear, or when you have to handle HR issues. That part is draining, but I'm pretty sure extroverted managers find that draining too.

I don't doubt that extroversion helps, but I certainly don't think introversion is an actual stopper.

I still entertain the idea of getting back into management, but I'll have to figure out how to offset that drain, or even gain energy from personal interactions, as you said, in order to sustain it for more than a few months/years.

My experience was basically exactly the same as subpixelated.

Just to point out even for extroverts a difficult conversation is still draining. The regular conversations should at least be neutral though.

100% true. The difference is night and day.

Both with their own self confidence to lead a group of enlisted and specifically senior enlisted who in my unit, almost always would have had more front line combat experience than the officers, which meant knowing when to overrule and when to defer to their judgement.

And simply the day to day small and large decisions/choices both during training & deployment were always more informed when backed up with prior enlisted experience.

- Units send their best enlisted folks to become officers.

- For entry officer jobs like a platoon leader, the prior enlisted will have a massive knowledge advantage. Once an officer hits company command (~5-6 years), I'd say the difference evaporates as the focus should be at a higher level.

Some of the downsides of prior-enlisted officers are:

- Leaning to much on their experience and micromanaging enlisted subordinates.

- Focusing on low-level details rather than "officer-business" like long term training plans and orders preparation.

This is a solid truth. Officers who were enlisted are more well liked by their subordinates. This is not just because they've been in enlisted shoes before. Officers who were prior enlisted are often older and much more mature than fresh faced LT's straight out of college.

full disclosure: i am senior dev and a bad manager

"In the four decades I've spent in the software business, I've learned that there are three fundamental abilities needed to do a quality job of managing software engineering:

* "the ability to understand complex situations so you can plan a project and then observe and act in order to keep the project going according to plan, or modify the plan;

* "the ability to observe what's happening and to understand the significance of our observations in terms of effective adaptive actions;

* "the ability to act appropriately in difficult interpersonal situations, even though you may be confused, or angry, or so afraid that you want to run away and hide."

Though I have all four volumes of QSM, I lifted the quote from here: http://wiki.c2.com/?QualitySoftwareManagement

This person is promoted, not hired from the outside, and then proceeds to stop coding entirely and focus on his direct reports well being, the well being of the team, and keeping everyone unblocked.

Otherwise, they just get out of the way and let the team do its thing.

Are you saying the next best thing to an involved manager is one that's not involved at all?

One of the companies I worked at hired a manager for a different team, and then somehow my team got stuck with the new manager. I don't feel like they were a great fit for our team, our people, and our way of doing things, despite how the other team thought the person would be great. People on the team started jumping ship and transferring to other teams, and I think it basically destroyed the couple of years of work we had put into building that new team. If you're hiring a manager for an existing team, I think it's important to have the direct reports really involved in the hiring process. It not only gives a sense of agency and involvement that helps bring a new person on above you, but also checks the culture fit of the people being managed (on both sides).

If managing is a people skills game, as this article seems to conclude, then it inevitably has to be about the people being managed. For example, is it a team of younger devs who need more mentoring and building up of skills? Or is it a more senior team who needs someone to push for them in the org and stay out of their way technically? These are two completely different managers in my book, and not because they are of two different levels of skill necessarily. While one person could probably do either, I think more realistically a manager is probably more on one side or the other.

There's one "goal setting" exercise I would want you "non-technical EMs" to do - and that's to allow people an opportunity to prove themselves, to build trust, so that they can get access to more parts of the stack and contribute as best they can to the company. That does not mean working at partial capacity within a pigeon hole you know nothing about but have been assigned to create for me anyway.

Trust can be tough to build, but there's no substitute for going through a real exercise of proving yourself "in the field". All of the 1-1s, goal setting, OKRs, and whatever, are unnecessary when all of those things can be determined from a display of dedication through actual, real work. All it takes is an opportunity to show what you're all about.

I maintain that it is very unlikely that you understand what this opportunity means to a developer if you are non-technical.

Disappointing to see this from CircleCI.

The problem i have seen with most non-technical managers is that they tend to crave for recognition from the tech people they manage and somehow think they can prove their worth by micro managing.

Better to have a technical manager who has better people management skills.

For example

> As our take on this organizational model evolved to align with our needs as a distributed engineering organization, we realized we wanted to distribute leadership more.

- "organizational model": "We divide our team into smaller sub teams according to X"

- "evolved": Something failed and we need to fix it.

- "align": (trendiest word in corp jargon right now)

- "distributed engineering organization": People working remote.

- "distribute leadership": More leaders.

My take is managers are there to support their engineers but also to make decisions when the team does not have consensus.

Is is similar to larger companies where from the Senior Manager level onwards there are many times more managers than engineers, with the ratio becoming more pronounced at each level?

Product thinking and work breakdown discussion: In this interview, the candidate and another member of our engineering management team discuss some questions related to their ability to understand work and delivery, and guide discussions from a customer value perspective.

What does that even mean?

Not true, probably for a majority of people. Alumni networks and family connections are not the norm. A support network and feedback is not something everyone is privileged to, which is probably why so many companies eventually create roles like this.

> Best way to support an engineer is to give him or her a fixed budget for development, and time to actually learn new things and not have their skills stagnate.

Is there any proof of this? Every Fortune 500 company and a vast majority of successfully-executed projects beg to differ.

> It saddens me to see the continued emphasis on hierarchy throughout the industry

Because by-and-large it works? For every Valve there are countless shuttered "unstructured" companies that floundered due to bad management and lack of ownership.

It would seem that people in technical fields often have problems with this kind of skill, and need help to improve it. Fortunately we have these things called jobs where we have this great opportunity to be exposed to people like that.

> As to your second sentence, what on earth are you talking about?

On why structured hierarchies are successful.

> You already have it with architects, leads, principals and others

These roles don't make business happen top-down. They'll be kind of useless in a room without someone driving vision and direction and, you know, deciding what's good business and watching cash flow.

> The problem is too much bureaucracy.

Says every engineer that's never been a manager. Like it or not, bureaucracy is the natural friction that occurs from competing priorities and limited resources, and no amount of smart "self-starter" engineers is going to change that. How do we know this? Point out the number of successful companies based on either approach. We like to call this empirical evidence.

I do own my own company though, and have hired 5 people so far. Its not a lot, but I have managed people in the past as well. Do not assume things about people.