The cleanest architecture I've seen was also the slowest. Twelve microservices. Proper domain boundaries. Kubernetes. Conference talk about the migration. A feature that took one day in the old monolith now took two weeks. In the corner, the ugly billing module was still

Diagnosing organisational problems surfaces politics fast. Constraints often point at sacred cows: systems built by senior engineers, processes designed by VPs, org structures the CEO created. Get air cover before you start. Without someone who can say "we're doing this

One PM told me, six months after killing their roadmap: "I used to spend 40% of my time on roadmap administration. Now I spend that time talking to customers." The roadmap was overhead. Talking to customers is the actual job.

Fresh eyes find friction faster. New engineers often see it in their first month. Then they get socialised into silence by teams that have stopped questioning inherited patterns. If a new hire asks 'why does this take so long?' - listen. They're seeing the friction you've

When engineers propose rewrites, ask two questions: 1. What gets faster? 2. What gets unblocked? If the answer is 'the code will be cleaner' - that's not friction. That's preference. If the answer is 'deploys drop from 40 minutes to 5' - that's real. Architectural purity is a

AGI is not coming. We are nowhere near AGI. What we have today is inference, not learning. Models get trained once on huge fixed datasets, then frozen. You ask questions, they remix patterns they already saw. Nothing updates. Nothing sticks. Talking to the model does not make

About to start a tech debt initiative? Stop. Don't catalog. Don't vote on severity. Don't build a backlog. Instead: look at your last quarter of work. What took longer than it should? What slipped? Where did engineers get stuck? What got de-scoped because it'd require touching

"Q4: Build new onboarding flow" is a task. "We believe improving onboarding will increase activation by 20%" is a bet. Tasks lock you into outputs. Bets let you change course when you learn something.

Planning feels productive. Shipping is productive. Different things.

"This is really well thought out. Let me discuss it with leadership and get back to you." That sentence, followed by silence, has ended more engineering tenures than bad compensation. The proposal was a test. Not of architecture. Of whether leadership would respond to 18 months

Every rewrite proposal follows the same arc. Retro feedback: noted. Backlog ticket: deprioritised. One-on-one escalation: heard. Formal proposal: rejected. Each step represents more effort from the engineer and less belief that anything will happen. By the time the proposal

Six months after the engineer left, the routing engine had a cascading failure. Eleven hours to resolve. Two hundred clients affected. In the post-mortem, a junior engineer pulled up the departed engineer's proposal. Page 14. The exact failure mode, described in detail. The fix

A senior engineer spent two weekends writing a 22-page rewrite proposal. He'd been flagging the same problems for 18 months. Retros. Tickets. Escalations. All acknowledged. All ignored. The 22 pages weren't a technical plan. They were a test of whether leadership had been

The worst state isn't an engineer proposing a rewrite. It's when nobody proposes anything structural at all. A rewrite proposal, even a bad one, means the engineer still believes things can change. When was the last time someone on your team proposed something big? If it was

11 improvement tickets. Filed over 14 months. Groomed, estimated, ready. Each one deprioritised when the next feature deadline hit. Those were the incremental alternative to the rewrite. Leadership killed the incremental path, then rejected the dramatic one too. Count the

Engineer presents a rewrite proposal. CTO asks sharp questions. Takes notes. Says "this is really well thought out, let me discuss with leadership." Two weeks of silence. Then a Slack message: "The timing is not right." Two weeks of nothing is not a neutral event. It's a