Every so often, someone will come to me and ask me "Stavros, why do you not share your infinite wisdom with us?". Invariably, my answer is "because you are not paying me, and also who are you, go away", but they get me thinking. What if I did share all my wisdom with the wider world? By how many millions of times would that magnify my impact?
Over the years, many people have helped shape me into the self-made man I am today, or at least that is the polite thing to say. However, I have decided that I can get many more consulting gigs if I give people a taste of what they're buying, so I have selflessly decided to provide immense value by sharing some inconsequential morsels of my decades of experience in running companies, leading thought, and, ultimately, making the world a better place.
Morsels to me, precious nectar to you. Behold them, for your edification.
All thoughts
How architecture decisions silently set the ceiling on gross margin, and why most engineering orgs never see that number
How 'we need a data strategy' almost always means three different things to three different executives—and the technical strategist who doesn't force that disagreement into the open before writing a plan ends up authoring a document that satisfies no one
Why deprecation is a harder strategic capability to build than adoption, and why most organizations have no one whose actual job it is to decommission things
How running two major technical initiatives in parallel—say, a cloud migration and a data platform rebuild—doesn't just split engineering capacity but creates a compounding coordination tax that neither initiative's plan accounts for
The pattern where an organization's stated technical strategy says 'microservices and autonomy' but its budget approval process, change advisory board, and shared database infrastructure all enforce centralized coupling
Why the most expensive technical strategy decisions are the ones made by default in the gap between two reorgs
The strategic cost of vendor consolidation pitched purely as negotiating leverage
Why designing against a vendor's roadmap is one of the most under-scrutinized bets in technical strategy
The pattern where organizations try to solve coordination problems with architecture and architecture problems with coordination—and why misdiagnosing which one you actually have leads to expensive interventions that make things worse
Why the technical strategy that gets funded is almost never the one with the best analysis—it's the one whose sponsor understands the CFO's current anxiety
How the sunk cost of a multi-year vendor contract quietly reshapes technical strategy long after the original decision-makers have left the organization
The counterintuitive problem with engineering teams that are too good at working around platform limitations
Treating headcount reduction as an architecture event, not just a cost event
The bottleneck AI coding assistants moved rather than removed
The dangerous assumption that a successful staff-plus engineer will naturally excel at technical strategy work
The argument that your cloud chargeback model is a more powerful architecture policy than anything the architecture team publishes
The compounding cost of having no shared definition of 'production readiness' across teams
The failure mode where technical due diligence gets done rigorously before a major decision—cloud provider commitment, framework adoption, vendor contract—but the assumptions behind that diligence are never revisited even when the market, team composition, or business model shifts underneath them
How quarterly planning cycles structurally prevent technical strategy from working
The difference between not having a strategy and not following one
Examining why 'buy vs build' frameworks fail in practice because they treat the decision as a one-time evaluation rather than an ongoing portfolio problem
The pattern where organizations staff technical strategy with senior individual contributors who have deep system expertise but no organizational power, then wonder why recommendations die in committee
How organizations consistently underinvest in the ability to actually evaluate whether a technical initiative worked after it shipped
The strategic problem with 'centers of excellence' that produce guidelines nobody is structurally required to follow
Why the second system you migrate is always harder than the first, even though everyone assumes the opposite
Why the most dangerous input to a technical strategy is a reorg
The tension between running a technical strategy function that's 'embedded with the business' versus one that maintains enough independence to deliver unwelcome conclusions
The overlooked failure mode where technical strategy documents optimize for internal legibility—clean diagrams, neat swim lanes, phased roadmaps—instead of capturing the actual messy constraints that will determine success or failure
Why structural protection matters more than strategic clarity
The strategic cost of treating observability and reliability as engineering-owned concerns rather than business intelligence
The uncomfortable reality that most technology radar and tech adoption governance processes optimize for saying no to new things while doing almost nothing to force retirement of old things
The underappreciated role of technical strategy in M&A due diligence, specifically how acquiring a company with an incompatible data architecture or deeply coupled monolith can silently destroy the projected value of a deal
Challenging the assumption that platform teams automatically create leverage
How the 'align engineering with business outcomes' mantra breaks down when the business itself can't articulate stable outcomes
Why successful migrations and re-platforming efforts often make the organization worse at the next one
The way enterprise architecture diagrams become political documents rather than technical ones
How 'individually reasonable decisions' hollow out a long-term bet
The moment a technical strategy becomes unfundable—not because it's wrong, but because the organization burned its political capital and executive patience on a previous initiative that over-promised and under-delivered
The underappreciated strategic risk of having your best engineers in the wrong room
Examining why 'buy vs build' is a false binary that leads strategy teams astray—the real question is 'where does differentiation live and how long will it last
Why vendor-sponsored maturity models are strategy theater disguised as assessment
Why the most politically difficult recommendation a technical strategist makes is 'do nothing right now
Confronting the tension between executive pressure for AI integration timelines and the reality that most organizations lack the data infrastructure, governance, and evaluation frameworks to deploy AI responsibly at scale
The dangerous moment when a proof-of-concept gets accidentally promoted to production infrastructure
The strategic mistake of letting platform engineering teams operate without a clear product mandate—treating infrastructure as a cost center that 'just supports the business' instead of an internal product with users, roadmaps, and adoption metrics
The uncomfortable truth that most technical debt isn't accidental—it's the rational outcome of incentive structures that reward feature velocity over system health