Do you really enjoy having 3 different managers to report to? All of whom have 3 different projects they’re dealing with? IMO, it’s better to have a 1:1 ratio of managers to teams. A 3:3 ratio is a recipe for endless meetings and communication overhead. 1:1 and 3:3 have the same number of employees, but 1:1 eliminates all of the communication overhead because there’s only 1 manager per team instead of 3.

In my experience, splitting managers, designers, and QA people across 3 simultaneous projects results in 1 project dominating their time and the other 2 projects being starved for attention. Repeat this across the product manager, engineering manager, QA person, UI designer, and project manager and you virtually guarantee that every project is going to be starved of resources.

Instead of having 3 separate product, project, and engineering managers split their time across 3 different projects and wasting time synchronizing with each other and the teams, it’s better to have 1 person handle the role of product, project, and engineering manager with 100% focus on the project and team.

I’ve worked in teams like you’ve described. It quickly turns into a mess of meeting scheduling conflicts, repeating every discussion 3 times because you have to communicate it to 3 different managers, and constantly working around blockers because your UI or QA person has been pulled into a higher priority project.

Put small teams together. Let them focus 100% on getting things done. Don’t cross everyone over to 3 teams. Don’t give everyone 3 different managers.

I'm not sure where the 3 managers comes from.

Product manager (Product Owner in scrum), Senior Dev / Tech Lead, Dev1, Dev2, QA, and UI/UX Designer all report to Engineering manager.

Further, changing the mindset from "as a manager these reports work for me" to "as a manager I work for these reports" improves the feeling of ICs having "multiple managers". The managers job should largely be unblocking the ICs.

> all report to Engineering manager

In my experience, product managers have never reported to an engineering manager.

Which is probably part of the problem, and why this type of hierarchy can lead to a "3 managers" type scenario. The product manager, senior dev / tech lead, and engineering manager all have some management responsibilities. When the separation of responsibility is not clearly delineated, so the regular team members are left in an awkward position of having 3 different people they have to report to, and often get conflicting feedback from each of them.

Basically this, for us it was:

Eng Manager <- Devs, Project Manager

Product manager -- UI/UX (same org not direct reports)

QA (Had their own reporting structure)

I would further note, if you have a Project Manager that reports to leadership outside your direct team, you should have a Product Manager on the engineering team to counter-balance. Project Manager's goal is to drive leadership initiatives, where as the Product Manager's goal is to guard the members of the team so they are not stretched too thin and can build a quality product.

> 1 person handle the role of product, project, and engineering manager with 100% focus on the project and team.

This is incredibly difficult to get right. A good product manager needs to be spending time "in the field", sometimes literally but always in terms of focus. A good engineering manager has to be spending time "in the lab", again literally & figuratively.

These two things are in contention, and balancing them properly in one person is very difficult.

Anyone who has project management skills can do that part, but trick is dedicating enough time to it. On a complicated project, this can easily become a full time job.

matrix management has it's own challenges (not that this is the only way to handle it) but your contention that because there are 3 "managers" involved means that everyone "has" 3 managers just isn't true. Most of this stuff is about responsibilities, not chain-of-command.

'I have eight managers Bob' - Peter

'Eight?' - Bob

'Eight Bob' - Peter

I don't think the IC's have 3 managers in this arrangement. The product manager & engineering manager work together in a customer-provider relationship, while the project manager acts as a sort of facilitator and metrics collector, & doesn't hold direct authority over the IC's.

I think this is about right, but one sticking point I've found is: what kind of employee is the project manager? Who do you hire, what is the career trajectory? There is a temptation to have them be a manager, because hey, manager is in the name! But having gotten over that, there is a version of the job that is essentially entry level work; what you describe of managing the tickets and all the stuff is just not very high level work relative to what the rest of the team is doing. But then what is the progression? What are they trying to do after they've put in their years wrangling tickets? I think this can actually lead to a lot of unnecessary complexity. If you have a smart and ambitious person doing this job, they're going to naturally look for ways to make it more meaty. But it doesn't really need to be, so you're in a bit of a bind.

I think this is where the impulse to let the managers handle this as a small part of their job comes from. It's already clear who the managers are and what their career progression is, and handling stuff the team needs to unblock, which doesn't fit well into any particular box is already part of their job.

Project/program management is probably one type of position that almost has to lead to people management at some point. Basically operational roles that have project/program management (folks) among others reporting to them. In other words, having overall responsibility for projects of smaller or larger size.

Yep, agreed, which is once again why you get managers doing the project management; a lot of them cut their teeth there.

Agree with this point completely.

Ideally it seems as if you'd want someone with administrative capabilities and focus but with enough understanding of the tech and business side that they're able to understand context and conversation.

Problem is, although its easy to find administratively capable resources who you can pay a decent salary to retain, the minute you require them to understand broader context the incentive structure changes as this is inherently more work.

To me that is why Product Managers who's focus is a single product should also take over administrative tasks on that project. It gives them an opportunity for "field time" as stated by another poster as well.

Oof, I really don't think that's a good use of a product manager's time. I want them out talking to customers, or evaluating similar products from other companies, or using their own product to understand its capabilities and gaps, or looking at metrics, or just writing and debating product proposals. I honestly think there is already way too much work that is way too valuable for them to be doing, for them to take on project management duties. It's a much closer fit for an eng. people manager if a dedicated resource can't be found or hasn't worked out. At least their job is already interrupt driven and focused on knocking down blockers for their team.

The challenge with this is that you have ~7 defined boxes that you are trying to put a team of 7 individuals into ( or 7 roles and 13 people ). At any given point in time there won't be work commiserate with all 7 job functions, people will grow to a different role, someone will be the bottleneck, and someone will be MIA or in a backfill.

It's often best to keep the number of roles low on the team to increase flexibility/provide freedom for individuals to tailor the roles to their own strengths.

I just left a team that was structured similarly. It was a pleasure managing them.

Team members were: - Manager (me), BA - managed backlog and some project management (actual title was principal dev, but she wanted a role change), 2x senior developers (both capable of architectural work), 2x developers, 2x test engineers, 0.5 Product manager (they report through their own branch of the org chart and cover several related products).

Additionally, I had 2.5 developers working on a different project, run as a separate agile team.

New team is 1 architect, 1 senior dev, 1 dev, 1 test engineer. BA and PM support comes from elsewhere, which is a big change fo me. Also in a new technical area (SRE vs 20 years of product/app dev). Fun, but stressful. I'll reserve judgement on the lack of BA/PM until I'm a few months into the role.

What does BA stand for? Thanks.

Business Analyst.

It's impossible to overstate how much I agree with the need for a separate project management role. Project management is the biggest distraction I have from the "things only I can do" and the biggest morale and time suck. I don't have advice to give because I haven't solved my lack-of-project-management problem, but I sincerely believe I could be much more effective if this was off my plate.

As things grow, you really have to move from ad hoc processes/tracking/etc. to something more systematic that someone needs to own.

The most successful teams I've ever worked on or led were structured like this. Both at the startup level (3-4 engineers) and big co level.

Can I just throw in a wrinkle, I'm what could be described (from this list) as an Engineering Manager and Tech Lead. I architect and implement solutions while also doing all the traditional managerial duties. I feel like I've been eaten alive lately on HN that this arrangement isn't possible and you cannot do both well, but I beg to differ.

What I would say is that it's possible but very rare to do this well, and furthermore that people often don't have an accurate sense of how well they're doing at it. The individuals on the team might know but might not want to say, but an even bigger problem is the individuals on the team not being aware there is a better way. I was about a decade into my career before I had an experienced dedicated engineering manager. I had already spent time as a tech lead / manager myself by then, and thought I had done ok, but experiencing a dedicated engineering manager made me see that I had actually done the job quite poorly.

You may be doing it extremely well! It does happen. But I can understand why you're getting skepticism.

A lot of us have been an engineer on a team where the dev manager thought they were contributing but were actually taking all the interesting architectural problems for themselves and making all the decisions, which quickly becomes extremely demotivating since the opportunities to advance your own skills quickly dry up and you’re left just mindlessly cranking out code. The worst is when an abstraction is imposed on the team that doesn’t adequately cover the problem, so you have to spend twice as much time bending the code to make the dev manager happy instead of doing it the way you think is best.

Granted this is just one way that situation can go, I’m sure there’s plenty of effective dev managers who still write code regularly, just hasn’t been my experience.

Sometimes the interests of the TL contradict the interests of the EM. Circumstances like those are usually brought on by strong budget or roadmap constraints.

Usually, people in your position will systematically wear one hat at the expense of the other, leading to long-term retention or code quality problems.

It's a delicate balancing act, that isn't easy for most people to pull off. It's not impossible, I've seen it done well. But it's a lot easier when "times are good", and you are not consistently tested by hard decisions where the EM and TL hats would disagree.

I don't doubt that it's possible. Except from having these creepy "one-on-ones" and review meetings, I have no idea what the engineering manager is even doing all day, never seen any transparency around this. "attending meetings" is what they say, but what meetings and why, I have no idea. Nothing is delivered and nothing comes out of it, I really think it's a bullshit job. "Sets tone, handles career growth, shielding the team" lol, do some coding instead.

One on one meetings are not "creepy" - they are a chance to have an open conversation about your goals; your concerns; and anything else that needs to be discussed about your career, the organization, etc.

Do you know what the sales people in your organization do? What about the legal department? Procurement? HR? Your lack of knowledge is not evidence.

"lol, do some coding instead"? And what should I code? How do you know what _you_ should be coding? Where does that work come from? Who makes sure that you're writing quality code and not some shit spaghetti mess? When the lawyers come knocking who answers the questions about security and compliance? You're just going to write some code for that?

Your myopic complaints do nothing to further your own goals - rather than make baseless accusations, look into the problems yourself and try to solve them. You might get some career growth out of it. At the very least you'll understand that not all problems can be solved with code.

> One on one meetings are not "creepy"

Actually, who decides this, and how?

I mean, I understand why 1:1 are considered necessary, but I still get the creepy vibe. It's probably mostly my introversion speaking, but this is honestly how I feel about it.

> conversation about your goals; your concerns; and anything else that needs to be discussed about your career

What goals exactly? We do sprint planning every spring, plus all that backlog refinement and other stuff.

Long-term goals? Well, they don't change that often (that's what "long-term" means). Neither does my career. So having this kind of debate once or twice a year would be quite enough.

The two people in the meeting decide it. I'm sure if either of them are creepy then you will end up with a creepy meeting. Otherwise it's just a professional meeting with an agenda and a desired outcome, like any other.

If you have no goals that's your failing, not the meeting's. If you lack the imagination to see where you want your career to go or the introspection to see where it's headed then, again, your fault - not the meeting.

Questions I get in my one on one's with people who care and are going places: -Why is the organization failing at x/y/z? How can I make that better? Is it worth fixing? -I am having trouble accomplishing e/f/g goal - I've hit q/r/s roadblock. What do you recommend I do about this? -I want your job, how can I change what I am doing to get me closer to what you do?

I also use them to get information I need from these people: -How is your team doing? Is anyone under/overvalued? -Are your commitments on track? -Is there anything I can do to make you or your team more effective?

I mostly have these meetings monthly. A month is long enough for things to change. 6 months is too long - too many things have changed, too many have been forgotten.

I feel the exact opposite, as a dev I don’t want to have to explain why my team’s work takes time, why we can’t do 50 things at once, and why we have to set priorities to the product teams or external stakeholders, I just want to write code. The engineering manager should enable the engineers to not have to get distracted by all the organizational chaos around them, their entire focus should be on developer productivity.

I've never seen any team where Senior Dev / Tech lead have had any power to make "arch level" decisions. And I have a very hard time imagining a team where the other junior/mid level engineers would accept to have such decisions made over their heads, by a member of the team.

Well, that’s how we do it. Senior devs make arch level decisions (how could you expect ownership otherwise?). It’s also not made over others’ heads but by involving them in the discussion, hearing their input.