The military also has a peculiar behavior of punishing leadership for failures instead of promoting them or giving them a golden parachute. Telling engineers to fulfill the expectations of their managers is more of survival advice.

Granted this does not hold for 1) small startups where everyone has influence on the direction of the product and bureaucracy hasn't taken hold yet, and 2) FAANGS for the most part appear to operate under military like organization and allow for IC's to make decisions without 12 levels of approval.

The US Army in WWII is known for moving and reassigning top ranking generals - failure was more a case of "you failed at amphibious landings in Pacific but now go do Air cover in Europe."

But in general I feel if you want people to take risks for you, it's best that you pay them so much they stop having worries at home and just have worries at work. Executing people for failure looks like it gets results, but often it just gets results hidden

As opposed to execs getting rewarded no matter what so they can be open about their failures that they won’t resolve.

There is a point to not executing people for failures so that information isn’t hidden but when “not getting paid massive amounts of compensation” is equivalent to execution I think you’re going to have the same bad behaviors.

Uh... Fulfilling expectations has nothing to do with making decisions on your own.

I can guarantee you that no matter how good or bad their manager, if you don't meet their expectations, you are in trouble. By all means, own your local decisions, be proactive, keep your manager in the loop - AND MAKE SURE THEIR EXPECTATIONS AND YOUR WORK MATCH. That doesn't mean waiting for requirements, but that means your manager knows what you do and agrees, at least in broad strokes.

Surprising your manager unpleasantly never leads to good outcomes for you. There's only one person holding power in that relationship. (Positive surprises do work, but they usually take the form of "I did what you expected, AND".)

Totally agreed that the 1-2 days in the future thing is wrong. As a senior you should be at least a couple of weeks in the future, better if it's months. At the staff level, 6-12 months. At the principal level, 2-5 years.

If it's just a few days between each level, a) somebody is failing at their job, and b) yes, information will be outdated by the time it reaches you.

> Surprising your manager unpleasantly never leads to good outcomes for you...

Not quite 'my' manager directly, but a client's PM. They had a ... PM/PO type person who was quite insistent that we had to have feature X by date Y. Slightly aggressive, but... sure. Between that insistence (over weeks) and the date Y... that person left and a new person started.

4 days before a walk through (where new items were demonstrated to stakeholders, and company owners), I sent the completed functionality over to the new PM (he'd been there a few weeks, but obviously still... new). "looks good" he replied. I checked that he'd at least watched the video I'd sent over.

Demo happens and I show the functionality, with the "this is vital to have" from the previous PM. Silence. Then "we didn't know that was being worked on". Behind the scenes I was somewhat thrown under the bus, even though I had jira tickets, paper trail, video evidence and assorted other info. "Lowercased is ... subverting the process" and I made a whole team look bad. Even though... they all had signed off on what I was delivering. But behind the scenes, new PM had told people "feature X won't happen" (i have no idea why that was said) but apparently I made a lot of people look bad, because I'd delivered something they said wasn't going to happen.

So so so weird...

Well, yes. Shitty management still exists. And the power imbalance is always there. I'm not saying not surprising your manager guarantees good outcomes, I'm just saying surprising them guarantees bad outcomes.

The lesson I've drawn for myself from similar incidents is "know all the stakeholders, and talk to them". Consulting/client work makes it extra hard, because stakeholders just keep coming out of the woodwork :(

I'm not sure how much more I could have communicated. "Feature X is done and i'm going to show it on thursday". "OK looks good".

Behind the scenes, without telling me, telling other stakeholders "feature X is not being done".

Demo feature X.

"Whoah, you really blindsided us and made people look like they don't know what they're doing".

Had this been, say, 5 weeks ahead of time, yeah, maybe. This was ... 3 days? Monday afternoon to Thursday afternoon - maybe you could count that as 4.

This had grown to the point where I wasn't allowed to directly talk to the major stakeholders. This demo meeting was the time to talk to them, for a dog and pony show only. 18 months earlier we had more regular (still in a group) communication, but it was possible to talk directly. As this grew, my own ability to talk directly to people was layered with middlemen, which exacerbated this sort of problem (had happened before, but never for something this 'important').

What's... funny about all this is that the earlier PM had made this feature of paramount important, but it turns out ... no one is using it.

EDIT: both at the time, and now, I looked at it as "mistake". we're human and things happen. but it was framed as "lowercased was hiding information, working in secret". this was not the case.

The power imbalance fascinates me - why should it exist at all?

Do as I say or else? Why not, credible mission, great story telling, compelling vision, a well argued rationale.

I mean. If we paid everyone UBI, then every compmay would look a lot like the Linux Kernel (insert preferred less shouty FOSS project here)

Because communication is inefficient.

If you have to produce a well-reasoned argument, and successfully convince all peers that your argument is in fact well-reasoned, and comprehensive, and handles all concerns of all involved or potentially involved, and that all opposing arguments do not meet these criteria… it will take ages to get all stakeholders in agreement, and even when you do, you get a horse designed by committee (a camel).

Projects with no owner consistently end up in the same rut — always planning but never doing. Bikeshedding.

So you need the owner. But for someone to own the project/task, he needs to be in charge of it — he needs power. For what is power if not the ability to make a decision and have others follow through on it?

In arenas without defined power relationships, but manage to produce useful work, it’s usually the case that the power relationships still exist; they’ve just been made implicit. You see this in geopolitics, in your high school group projects, in Valve, etc. Determined not by corporate hierarchy, but instead charisma, money, social networks, physical/military strength, etc. Most of which is reflected by the corporate hierarchy anyways.

Businesses just make it explicit, and consider it valuable enough to attach higher pay. You might make the argument that managers don’t deserve higher pay than an individual contributor, but it’s clear enough that a manager has much higher potential impact than an IC — if you manage 100 resources, making them 10% more efficient than otherwise, you’re doing the effective work of 10 ICs. But in my head, a resource-managers role is primarily to make his team more efficient — by optimizing processes, clearing blockers, umbrella’ing against shit from on high, reporting upwards, to guide the overall direction of all involved — not to dictate the every individual activities of his underlings.

Also the Linux Kernel clearly has a power hierarchy, and while that power hierarchy doesn’t dictate what you work on, it does dictate whether your work can hold any value (by getting included into mainline). The difference just ends up being in the fact that it really doesn’t cost anyone anything for you to continuously do work that’s ultimately rejected every time, whereas for a business it obviously does (in the format of your salary). Obviously you can fork if you want and make it perhaps valuable… but you can exit the hierarchy just as well in business by quitting.

> You might make the argument that managers don’t deserve higher pay than an individual contributor, but it’s clear enough that a manager has much higher potential impact than an IC — if you manage 100 resources, making them 10% more efficient than otherwise, you’re doing the effective work of 10 ICs

Maybe. Supply and demand is always at play. If any manager can make 100 developers more 10% more efficient, but only a few people who have any ability to be a developer at all, then the developers are worth more. Numbers are relative to supply - my company has discovered we have to get ICs better raises than their manager at the lower levels as our great developers were becoming managers. We can get managers from lots of different entry level areas, but not enough engineers.

> If any manager can make 100 developers more 10% more efficient, but only a few people who have any ability to be a developer at all, then the developers are worth more.

Then you'd expect fewer developers, and fewer managers overall. Unless you hit some really low threshold (e.g. 5 developers, so the same manager is only worth 50% an IC) where the cost of manager doesn't "pay back" in developer-headcount-reduction, it'd still follow the same strategy.

And of course, the amount of "pay-back" you get from a manager would naturally be how one derives their value, and thus their paycheck.

But IC --> Manager as the only promotion track is completely unnecessary, and generally a mistake. That's just intentionally driving into the peter principle (promoted to the level of their incompetence), because you've simply left no other way to go. Usually you have the alternate track for IC's expanding into larger/more abstract/more important domains, but not head-count; technical/solution architects and what-not.

But the story hasn't changed -- if you assume the role of the manager is to make their resources more efficient, then a manager's value scales with the number of resources under him; an IC does not. It will always eventually make sense for a manager to be more valuable than an IC, and this only holds false at low headcounts.

I mean... if you get your managers "from lots of different entry level areas", then you get exactly what you paid for.

Any tech manager even remotely worth their salt should be able to function as a senior+ IC if necessary. If that skillset is lacking.. maybe you want to rethink your hiring. You'll likely never see the effect of a good manager if you don't.

As for your argument that developer scarcity somehow makes managing worth less - the opposite. If you can hire a single person that can effectively give you 10+ devs without having to hire those 10+ devs, you want to hire that person.

And for the "ICs need better raises, or they turn managers" - uh, no. But you do need to offer parallel development tracks, with comparable advancement opportunities. (In reality, IC & mgr raises should be roughly similar in terms of percentages. If you value managers, at least)

Management is not related at all to tech ability and there is no reason for a manager to have tech knowledge. Tech knowledge avoids some of the worst things i've had managers do, but my best managers have been completely non technical.

Edit on the above: I am coming across way more negative than I planned. I just want to counter-balance the underlying assumptions that a workplace is somehow fair, or has your interests at heart. They are collectively controlling ~50% of GDP resource allocation, they are effective dictatorships for the executive "class" and perfect competition that would keep them in line is rare in most industries.

Perhaps I am saying that changing the game is better for everyone than learning to play the current one well.

> Talk to your users. Find a way to identify them and get feedback from them. Keep your manager in the loop sure. But don't wait for requirements to come down from on high.

As a senior engineer that is what my manager expects me to do. In fact I'm often expected to define the requirements before working on them. Often when I get the requirements refined enough I hand them off to other engineers.

Of course there is personality involved here. I pass things off before I don't enjoy the boring grunt work of putting the final polish on, but I work with people who prefer to put the polish on an already solved problem. This is a win-win as both of us avoid things we don't like. (note, putting polish on is at least 90% of the work, so I can't completely get out of that, and junior engineers never can). There are other problems that other senior engineers work on that I never touch - they are the experts not me

>"Ensure that you are fulfilling the expectations of your manager"

"Just tell me what to do" is like the anti-senior developer philosophy, particularly if you report to someone who is non-tech.

If you're senior you should be the one setting the expectations and lay out a (working) plan to fulfill them.

> The US military tries hard to put decision making at the front line where it is most up to date.

Business leaders love to imitate the military, but isnt it ironic they are emulating the institution that has the most government involvement and central planning?

In terms of how it’s supposed to be structured the military is heavily centralized but that model has broken down considerably as the US has had to face far more dynamic adversaries than before. It’s a popular perception but most groups in the military branches operate a lot closer to Silicon Valley in many respects than people give them credit for.

On the surface level it should make sense bc in war stakes are high so you’d think “survival of the fittest” would apply. In reality I’d say it’s far from being the case but it makes suits feel more important so here we go again