A lot of talk about managing focuses on "decisionmaking": how to run decision meetings, who gets to sign off on what, how they flow up + down the hierarchy...

But IMO, management isn't (mainly) about decisions; it's about understanding and tweaking a complex system (of people).

Most individual A-vs-B(-vs-etc) decisions don't matter much in some sense. First because most decisions are reversible, so low-stakes. Second because making a decision is often straightforward: think about the pros and cons; think about what you care about; take your best shot.

But that framing only applies when you're at a pivotal point where you need a specific A-vs-B decision. It's not a good fit for most work, because most work happens as a result of the accumulation of thousands of micro-decisions continuously sprayed from the decision firehose.

My preferred framing is:
- Your org is a complicated system with lots of moving + interacting parts, self-amplifying/self-limiting control loops, etc. (a la lethain.com/systems-thinking/);
- Your job is to (1) implement some control loops, (2) be a debugger / technician on the system.

That means stuff like:
- Exerting backpressure (
) when your team is overloaded. "Cool idea! You can see our current priorities at this link; let me know if you think we should deprioritize anything to make room for this."

- Noticing what's bottlenecking work flowing through the system. "This project is moving slowly because it's being worked on by 2 teams that keep getting blocked on each other, because we drew the team boundary in a bad place, because..."

- Orienting: maintaining and sharing a (fuzzy) notion of the end state you're trying to get to, and making sure current work is heading towards it, not away. "We know we'll need to host outside the cloud soon, so let's choose a datastore we can run on-prem here..."

- Noticing misaligned incentives. "Our perf review process requires demonstrated 'ability to innovate' to make Senior, and it seems like the committees interpret this as 'building a new service.' Would we have less of a problem of too many microservices if we broadened it?"

Some of these have a decision point at the end, but by the time you've framed it as a crisp decision, the answer's often straightforward. But you also have to get there in the first place—observing, conceptualizing, choosing where to intervene, etc. That's often the harder part!