Hacker News new | more | comments | ask | show | jobs | submit login
What we've learned about hiring engineering managers (circleci.com)
234 points by aechsten 21 days ago | hide | past | web | favorite | 100 comments



I firmly believe great software engineering managers are people who are adequate developers, but have excellent people skills.

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.


I have worked for Intel for a bit. I haven't stayed there for long but I have learned a lot about how great engineering management works.

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.


Best style I have seen is 'people' manager that has the soft skills and interest to do the organizational performance stuff, and separate 'project' managers that manage the work and teams. This allows technical staff to easily move around as needed to different projects without it being a big deal. That also encourages the project managers to be good so that people will be interested in working on their projects.


Most organizations don't have the foresight or bandwidth to organize things this way. It's always just one person do everything. I hate it.


Same. My current org actually got rid of our project managers over the last year and a half. So now my direct (engineering) manager is basically an overburdened full-time PjM, with spillover landing in my lap constantly (I'm an engineer and a team lead). It's extremely frustrating. And I can't even remember the last time he and I had a one-on-one.


I also work for Intel and I'd attribute this to the two very distinct tracks that are laid out, either the technical track to Principal Engineer, Fellow, etc. and the people track from manager, VP, etc. A LOT of people end up stopping after 3-4 promotions because it takes a lot to reach the final stages of this track but it provides a really robust pathway for people who want to have technical/people influence on dozens or hundreds of engineers but not necessarily thousands.


As a dev that has been promoted to manage (not just lead, manage) a reasonably sized team, but is still expected to code regularly, what you're describing sounds like paradise. From both the management, and dev perspective.


If you have a reasonable sized team that you're expected to manage, you should not code at all, let alone regularly. You will fail at one always, but more often both. My rule - if you have 5 direct reports (any role) you can code light stuff, sometimes. If you have 8 (a full team) you should not code - you will drop stuff over time and morale will sink a lot.


Funny, had an interview at a boutique consulting firm as a manager, told me something like : no no! You are not expected to bill like 90 or 100 percent. Aaaannndd I'm out. Those shops work like : bill 80 or still 90 percent while working with the team 100 percent. No thanks.


Or, like me, they love development and don't find it frustrating, but they would rather follow the money.


Often (I don't claim always), such a person is not as good at being an engineering manager as someone who was just ok with developing, because they keep wanting to interfere in low-level development decisions. Because, you know, those were the kinds of decisions they made when they were doing the job they actually loved doing.


This is my struggle. Do you go the management route for the money or stay in development where the pressure, and pay, is lower...


Have you considered consulting? Where you have more control and leverage over your earnings? (Especially if you have a spouse whose health insurance you can use)

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.


I haven't considered consulting mainly out of fear. I know a few very talented consultants that struggle to maintain a steady client-base. I'm the sole income + benefits in our household and with multiple little ones, my risk taking has decreased considerably. PMing might be an option though. I've worked mainly for smaller companies, so I imagine that's something I'd have to transition to a mid/large company to find?


In my career at least it’s never been true that the pay or pressure have been lower as an engineer vs a manager.


That's good to hear! My understanding was that as you move towards your 40's and 50's it becomes more challenging to find engineering roles that are willing to compensate you for your increasing experience levels. I hope I'm wrong.


The best engineering managers I've worked with still code every day or at least every other day. They are more than adequate as developers and they also have people skills.


But people skills is herein defined as lack of technical skills.


I recently realized that there are roughly two kinds of people, namely people who are good at symbolic/abstract ideas and people who are good at real/physical/touchable things, which can be considered orthogonal to the extrovert/introvert categorization. For a software engineering team, I find it tends to be suboptimal to have a physical-thinking oriented manager who dislikes abstract, symbolic notions, even though they are brilliant and would probably a good fit for say electrical or mechanical engineering teams.

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.


In my experience there are two kinds of people; those who are good at many different things, and those who believe there are roughly two kinds of people.

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.



This is interesting. I self-identify in the symbolic/abstract side of things and really struggle with how difficult it is when dealing with the real/physical/touchable camp. I've especially struggled with superiors who are in the latter group which tracks with what you say here. And as another point of anecdata I've personally been meandering my way into the leadership/management turf over recent years.


Yeah, I noticed that if I want to be perceived as good in x I often have to pretend that I am bad at y.

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.


I only mostly agree. The soft skills are crucial. The other critical part of a good leader is vision. Engineering skills are helpful, but only so much as they help eliminate distractions from the vision. Junior engineers bring in all kinds of distractions to make things supposedly easier.


> Engineering managers at CircleCI are now dedicated to people management: focused on development of a set of engineers, tech leads, and team leads. They hold regular 1:1s and career growth conversations with the engineers who report to them, and are responsible for goal setting, feedback, coaching, and mentoring for them. They also work across a set of teams to ensure team health, knowledge sharing, business value delivery and alignment across teams. This means that our engineers have managers who have great interest and investment in their personal and professional growth, and teams have someone to coach them through the product delivery process.

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


Notice how every one of these tasks are things required of the engineer to satisfy the manager. None of it contributes to the productivity of the worker. And only a small portion of it has any relevance to the productive of the company as a whole.

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.


This sounds like you haven't had a competent manager before (nothing to be ashamed of, I was there once!)

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!


> They're a safe space for you to complain, and share what sucks about your job

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.


Your description does not sound like good management. Wouldn’t it make more sense to have a mutual working meeting where both IC and manager commit to goals and achieve organizational changes in a more coordinated manner? How could a conversation with a manager with hire-promote-fire power be considered a safe space? An EAP specialist would be a more appropriate outlet for venting.

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.


I think that's a very cynical view to take. Have you had experiences with good and bad managers? In my professional life I've had both, and I can tell you that the difference is night and day. I'm in a "bad management" spell right now (yay, academia) and I would love to have regular 1:1s and get feedback that I could actually act on.


Circle CI also supposedly only hires the "best engineers".. I didn't realize the best engineers needed so much focused management.


This is totally consistent. The best athletes receive the most focused coaching. This makes perfect sense. They need experts because they're at the leading edge. The slightest of annoyances is costing you major productivity. It is precisely the best that you need the best coaches for.


Before I write out a long response on how I, as somebody who played sports and received coaching, believe that non-technical managers of software engineers and sports coaches contrast more than they compare I have to ask.. I'm guessing your being sarcastic? :D


If that were the case, why does practically every company that has engineers also have engineering managers? Are we all just doing it wrong?


I've worked at companies, and know others who work at companies, where being an Engineering Managers means you're 90% developer and 10% manager. You're expected to do one on ones, assign work, but mostly code.


I would expect that to be called tech lead. Though probably closer to 80/20 (or lower) than 90/10 by the time you include all the extra work and meetings he or she has to go to by dint of being in that role (vs say the next most senior engineer).


I completely agree and that's been my argument the whole time as well.


So usually the EM is either "Technical" or "Non-Technical".

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.


This isn't the nomenclature I'd use. What you describe as a "Technical EM" is what I'd call a "Tech Lead", who doesn't have people management responsibilities (things like 1:1s, recruiting, growth and success of the team, etc) and focuses solely on the technical execution of a team. In my book an EM is always responsible for those people management things, and I'd use "Technical EM" to describe an EM who secondarily takes on some or all Tech Lead responsibilities, directly contributes code, etc.


I've reported for years to EMs who didn't code, and they were just pointy-haired bosses: coming up with ways to manipulate people to make progress quicker, writing performance reviews mostly based on other people's input (why, then, couldn't those people write the reviews themselves?), not understanding engineering realities like some tasks being unknown, demanding ironclad estimates, judging based on appearance rather than substance (or a mix of substance and appearance), and so on. They were just overhead.

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.


Fair point.


My experience is that a manager who is sharp and knowledgeable will be able to perform the non-technical tasks with confidence and ease, while the non-technical manager will be consumed with politics and divide-and-conquering his own team and its perceived adversaries.


"Technical EM"? What about architect? Or is that title no longer in fashion?


You can be managing the engineers (your definition) or managing the engineering (another definition). You could describe both as an ‘engineering manager.’


I am assuming they did actual work alongside management responsibilities, which isn't really sustainable.


> We look for candidates’ ability to mentor and add value to technical discussions while understanding their own limitations, supporting a technical decision without acting as a decision-maker.

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.


My personal model for how to handle the relationship of tech manager vs lead developer (actually all developers) is that the manager should definitely supervise and understand the decisions made. If she has concerns about them, be straightforward with the team, saying "I like x,y,z about your plan but I am concerned about whether we are getting in trouble on A or B". Let the team work out the problem and respond.

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.


> supporting a technical decision without acting as a decision-maker.

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.


you are stuck on the model of manager-as-boss. in order to create a true engineering ladder that is separate but equal to the management ladder, tech teams need to make the decisions. it is the tech lead (whatever rank he may be, let's say principal for sake of argument) that makes technical 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.


>you are stuck on the model of manager-as-boss. in order to create a true engineering ladder that is separate but equal to the management ladder

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.


hiring decisions are made by the team, not the "hiring manager". putting the responsibility of "tie breaking" votes onto the HM is a reasonable thing.

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.


Hiring decisions made by the team are short sighted. They tend to hire people like themselves with similiar ideas. If you are looking for a balanced diverse team group think will not replace a hiring authority.

It is probably the best way to find someone likable by all. But bad for someone who might challenge ideas. Unless they find someone that has traits that everyone is in awe of but usually that only happens when there is a single person role with no other developers working in that layer or silo of the stack.


> being responsible for the decisions can't be separated from making those decisions.

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 been fortunate to have two great direct managers at the prior companies I've worked at, and one common thread they have is they've both been developers. I think working in the field before you command people who do so helps build empathy and understanding of the problem at hand, as well as how it all ties into the bigger picture.

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)


Not sure if this is a counterpoint, but pretty much every direct manager I've had (except for one, and she was awesome) started their career as a programmer, and I was also a manager that went from programming->management.

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 think there's something about programming day to day that actually makes it harder to manage. I used to be a PM and a people manager, IC engineer now, and I've found that my ability to convey concepts clearly has degraded because I spend a lot of time in the weeds. I have to purposefully step back to think about framing because I don't automatically have to do it.

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.


As an introvert who was a manager for several years, I agree that it is very difficult and draining. I believe that I have the skills to be a good manager (empathy, EQ, organization), but I did find it extremely draining. Towards the end of my experience I could tell I wasn't giving my best to my direct reports and so I've gone back to being an individual contributor.

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.


What specifically was draining about it? What drained you? Why?


Because that's basically the definition of the difference between introversion and extroversion: introverts "recharge" by being alone, while extroverts "recharge" by being around people. If you are an introvert and forced to have lots of people interaction daily, you basically don't have a chance to recharge.

My experience was basically exactly the same as subpixelated.


> If those interactions all take energy from you instead of give energy

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


> 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

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.


I agree with the sentiment but I'm not so sure about 100% and calling it night and day is exaggerated. I've had anecdotes both ways. I think there's some important factors to consider:

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


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.

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.


Can confirm that Mustangs were highly preferred by those that reported to them over academy grads in the Navy.


So basically "we were devs and we want managers who are devs" .. which inevitably leads to "we really need some real managers"

full disclosure: i am senior dev and a bad manager


Developers can acquire 'real manager' skills. Jerry Weinberg, from volume 2 of 'Quality Software Management"

"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


Thanks for posting those Jerry Weinberg quotes. I'd never heard of him, and just spent a few hours reading up on him. I think I've found another role model tonight :)


I got to meet him, several times. He is as thoughtful and eloquent in person as he is in writing. He's certainly one of my role models, so I commend your choice :)


yep, me too. it's depressing.


My ideal manager is someone who has been at the company as an engineer, has great people skills, and knows how to think at the macro level.

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.


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


benign neglect is better than malign involvement - micromanaging, bad judgement, disruption and chaos etc ...


They are both bad.


I don't know if you just made that phrase up, but it's great.


I think it's good that they are doing some more managerial skills fit, although I think even a good manager for one team at a company might be a bad manager for a different team at the same company.

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.


100% have the team involved. I recently hired for a manager to take over one of my dev teams, had a couple of candidates I was on the fence about, but after hearing the development team's feedback, removed them from the running. A person's manager is one of the most influential people in their lives, like it or not, and it's very important to give people a say in that decision whenever possible.


I've always been apt to push for a more technology-oriented manager due to logistics because I don't need/want a non-technical "career coach" calling the shots on implementation/execution when they don't even have an IDE installed on their laptop... which is why I feel they specifically nailed it with this - "We look for candidates' ability to mentor and add value to technical discussions while understanding their own limitations, supporting a technical decision without acting as a decision-maker."


Unfortunately, the term manager is what makes this difficult. If they were merely Team Secretaries, keeping track of the decision making and the financial implications, things would be better IMHO.


I've made it a personal rule to never work for a non-technical manager ever again. Having experienced both sides of the coin, I like to think I'm able to learn from past mistakes in life.

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.


Experienced developers don't always make the best managers, but the best managers are almost always experienced developers.


What I don't want is having a non tehnical person evaluating my tehnical skills in order to decide my raise...


I often hear that experienced devs don't necessarily make good managers, but that's not always the case. It's important to not force devs into becoming managers if they aren't a fit. Therefore, the traditional tree structure of promotion doesn't really fit development. You should be able to gain responsibility and compensation without becoming a manager.


May be the non-technical manager thing works for big companies but it might not be the case with the rest.

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.


This entire post is a perfect example of the awful corporate jargon infecting our culture right now.

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.


Having separate "people leaders" and "technical leaders" is a cop out and poor org design. All you are doing is creating opportunities for conflict. Finding great technical people with an aptitude for leadership is hard, and the market for that kind of talent is fierce, but it is worth it. Settling for less is settling for having a mediocre engineering team.


I am on the fence about this. I think it sounds great in theory and it may even work for smaller companies. However, a problem I’ve encountered with this approach to engineering management is that it ignores what the managers need to do to develop and advance. My current company has a very similar role for managers. The problem is that for the managers to advance they have to make an impact to the wider org. So this leads to the craziest, most toxic politics I’ve ever seen. In my opinion, when managers can be judged on their ability to make good technical decisions, it leads to a more objective outcome when judging the performance of a manager.

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


It would be interesting to see how many engineers vs managers there are for each compensation level at CircleCI.

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?


The right sort of engineering manager for a company very much depends on the size of the organization. Large companies can afford to have professional managers with minimal technical skills because they can also afford to have lead developers and architects. In a smaller organization, that’s not possible and you need to understand the team you have and then mitigate the inevitable weaknesses of the managers.


Such a handwavy article. I wish they were more specific of the type of questions/exercises they asked/did in their interviewers.

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?


You have to synergize authentic work-streams.


Well, "work" is doing stuff, "delivery" is giving that stuff to other people. Not sure why they need an entire discussion about whether the candidate understands that, it seems like something they could cover in the phone screen.


> Engineering managers at CircleCI are now dedicated to people management: focused on development of a set of engineers, tech leads, and team leads. They hold regular 1:1s and career growth conversations with the engineers who report to them, and are responsible for goal setting, feedback, coaching, and mentoring for them.

Do you really need this? Developers will have their own set of mentors, coaches as well as people in their network that will help them grow if they are interested in remaining relevant. Why one earth, would you spend so much money on EMs when developers should be given time to think about what they want to do themselves.

The title should be changed to engineering nannies. Furthermore, having non-engineers as engineering managers _can_ work, but it can be a risky move if the person in question does not have enough respect and empathy for the work an engineer does.

It saddens me to see the continued emphasis on hierarchy throughout the industry. 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.

I think we need to go back to team leads having hiring and firing power. At the end of the day, they code and are down in the trenches with the rest of the engineers.


> Developers will have their own set of mentors, coaches as well as people in their network that will help them grow

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.


> Not true, probably for a majority of people. Alumni networks and family connections are not the norm.

Networks don't magically appear, you need to work on building them.

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

I don't have any proof other than my own experience. As to your second sentence, what on earth are you talking about?

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

There is no problem with structure. You already have it with architects, leads, principals and others. The problem is too much bureaucracy.


> Networks don't magically appear, you need to work on building them.

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.


> Says every engineer that's never been a manager.

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.


In short, don't give managers the same interview as engineers. Sorry but seems pretty obvious.


Engineering Managers aren’t necessary. Project Managers are, and so are experienced engineers willing to lead technically.


Any good, blogging engineering managers to follow?


Charity Majors https://charity.wtf/




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: