"My boss says we don't need any engineering managers"
charity.wtf
charity.wtf
Instead you should notice the natural hierarchy that forms based on everyone's desire to build things. Some of your engineers are already deferring decisions to other engineers, and you just have to pick up on that as you develop a leveling system. That's where a hierarchy should come from if you insist on it.
It sounds like this is already what's going on given that you have clumps of 3-4 engineers around leads. And the author even says "hierarchy is a property of self organizing systems". So clearly this system is self organizing and working. But the author has no skill for designing organizations, and doesn't know what to do if he can't hire managers and make it look like what he's used to.
It sounds like a bad culture fit. The CEO needs a VP who isn't stamping out the same organization job after job, and can embrace and extend what is already working at this company.
But do those other engineers want to be managers? I've certainly picked up some of that work from time to time in my career, and yet if my boss told me, "congratulations, you're being promoted to manager!" I'd have to respond with, "congratulations, I quit."
You could either embrace this as the start of the hierarchy everyone is apparently so desperate to create. Or you could ignore this signal in favor of handshakes, smiles, buzzwords, or however else you intend to pick a manager from your outside funnel.
Part of this reluctance is an aversion to the busy work that often comes with a manager title. Work that managers create for themselves and other managers to legitimize their roles, but which actually impedes progress, and annoys or alienates talent.
Fundamentally, small companies that accomplish things tend to have relatively strong cultures, and external managers (by definition) are not necessarily part of that culture.
I've seen an external manager cause loads of issues because of this, even when they come in with the best of intentions.
In smaller companies, you are almost always much better off promoting internally for a number of reasons. Firstly, it demonstrates (assuming that you make the right person the manager) that there's a path for people on the team to progress. Secondly, they are already aware of the actual problems with the company, and (importantly) the kinds of solutions that are acceptable.
I currently work for a small, fast-growing company and our external manager decided to rebuild a core system at the weekends and push it to prod. Now, the system is actually pretty good (I dislike it stylistically, but i have niche tastes).
However, what this person didn't consider (because they were new) that the org was not going to give much (if any) time to move stuff over to this new system. As a result, we're about 50% of the way done 18 months in, and in the interim, we've had to not do a bunch of stuff that would actually improve our product.
Like, I remember (and HN hate this company so it's unlikely to be listened to) when FB started getting really successful (2013-15), we ended up hiring a lot of Google/Amazon managers and leaders externally and probably through negligence, they ended up destroying a bunch of what made the culture great.
Hiring bad managers is much, much worse than no managers, but if you promote an IC then they have a valid stepdown path if it doesn't work, which an external manager is less likely to have (or indeed, accept).
And thus concludes my Ted Talk about avoiding external managers.
This was a pretty good Ted Talk!
OTOH, unless you are the team lead, the amount of bike shedding from simply taking initiative and just making a tactical decision can be overwhelming. It's framed as "not building consensus first."
A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"
Many orgs do not view engineers as decision makers, simply as do'ers, which really I think highlights how the role of a software engineer is just misunderstood. Software engineers are more like writers than they are like carpenters. Consider for example the number of decisions made when writing a single sentence, let alone the upper management that can barely make a decision more fine-grained than the title of the book and whether it should have one or two main characters.
At this point we are almost certainly talking past one another. I've never been at a company where management didn't have the final say. In your world where managers don't decide anything important, I guess they are just HR secretaries? They have 1:1s with people and try to figure out who needs to be replaced and who should be promoted? What is that like?
> A PO recently chastised me after I worked with a user who wanted a date field to default to today. I was asked "who told you to do this, where is the JIRA that described this work?"
This is really the root of the problem. Implicit in all these titles ending in manager is decision making authority, and the selection process does not in practice produce better decision makers. A competent engineer experiencing a customer problem first hand is the smartest and best informed person in the room. They should be expected to make the best decisions about how to use their time and skills. But there is a charade that plays out involving * managers, who have been given decision making authority. They either agree ceremoniously or look stupid with little corrective consequence.
With regards to our differences, I view software management more as a leadership role rather than as a decision making role. We won't quibble that leaders need to make important decisions, we both agree there. Yet, providing direction is different from deciding direction. That is my point, software managers are deciding neither "what" nor "how", and thus their role is (IMHO) primarily more leadership rather than decision making.
By one metric, I'd suggest software managers are most responsible for helping their team maximize the ratio of time spent focused on-task to the time spent dealing on noise. While that is an interesting metric, it's still hard to tease out the effects of organization and team structure from the role of just one person who is meant to largely coordinate (AKA: direct or lead) and enhance those networking effects.
My standard joke is: We must be doing incredibly well if you have time to ask me that. Ideally the standard joke is followed by a [long] list of things they should or could be working on and then I force the conversation into that direction. If they ever bring it up again I remind them that they had already mentioned it and change the topic to actual work again. I've had a good few burst out in laughter going though the process specially the 3rd or 4th time.
The phenomenon is known as 'the elves leaving middle earth', per a 2009 Steve Blank post:
https://steveblank.com/2009/12/21/the-elves-leave-middle-ear...
Per Steve's post, the real wake-up call is typically some beancounter deciding to charge for the free sodas in the break room. But I would agree that hiring a bozo manager is equally as much of a wake up call.
My advice for you, after I leave, you go pick up a few boxes of pastries for your employees. You've never done this, correct? Then I gave him the military salute and left not waiting for an answer.
Turned out he was the funny kind of blunt asshole. A year later I ran into someone still working there in that place where no one ever smiled. Apparently the boss got the boxes of pastries and told his employees it was my idea etc One employee told him I was right, I cant remember the last time you did anything nice because you never did, you are an asshole, you've always been, we should do this every week.
It was long long ago but I'm sure they still eat pastries every week.
The difference between one company and the next (eventho they do similar things) can be pretty strange. My mind flashes back to a few places I could only describe as a different kind of death that might be worse than conventional death. haha
Managers justifiably get a lot of flak, because management is fairly intangible, our society has decided to conflate authority and prestige with direction-setting, and there are just a huge number of incompetent managers.
But anyone that's tried a multi-person project without management understands the value of management. Someone has to step up and manage, and if it's your best engineer, you're spending a pretty valuable resource (their time) on something someone else might be able to do better.
Finding good managers is super hard, but a good manager can still be valuable, even though bad managers are frustratingly useless.
Basic rules of staffing university departments:
0. Generally don't hire your family or friends. The assumption of nepotism will be hard to shake.
1. Blind resumes and interview candidates and have a hiring committee rather than giving jobs out preferentially by a single hiring manager unilaterally, because there is a human tendency to hire people unintentionally reinforcing propinquity biases.
are you saying the ones doing the deferring should be managers, or the ones being deferred to?
This happens in every organization and you can't really fake it. The alternative to asking another person for help is becoming a low-performing lone wolf. Given the choice, people choose to reveal who they believe is competent.
(https://hbr.org/2013/12/how-google-sold-its-engineers-on-man...)
I am an Engineering Manager/Director and my life is quite hectic and not because of busywork. You work with some very brilliant people, but they often fail in conflict resolution. Even if you don't have EMs, you still have upper management and more often then not they're out of touch, here the EM acts as a translation layer that understands both the business and the tech enough to balance these tensions well to make sure the team works well while delivering value for the company. Sometimes you need to deal with other teams with their own agendas.
In essence - if things go well, there's less need for an EM. I had a well running team last year, so much so that my life was quite calm. Then the leadership forced product domain and technology change on us and we lost our tech lead. Even if 90 % of the team stayed the same the dynamics were completely new and I had to help the team navigate an uncertain environment. Things went to normal and suddenly we became responsible for the core of a cross-team project and I am busy pushing against leadership, getting other teams to commit to take the burden off of our core team and other much needed activites. My tech lead couldn't do that while also designing the tech solution so in a way I am helping them do better work.
The thing EM adds for me is agility (small a). Our engineers work Agile (quite happy with it), but they are human. They (as a group) have an overarching goal in mind (to reach X now, Y later, to keep Z in check, but replace O around then and then). Management can undermine that medium term feeling of being in control. That leads to losses in confidence and commitment. EM helps bridge that gap. In the end it all comes down to getting the Why across emphatically.
The best engineering managers can push back against changes with specific estimates of how much the changes will increase the budget and delay the deadline.
Of course, some changes are inevitable. But core business doesn't change that fast. It is the vanity of other managers that often introduces demands with no underlying benefit to the business.
Managers can bring value from multiple aspects, one being faster decision making by shifting away from decisions through consensus. What Amazon calls disagree and commit.
If you go back even further, the no manager philosophy traces to Steve Jobs and his "It's better to be a pirate than in the Navy" quote. With the idea that pirates self organize and are a stronger team. Works great in a skunkworks department, where Jobs personally selected pirates. Falls apart at scale.
> It’s not uncommon to find engineering managers with 30 direct reports. Flatt says that’s by design, to prevent micromanaging. “There is only so much you can meddle when you have 30 people on your team, so you have to focus on creating the best environment for engineers to make things happen,” he notes. Google gives its rank and file room to make decisions and innovate
OP:
> I recently joined a startup to run an engineering org of about 40 engineers. My title is VP Engineering. However, I have been having lots of ongoing conflict with the CEO (a former engineer) around whether or not I am allowed to have or hire any dedicated engineering managers
So Google, by design, had some managers with 30 direct reports. And they thought that went well. Meanwhile the above CEO wants the VP-engineering to manage 40 direct reports. The numbers are slightly different but they are in the same ballpark.
I find the OP's response not very convincing. The above CEO isn't trying to build a no-hierarchy org. He wants his tech-leads to also double-up as mini-managers, with dedicated managers only at the VP/director level. I personally know of at least 1 other very successful company with a similar policy.
The great thing with startups is that they are a low-risk avenue for experimenting with new ideas. Including new organizational-cultures. If Google and other early pioneers hadn't experimented with cultural changes, we would still be working in suits and drab gray offices. The CEO could have done a better job of explaining his vision to the VP before they joined the company. But besides that, I'm glad there are startups out there experimenting with radically new ways of working.
The real difficulty, which the author only touches on at the end, is optimizing the number of managers. Not only are there diminishing returns to adding excessive managers, more management creates more workload for everyone past a point. But even though the organization would benefit from scaling back the number of managers, there is an obvious individual disincentive to say "it would be better for you all if I was fired." Thus once you get too much management, it tends to stick around[0], and therefore it is critical to avoid excessive management in the first place. The article articulates clearly why you need more than 0 managers, but it should include strategies for determining whether you need an n+1th manager.
[0] There is one fix. It's tough to get rid of excess management, but an organization can potentially grow into an appropriate size for the amount of management it has. This may be a challenge for a mature company, but for a startup like the one featured in the article hiring too many managers is just hiring an appropriate number of managers early.
What I've found over time is the implementation of this is often very inefficient.
The coordination aspect is often a blend of the product organization and the engineering leadership, and in both cases I find there's too much authority pushed all the way down into individual scrum teams. There needs to be a cohesive product vision across all of the teams, and some set of people need to make sure they're all working on roughly the same things at roughly the same time. But that's about it. And you don't need a Product Manager, an Engineering Manager, and a Scrum Master for every set of 8-10 developers in order to make that happen.
The people management portion is trickier. You *do* want to cap that at a ratio of about 1:8-10. But this role is traditionally associated with authority over things like on what their reports are working. Which exacerbates the point above.
I've not been in many companies over the years - mostly worked independently - but in the companies I've been in, that was never on the cards. Ever. I don't doubt it exists, someplace, but never saw it in person. Bit of a shame, as it sounds nice.
I’ve learned not to mention that, here, as it often results in fairly insulting attacks.
I get the feeling that people don’t actually want to be managed that way.
> people don’t actually want to be managed that way.
That is not management, per se. It is a way to try to extract more value from employees outside of the business. More often than not, documentaion (ie quarterly reviews) is weaponized when cuts are being made. This is by desgn.
If something is not a reliable tool for making their job better, engineers will choose to avoid wasting work time with it.
As someone who has gone in and out of engineering management over the years I actually kind of wish this were true as it's the part I enjoy the least. I don't know if it's a generation thing or the times or whatever but I've found it's very much an increasing trend. My job becomes more therapist than anything else.
Managers do that?
Well, second to go, right after they have the task of laying off their team first.
The middle managers (the VPs and Directors) are essentially useless as they are passing forward the leadership 10,000 ft view. The managers are stuck implementing in their area and thus no two teams operate the same way. The workers are then in this area of constant upheaval as nothing seems to get accomplished the way leadership expected.
I read these articles as they seem to have come out every year first Google then Zappos then various startups. Leadership communicating to workers never seems to work out well as companies grow. They operate at too high a level and unless there are a solid structure of guidance to go across teams/individuals it makes it difficult to all row in the same direction. It makes sense that a UI team is going to operate at a different cadence to the services team to the data team, but if you don't have managers over each function at least there will be chaos in my experience.
When this works well, its obvious to everyone. "Today I'm triaging a bug that comes up for our customers. We want customers to have a delightful experience, keep giving us money and recommend us to their friends." / "I'm writing a technical blog post. I've been asked to blog more because it helps us attract good talent, and good talent will help us make better software."
But its heartbreaking how often teams and people fail this test. "Oh, I'm doing this but I don't know why. My boss asked me to do it. But she didn't tell me the reason and I didn't ask." / "Yeah we're all working hard on this product but there's another team doing basically the same thing and in 6 months all our work will probably be scrapped." / "Our scrum meetings are an absolute waste of everyone's time. My boss admitted over drinks that we only do it because it makes our team look good in the meeting with all the big bosses."
Sometimes the problem is communication. Sometimes its a lack of initiative on the ground - eg "I learned to stop asking questions like that". Or a lack of mentorship to junior employees. Sometimes its a lack of leadership from the C-suite, or incompetent middle managers or VPs or something. But whenever people can't explain the point of their work, something is going terribly wrong in the company, and I hear a calm voice playing in my head: "Please take a moment to locate the nearest exit. It may be behind you. In the event of an emergency, ..."
Do leaders at the tip top of larger orgs "care" if their communication works out?
Every larger company I've worked for the top leaders stated their case and just ... left the room. It wasn't a conversation, or any kind of communication I would expect where someone validates that everyone is on the same page.
What follows is inevitably middle managers repeating what was said, again no real validation that anyone got the point and everyone rolls on.
Communication from "leadership" at big orgs is always more just communication AT everyone and that's it ...
In such situations it's hard to imagine the top leadership really care beyond getting their noise out in the room / email / etc.
Is your company, by any chance, based in San Mateo and Raleigh?
Well the first problem is management calling themselves "leadership." Then there's communicating "to" instead of "with" a separate group of "workers." Someone who tries to convince me to do all the work is not a "leader."
That scenario seems more like a setting for a fable than a healthy work environment.
It leads to very passive and indirect statements.
I worked for a year with no engineering manager, no software director, no VP of Engineering. The most productive year of my group at that job. Brought out two new versions of our OS to support multi-processor configurations and use new memory modes.
No you did not. You were the engineering manager
I'm not sure if that is bad or not - while it is annoying to attend all those meetings, often you know the problem well enough that you can just build the right thing. You start to feel empowered to add this feature customers want because you know the customer
You can also run a company of _hundreds_ of engineers who are all self-governing. If it can happen at least once (company I worked for), then it's repeatable and therefore a viable alternative.
The fact is, the work of an engineering manager is largely make-work. Something to justify a middle manager's salary.
But did this significantly impact the business in a positive way? If it was a wild success why did it only last a year? Part of managing software engineers can be to stop them from doing things that merely feel productive.
It lasted until we got bought (the price of success) and the old-mill buyer installed drones to crush moral and productivity. They had no idea how an engineering company worked.
I quit and moved on.
I am not saying that to take away from the accomplishment, as another said: you were the engineering manager.
A manager is often the delivery system for all the messages that engineers aren't interested in: The fickle customer, the imperfect or unattainable vision of the enterprise, fiscal demands.. Often managers are delivering you unpleasant, distracting, or annoying news. But if they are good they are giving you a lot less of that distraction then if the org were flat.
Prevent other teams from reaching in and randomizing our priorities, work on promotion plans for anyone seeking promotion, manage customer/partner team relationships, ensure everyone has balanced feedback regularly, mediate disputes, collect information to manage upwards so we can still be funded, advise on team process but never mandate it, facilitate accommodations, manage poor performance so the team isn't dragged down, try to consolidate and clear meetings from calendars across the team.
If I'm not around, then all those things either don't get done or fall to the engineers themselves. I personally think it's useful to have someone on the team specialize in those activities for the benefit of the team. But I'll admit my bias.
> Prevent other teams from reaching in and randomizing our priorities, work on promotion plans for anyone seeking promotion, manage customer/partner team relationships, ensure everyone has balanced feedback regularly, mediate disputes, collect information to manage upwards so we can still be funded, advise on team process but never mandate it, facilitate accommodations, manage poor performance so the team isn't dragged down, try to consolidate and clear meetings from calendars across the team.
Now I won't pretend that these are not real problems that companies have, but I would argue (from my own experience) that they are not problems that all companies _must_ have. A company I worked at did not have these problems — _without_ a manager sorting them — and we had literally hundreds of engineers. Granted, this was a single company, and I've not seen it happen since, but if it can happen even once, then it proves the point.
When you have tens or hundreds of thousands of people working together, those responsibilities become large enough that centralizing them makes sense.
Engineering management is just specialization of a role, based on the need to have a specialist fill that role. Just like a games studio with 5 people doesn't need a dedicated build engineer, but a game studio with 1000 people probably does.
That suggests at least one of:
1. a need to delegate more so that reports can be more autonomous
2. a need to groom replacements internally
If someone has a well-managed team, they should return from vacation with individual people having missed them but the company as a whole being unaffected.
Managers are like cockroaches, every time you turn on the lights, there are more of them scurrying around.
Yes, we do need project managers, but before you hire them you need a plan and business managers can't come up with sufficiently detailed WBS to drive a project of any significant complexity.
Before you have a project plan you need a business case and a marketing plan.
As a founder and soon to be CEO you need a rock solid business case.
Then a capable technical person comes up with a project plan with sufficient detail (aka WBS) that you can see what needs to be done and a provide a reasonable estimate of time-frames and resources required.
Only then do you need a project manager to make it happen. If the project is sufficient large, then groups of technical personnel might need a more experienced person, aka team leader.
The bane of so many "projects" is that they have a vague description of a deliverable, a hard deadline and a budget created without any comprehension of what is required to create the deliverables and whether the business plan will even sustain the realistic need for resources.
Maybe, in the article's startup with 40 engineers, if they want to structure it as compartmentalized worker drone resources, who mostly only do what they're tasked to do, and someone else has their eye on the bigger picture and what all the teams need.
Depending on the nature of the project, 40 engineers could be a lot, and might have big coordination overhead and risk. Then maybe managers and/or cross-team technical roles can help with that.
Or maybe the bulk of it is something easily parallelizable and straightforward, like systems integrations for many customers around a shared core that they don't much change. Or they're building something that they're sure fits a routine pattern, with little cross-team thinking to do (e.g., "simple CRUD, with Web backend, Web frontend, and iOS and Android apps"). If the work is that simple, but still voluminous, you don't need many people who aren't either typing code or determining&selling product.
With nothing coming up, I'm getting my biases confirmed that orange site remains unable to discuss the conditions of our jobs.
Until we can discuss power and control instead of just how we build things you're gonna have managers same way a prison has guards.
At a minimum, I’d limit it to two or three managers (12-13 reports). Adding EMs for each 3-4 person team is overkill, and a huge morale hit especially if they are outside hires.
All I can see is a massive 25% headcount increase that will result in ten people trying to implement [latest-job-I-had] structures and “show impact”. Seems like a recipe for disaster at a startup.
You will know this because the managers keep creating specs without consulting the IC’s and the amount of useless busy work and fake deadlines go up.
https://www.youtube.com/watch?v=7dcDuVyzb8Y
https://en.wikipedia.org/wiki/Coastline_paradox
Problems are fractal-like. Each section of a problem needs attention and management. Engineers are largely self-managing - we pay attention to the problem in front of us. There is still a need for coordination.
The article's topic is of common interest, and the quoted question's little details sound plausible/familiar. But I'm wondering whether the quote was contrived by the article author, to set up the article in a more engaging way?
Yes, I could just do a search but imo is also worth mention and listing the key points that the author wants to highlight about them. Otherwise everyone is taking away a different interpretation.
I worked on a team half that size with a single manager, our "lead developer" and it was remarkably smooth.
I ask what is keeping the VP of engineering so busy that they can't handle that work themselves?
In a 20 person team the lead developer also played the role of EM?
Limited transferability in all likelihood.
I'm not saying that has to happen. I'm just saying I've seen that more often than not. Maybe it's a side-effect of having tech founders who don't really want to manage.
:D
Yeah.