🔗Why I'm Writing This
Recently, I found myself in a series of frustrating discussions — not about technical feasibility or risk tradeoffs, but about political hesitation, title-driven gatekeeping, and people blocking by saying :
- “I’m not sure what problem we’re solving here.”
- “Let’s park this and revisit in the next planning cycle.”
- “That won't work for us”
- "Can you write up a detailed proposal so I will try to review if its of priority?"
And here's the thing: these weren’t blockers grounded in engineering risk or customer impact — they were social friction driven by hierarchy.
People who should have been solving the problem are instead protecting turf — slowing down the very momentum they claim to support.
A personal manifesto for anyone who’s ever tried to do the right thing, move fast, and build something real, only to be slowed by people who don’t build but still want a say.
If you’ve been architecting for future, while paying off a mountain of yesterday’s shortcuts — because somehow it all lands on your shoulders — this is for you.
🔗DO: Ship Through the Fog
You’ve been architecting for the future while carrying the weight of outdated decisions and shortcuts made over years and continuing, you already know — clarity is a myth.
The system doesn't wait for alignment. It bends to the will of those who move.
In most rooms, there’s a debate. In rare ones, there's a build. And if you're reading this, chances are you've become the person who ships while everyone else waits for approval.
You don’t need permission to clean up what others ignored. You don’t need consensus to protect long-term integrity. You just need the instinct to act — and the discipline to make it stick.
Think of architecture like progressive delivery. You don’t flip every flag at once. You isolate, you ship, you observe, and you refactor forward.
You don’t need a roadmap to move — you need an exit strategy when others stall.
🔗EPIC: Make It Heavy Enough to Matter
You’re already carrying load-bearing responsibilities — why build lightweight ideas?
Epic doesn’t mean big and shiny. It means meaningful, reusable, and unmistakably intentional.
- Build foundations, not patches.
- Design for ten teams, not just your own.
- Create things that make future engineers whisper: “Thank you for doing this the right way.”
You're not just building a sand castle — you're laying steel beams others will anchor to. It needs to hold weight, not just pass CI.
The work isn’t epic because it’s cool. It’s epic because it prevents chaos — silently, consistently, and at scale.
🔗SHIT: Don’t Let the Grind Kill Your Fire
You deal with ambiguity, institutional baggage, half-made decisions, and tech debt stacked taller than the product roadmap.
You hold the system together not because it's fun — but because someone has to. And you care enough to make sure it doesn't fall apart on your watch.
But here's the truth: If you let the weight of it all kill your spirit, they’ve won.
The game isn’t just about building systems that scale. It’s about lasting long enough to do it again — better, faster, cleaner — the next time.
You don’t need stickers and offsites to stay motivated. You need space to build, permission to move, and teammates who don’t treat velocity like a threat.
Engineering at scale isn’t romantic. It’s trench work. But it’s your trench, and no one else is coming to clean it up.
Take the work seriously. But don’t let the work take you.
🔗Don’t Let Political Noise Rewrite Your Job Description
You didn’t sign up to maintain spreadsheets of alignment. You didn’t become a builder to attend recurring syncs where nothing moves.
But here they come and just say:
- “I’m not sure what problem we’re solving here.”
- “Let’s park this and revisit in the next planning cycle.”
- “That won't work for us”
- "Can you write up a detailed proposal so I will try to review if its of priority?"
Here’s what actually what it reveals:
- They don’t understand the problem, so they stall and block instead of contributing and solving
- I want a safety net, and I’m more worried about who approves it than whether it works
- Let it die quietly so we can avoid difficult conversations, because they don't know to solve it
- Avoiding accountability under the mask of process or words they use
These are the people who should have solved it — but didn’t.
They’re like a misconfigured circuit breaker — tripping too early, blocking flow, contributing nothing to resilience.
You wouldn’t accept that in production. Don’t let it run your org.
Surround yourself with engineers who:
- Solve with urgency
- Architect with clarity
- Scale with right principles
Be kind. Be sharp. But above all — protect your velocity like uptime.
🔗Make Your Work a Signature
You don’t need a title to lead. You don’t need a charter to drive change. You just need a mindset:
- Act even when it’s uncomfortable
- Aim for problems that matter
- Ignore the noise that doesn’t ship anything
Because if you’re spending more time in syncs than in flow... If you're battling titles instead of solving bottlenecks... If you're navigating more "alignment" than architecture...
Then you're not the problem — the system is.
So keep building. Keep pushing. Keep moving forward.
I don’t chase credit. I leave behind working systems. Let them chase just fictional powerpoint claims.