How do your priorities as a developer materialize? Why are those the priorities? How are they decided upon? What does it take to do this?

As someone with a technical background I completely understand that feeling. You walk past someone spending three hours on a PowerPoint and think, what is actually happening here.

But here’s what I’ve come to understand. The document is rarely the work. It’s the evidence of the work.That Word doc someone spent a day on probably represents weeks of conversations, decisions, disagreements, alignments and compromises that happened before anyone opened a blank page. The document is just where all of that gets crystallised into something an organisation can act on.

Organisations don’t run on code or products alone. They run on shared understanding. And shared understanding needs to be written down, formatted, presented and communicated in ways that different kinds of people can absorb and trust.

The person making that presentation isn’t just making slides. They’re translating something complex into something a room full of people with different contexts can agree on in forty five minutes. That’s actually a really hard skill.

The other thing worth considering in most organisations decisions don’t get made because something is technically correct. They get made because someone communicated it in a way that felt credible and clear to the people holding the budget.

Engineers build the thing. But someone has to convince the organisation the thing is worth building, funding and scaling.

That’s what those Word docs and ppts are often doing. Unglamorous. Underappreciated. But genuinely load bearing