Together with our Staff Engineers and Tech Leads, we had mapped technical risks, organizational bottlenecks and initiatives worth addressing. We used the classic Eisenhower Matrix in a workshop and agreed on what was important, what was urgent and which topics we wanted to address first. The week afterwards, none of the topic were in my calender.
My calender was full of one-on-ones, job interviews, roadmap discussions, leadership weeklies, team sparrings… Most meetings had a legitimate purpose. But our agreement on what mattered had not allocated any time, people or decision-making energy to act on it.
Inside an engineering organization, priorities compete in an internal attention economy. And the work that changes the system often has a disadvantage: it crosses team boundaries, its costs and benefits are distributed, and nobody is naturally responsible for pulling all the strings together. It needs a sender.
How the internal attention economy works
An attention economy is the system through which an organization directs its finite respiprce attention: its meetings, decision-making energy, interruptions and capacity to think. The attention allocation mechanism is often tied to urgency created by a sender. Without a counterweight, it favors urgent work with a sender over work whose cost and reweards are delayed and distributed.
By sender, I do not necessarily mean a person. I mean a mechanism that makes work hard to ignore: an owner who needs a decision, a recurring forum, a document that must be updated, a review date or a commitment that someone will notice if it does not happen. Most reactive work arrives with a sender. A recruiter needs a decision because a candidate has another offer. A Tech Lead needs help with a difficult situation. Product needs a trade-off resolved before a roadmap meeting. An executive needs input for tomorrow’s presentation. Someone is waiting and that creates urgency. However, the topic that seems to have the most immediate pressure is not necessarily pointing at an important issue.
Work that is important in the long run often works differently. Redesigning ownership, developing leaders, reducing a recurring architectural risk or diagnosing why teams keep escalating the same decision rarely has one obvious owner. The problem may affect several teams. One team owns part of the architecture, another owns the platform and another experiences the customer impact. Everyone owns a piece. Nobody owns the whole. Its costs and benefits are also distributed over time. There may be no single person who can say, “I need this in a year.” That makes this kind of work less likely to win attention by default.
Reactive work is part of the job
It would be wrong, to turn this into an argument for declining meetings or ignoring Slack for any short term request. Helping a Tech Lead think through a hard situation is leadership. Supporting Product through a real trade-off is leadership. Responding quickly during an incident is leadership. Reactive work also provides useful signals. If the same ownership question keeps returning, if the same class of incident keeps interrupting teams or if the same decision needs to be escalated, t may point directly to the neccessity of more long-term changes the organization..
The problem begins when incoming urgency becomes the only way leadership attention is allocated. A calendar then reflects who asked most recently and most forcefully, rather than the combination of work that keeps the organization running and work that makes it work better.
Agreement is not allocation
The workshop taught me that a shared priority list is a weak commitment on its own. It tells people what matters, but it does not answer the harder questions:
- Who is accountable for moving this forward?
- What decision, outcome, or artifact will show that progress has been made?
- Which people have capacity to do the work?
- When will we look at it again, even if nothing is on fire?
Until those questions have answers, an important initiative is competing against a full calendar with only goodwill on its side. This is why migration weeks, architecture reviews and strategy offsites can be useful, but only when they produce follow-through. A migration week protects engineering capacity. An architecture review creates a recurring decision point. An offsite can create enough distance to identify a problem worth solving.
For more strategic work to survive, it needs a small operating system around it. In practice, that means giving each priority:
- a named owner and if needed, an executive sponsor;
- a concrete next decision or deliverable
- explicitly reserved capacity
- a review rhythm that continues until the work is completed (it does not need to be a new meeting!)
Those elements give strategic work a sender. They turn “we should improve our decision-making” into “the owner will bring a proposed decision model to the architecture forum on this date.”
Focus time is a tactic
I now protect recurring time for longer-term work and reschedule it immediately when a genuine priority displaces it. That helps. It is also not enough. A protected block does not create capacity from nowhere. It makes a trade-off visible. If leaders want room for long-term, strategic work, something else may need to be shortened, delegated, redesigned or dropped so that it no longer requires their direct involvement. If none of those choices is possible, the organization may have a capacity problem.
How to find important but not urgent topics?
One practical starting point is to look at the last month of reactive work. Which questions, escalations or approvals repeated? Which meetings existed only because a decision was not clear elsewhere? Which risks were widely acknowledged but had no owner, decision date or capacity attached? These topics deserve explicity attention. They may need a quick decision, a clearer boundary or a more long term stratic change.
Leadership is not choosing between serving the organization today and improving it for tomorrow. It is managing both. Reactive work keeps the current organization running. Strategic work changes how it runs.
Reactive work fills calenders and Slack automatically.Strategic, longterm work needsi an owner, a decision date, a forum, and capacity that someone has explicitly chosen to protect.