>>If you're a manager, managing 50 people.

How does that even happen? I work at a large corporation and our goal is to never ever have teams larger than 8, with 6 being the optimal size. I'm currently managing 5 people and it's already hard work, I can't imagine managing 50.

It often means that your manager is doing nothing but the administration around management, and your team leads are pseudo-managers.

There are three forms of management: The team lead as manager, the manager that has 2-4 teams and is responsible for communication flow in the system, and the pure administrative manager overseeing a community of developers that are self-managing.

I hate the pure administrative manager model.

Sometimes it's a deliberate policy; Engines of Democracy[0] is about an aircraft engine plant with 170 employees and 1 manager.

[0] https://www.fastcompany.com/37815/engines-democracy

It could be that the original poster was literal, but more likely it is that the person has 50 people total under them. So there are 8 teams of 5 people, each with their own manager, and while the managers are direct reports, likely all of them are considered to be managed by the original poster. A good higher-level manager likes to maintain contact and stay involved with everyone underneath them, probably weighted by the seniority of the individuals.

> How does that even happen?

Very badly

So you value them, right? You must have evidence that they work obviously, would you mind sharing some examples of that? If your company didn't have this policy on goals, would you introduce one?

I hate them as a head of Engineering at 2 startups that scaled until the moment when the CEO decided that we needed to set OKRs for people.

Software eng. Teams objectives are basically to build the stuff that goes in the backlog. If it's not in the backlog, it wont happen. Developers are always in a rush to finalize whatever is in the backlog so theres seldomly time to pay the technical debt required to "improve " So the OKRs y started using was: we are going to build the shit that product throws at us plus the fires that Customer support throws at us plus whatever stupid thing Sales promised to the next large customer to close the deal.

Whenever business things that performance, security or availability are features that need to be improved, they'll put it in the backlog.

Sorry, I'm bitter.

I've always had the same problem. I'd say it's even worse. Suppose I set as a goal that I want to add a hypermegaML module to the production system to increase company profits 1000%. As you say, that only works if it gets into the backlog. BUT how the heck do I know I'll be the one who picks up the requisite tickets? It's a scrum team, we all pick up the next ticket. Work isn't dedicated for one person or another.

So now my teammates bob and Joanna are the ones who executed the hypermegaML module that increased company profits.

And there should be some degree of flexibility. If a new unplanned but important project comes up, you don't want to say "Nope, can't help it's not on the list" even if everyone else agree this should be your priority. (Or you're told to do it and then are dinged because you didn't meet your goals.)

In general, having a set of agreed-upon goals/priorities works for me so long as they're not being rigidly followed past the point where they make sense.

Yeah this is why we end up setting goals for our teams that are generic, like “respond to production issues within one business day”.

Not the dev’s fault if the big Q3 feature they were supposed to work on gets deprioritized in Q2 or some important customer cancels for an unrelated reason and their goal was to get the customer live.

Yes, you can redefine goals as things change, but at a certain point it adds a lot of overhead and the goals just turn in to “your job”.

There’s probably some happy medium between super-generic and super-specific in many cases.