Aim high, but aim with purpose
There's nothing wrong with ambitious technology.
The problem is technology that aims high without knowing what it's aiming at.
Thoughts on architecture, technical direction, and the value of shared decision records.
View All TagsThere's nothing wrong with ambitious technology.
The problem is technology that aims high without knowing what it's aiming at.
When you cut documentation, then testing, then even refactoring, you think you get back to schedule. In reality, you just doomed your project and not even know about it.
Microservices were misunderstood from the moment the pattern came to light. It was rarely about the scale of the tech and throughput of services, rather then the scale of the enterprises around the products. It supposed to scale the organization.
Modular monoliths have a resurgence after the craze of the microservices era. Hype happens, then the tech finally finds its place. Don't follow fashion, be honest what your team can actually deliver and maintain.
I designed the Tech North Star packages around specific level of complexity. Industry wasn't enough, scale became a driving dimension.
A Tech North Star isn't a bunch of documentation files. It's a velocity multiplier for your organization.
"I don't need this — I can just ask ChatGPT to generate the architecture."
I hear this a lot. And it's true: any LLM can produce a C4 diagram in seconds. But always, there is a catch.
I didn't expect when building these packages, the hardest part was deciding what not to include.
Multiple client executives asked me before: "your code seems don't have much documentation, why not follow the best practices?"
My most memorable feedback was never about my tech skills. It was my bridging of business and tech that gave me a superpower.
We all believe we know our architecture's drawbacks and we anticipate their costs. But we, the CTOs are almost always wrong and too optimistic. Hence we find our architecture's issues when it is already too expensive to fix.
The most exhausting part of being an architect is running endless alignment workshops repeatedly until your voice cracks and nose bleeds.
The gap between "senior engineer" and "principal engineer" is the scale of influence.
Unpopular opinion: most architecture diagrams in enterprise companies are theatre. While my system diagrams usually live on the team rooms' whiteboards for years.
I almost didn't build this lifesaver.
For years, every time I joined a new engagement, I rebuilt the same architecture artefacts from scratch. C4 diagrams. ADRs. Cost breakdowns. Security layers.
Most engineering teams think documentation is a tax they pay at the end of a project.
It's actually a multiplier lever they're giving up at the start.
Most digital projects fail because nobody shares the same mental image in the team. I would argue this is the only problem that kills more projects and budgets than any other out there.