5 posts tagged with "Leadership"

In software engineering, cognitive load refers to the total amount of mental effort being used in a developer's working memory to complete a task. Think of it like the RAM in a computer: if you try to run too many heavy applications at once, the system slows down, glitches, or crashes.

When a developer's cognitive load exceeds their mental capacity, productivity drops, the quality of code suffers, and the risk of burnout increases.

Somewhere in your organisation right now, an engineer wants to use a tool. It's open source. It's battle-tested. Half the Fortune 500 runs it in production. But first, they need to fill out a vendor assessment form, get InfoSec sign-off, wait for procurement to confirm there's a contract in place, and then — maybe, in four to six months — they'll get a "yes" or a "no" from a committee that's optimised for risk avoidance, not risk management.

This isn't an argument against governance. Governance matters — especially in regulated industries. This is an argument that the way most enterprises do governance today is broken: optimised for the appearance of control rather than the reality of it. The question isn't whether to govern. It's whether your governance framework is actually reducing risk — or just reducing speed.

Meanwhile, the startup down the road shipped the feature last Tuesday.

But hey, at least you've got a contract. You can sue them if things go wrong. Right?

A new project kicks off — migrating a critical system to a platform nobody on the team has used before. Well, almost nobody. There's one person who's built on it. Shipped production workloads. Knows the failure modes.

They don't get the lead. The person with the most years of experience does. The senior. The one with the title.

Everyone defers. The titled lead chairs the meetings, makes the architecture calls, approves the designs. The person who actually knows the platform sits three rows back on the call, unmuted only when asked a direct question.

Six weeks later, the project is behind. Decisions are being revisited. The team is frustrated but can't quite name why.

You've seen this movie. Maybe you've been in it. Maybe you've been on both sides.

Look, you worked hard. You stayed late. You shipped that thing nobody else could ship. You earned every single promotion, every bit of recognition, every seat at the table. It was all you. 100%. No asterisks. No footnotes. Definitely no luck involved.

Right?

You send a Slack message to another team. It's a reasonable request — a small API change, maybe a code review, maybe just a question about how their service handles edge cases. You write it clearly. You tag the right person. You even add a polite emoji. And then... nothing. No reply. No acknowledgment. Just the quiet hum of a message marked as read and promptly ignored.

You're not being ghosted because they're bad people. You're being ghosted because the game they're playing rewards ignoring you.

This isn't a people problem. It's a math problem.