[aboodman]

lol I read "as many as 15+ direct reports" and thought it was hilariously low. My manager at google had like 50+ directs in 2010. And he was the best boss I've ever had.

Popular conception of what a manager is is wildly unambitious.

Weekly 1:1 is performative and useless. It's not what makes a good manager. What makes a good manager is:

  * Having excellent domain knowledge and judgement
  * Having the respect of the team, to settle disputes
  * Solving problems when needed
  * Hiring and retaining an excellent team
  * Picking the right things to work on

... etc ...

If a manager is doing these things well I don't need a standing meeting at all. Or we can meet quarterly to check in.

Email is a thing.

[cjrp]

Interesting. I'd define all of those tasks as the job of a team/tech lead, rather than a manager. I've worked at places where the same person did both roles, and it was not always a great mix.

[seattle_spring]

If you think hiring, prioritizing, planning, and cross-team negotiation are all tasks of a tech lead and not a manager, then what is the job of an engineering manager in your opinion?

[cjrp]

IMO purely people management (1:1s, promotions, goal-setting, staffing/resourcing, involvement in hiring).

[aboodman]

But how can you know who to promote, how to balance resources, or who to hire if you're not leading the project?

People management is about managing the company's resources to achieve goals. If you are not the one leading the implementation of those goals, you are not going to be able to:

  * reason about what the right about of resources should be
  * see opportunities for optimization
  * forecast future need

You will be completely dependent on a technical lead who does have that information. So then what is your independent role? Just to shuttle information between the technical lead and others?

[aboodman]

The most common split I'm aware of is tech lead / eng mgr. The eng mgr does "people stuff" like hiring/firing and cross-org negotiation, and tech lead does "technical stuff".

But the thing is this makes no sense. Tech issues always turn into people issues - when there is a disagreement, who adjudicates? How can a manager adjudicate something they don't understand. And how will engineers respect / follow the decision?

And people issues invariably become tech issues. How can you hire the right people if you don't understand the tech? How will you know when to fire?

This setup makes no sense to me and i have very rarely seen it work. It seems like it was a product of an earlier time when there was a lot of money floating around and provided a way to (a) shield senior eng from dealing with people problem they just didn't want to, and (b) provide cushy jobs to professional managers that didn't know much about the tech.

But it doesn't work. There's no way to do the shielding well and a person with hiring/firing power needs to know what the fuck is going on.

Really good eng leaders must be both good at tech and good at people. That's the job.

[reverius42]

Median tenure at a lot of tech companies is around 18 months. If you meet quarterly with your manager, the median employee is only going to meet with their manager 6 times, total! Not to mention people change jobs, and org charts change, so even if you don't leave after 18 months your manager might. How can you build a real relationship with only 6 meetings total?

[aboodman]

Do you people only interact with your manager via 1:1? I was constantly interacting with my boss - design meetings, code reviews, product decisions, whiteboard sessions, in slack, in irc ... he was always around.

I got to know him much better through these productive interactions then awkward smalltalk in a 1:1.

And it kind of make sense to meet privately quarterly since perf reviews are also quarterly and that's the only reason I can really think of for a private scheduled face-to-face.

Of course I could always just ask for a private meeting anytime I wanted, which I guess I did from time to time. But it always for a product reason: a tough tech choice I was wrestling with or similar.

[reverius42]

I guess it depends on the culture. In a lot of work cultures those other meetings are all work, and if you are fully remote (especially while others are not)* then there's no water-cooler talk.

Plus I think the regularity/cadence of it is supposed to provide some psychological safety. Asking for a one-off meeting feels like overkill for a normal 1:1, and yet a little intimidating for the type of 1:1 that you really need to have a 1:1 for (like discussing interpersonal issues).

* I suppose if everyone's fully remote, in theory the water-cooler talk moves to Slack.

[jychang]

This is stupid and irrational. It's like seeing someone eat 100 cakes, and then assuming everyone can do it. And then getting diabetes afterwards.

It seems quite counterproductive to assume such a system would scale to everyone else, or that everyone else could possibly implement this. This is cowboy levels of human resource management, not careful engineering.

[aboodman]

I mean a branching factor of 50 vs a branching factor of 7 is a massive difference. A team of 50 can either be run by one manager and a two-level tree or like 8 managers (!!) and a three-level tree. Think about the difference in execution (and expense) in these two companies.

If you can do it w/ the first model why on earth would you not?

[jychang]

This is "Steve Jobs looking at someone on a fruit diet" and thinking "I can do it too" levels of reckless.

Hell, Dunbar's Number is 150 people, and you expect to have 50 directs? That's literally 1/3 of your 150 being occupied by directs. It seems clearly infeasible the more you think about it.

[aboodman]

I mean I have 7 reports right now and we're a startup. And fully remote. And I'm still contributing as an IC too.

[AdamN]

A manager who is also contributing code is almost an entirely different role than a manager who is not contributing code. Typically the former should not exist in a smaller org and in a larger org it makes sense to shift to the latter because there's enough non-code work to do that you might as well dedicate whole people to the task.

Different roles though.