TODO
]]>The problem is technology that aims high without knowing what it's aiming at.
I've seen it on a dozen engagements: a talented team, a genuinely sophisticated architecture, and no clear connection between what they're building and what the business needs to achieve. Event-driven, cloud-native, highly scalable, all the nice sounding, impressive adjectives.
And produces no revenue at all, costs a fortune to build. Or solves a problem that the market doesn't have, never validated, or outright rejected. Then act surprised when the project is shut down and abandoned.
Technology was never the goal, it's a means to an end only.
When the business need and the technical direction aren't connected explicitly, in writing, in a shared place the whole team can see, this is when you get drift. The product builds towards elegance instead of outcomes, features instead of solutions. Infrastructure spend climbs while features that don't matter get polished. The things that do matter get deprioritised because they're less interesting. So human, focus is hard, keeping direction wins but masquarades unsexy in press releases.
A Tech North Star actually forces the connection between business and tech. It starts from business context — what does this system exist to do, for whom, under what constraints and works inward to the technical decisions. It connects for non-techies too.
Ambitious technology can be valuable on its own, but usually not economically.
Without that connection, you're spending real money going in the wrong direction to get to nowhere fast. As a leader, you are responsible for the direction. Get the help of my Tech North Stars.
(P.S. when the business becomes the technology itself, you get the bubbles like dotcom and genAI. Valuations divorced from reality.)
]]>I've heard this defended as pragmatism. "We'll write it up afterwards." "The code is the documentation." "We can add tests in the next sprint."
Afterwards never comes. You just took a loan with unknown interest that you pay every day until it buries your organization.
And here is how I push back: dropping tests is a pain You feel within weeks. Bugs surface, on a stakeholder's phone right on the demo. Regressions appear, users get angry and drop the app. The team notices falling KPIs and eventually pushes back, too late though.
Dropping the documentation is invisible at first. There's no immediate feedback loop for it, the system continues to work, velocity may seem stagnant too. The sprint still closes, nobody raises a flag, retros are calm.
And the cost accumulates silently. Every new engineer who joins spends weeks decoding decisions that took hours to make. Every senior engineer asked "why did we do it this way?" answers from memory, and differently each time. Every stakeholder who asks for a system overview gets a two-hour whiteboard session instead of a one-page document. Trade-offs hide in minds unspoken.
Six months later the team is 30% slower and nobody can point to why. Retros are livid but nothing seems to work to correct.
Tests protected you from breaking what worked and now you have a hole in that guardrail. Documentation protected you from forgetting why it worked and now you repeat embarrasing mistakes.
Both matter. But only one of them bleeds quietly. Don't forget, you still pay its interest anyway.
Start with my Tech North Star packages, so the quiet bleeding never happens.
]]>Bear with me a little bit, either if you are a microservice-enthusiasts or a hater. Each pattern and tech has its places.
At enterprise scale — multiple tribes, year-long programmes, regulatory constraints, teams across time zones — the bottleneck is never the database query, the API response time or the UX animation length. It's the organisational impulse, the weight of the moving whole. It's the three teams waiting on a single integrator team's API. It's the cross-cutting change that requires a six-week coordination window among 7 squads. (Be real, they are just departments with fancier names at this point.) Or the service that nobody owns fully but everyone depends on, long forgotten who made it, long left the building anyway.
Microservices at this scale work great when they're designed to scale the organisation.
Because it is faster to create small functional things in isolation than use and modify slightly something else that a thousand paying customer relies on daily.
For example, you might have three notification services. One for transactional emails. One for regulatory communications. One for marketing. They overlap. They're not DRY. They might be in three different languages, with different coding standards. And that's fine. Actually even desireable.
Each one is small enough for a single person even to own completely, modify quickly, and ship without coordination. Or anyone to pick up quickly, as to read a couple dozen lines in minutes and you can confidently modify with a good enough test harness around it.
And if you need a fourth — for a new channel, a new regulatory requirement — you write it and deploy it in a sprint. You don't refactor a shared service that three other teams depend on. That a nightly obscure job calls every so often and somehow holds up half the revenue in last quarter. You never mess with something that works.
But you build next to it. This is micro-efficiency over macro-efficiency. Building each service locally, is inefficient. The organisation globally becomes fast just for this reason!
My enterprise-scale Tech North Star package is built around just the right approach for this: choreographed microservices — event stream based, not orchestration — so no single service becomes the bottleneck that the whole programme waits on. No single fault point to bring down the entire revenue stream overnight.
It's not the architecture that looks cleanest in a diagram. It's the one that survives contact with two hundred engineers and a five-year operational horizon.
]]>My medium-scale Tech North Star is built around this pattern — and its returning context: a core banking system, a complex end-user application in automotive, systems that need to integrate a dozen or so legacy calls and still let a team of twenty-ish people ship independently and fast.
That is harder to achieve than it sounds. The urge to scale up too early, especially for ambitious leaders to show off how they manage headcount, instead of how they succeed with less.
Just as microservices sound like the answer here. At this scale, with this team size, lacking the platform engineering enabling the real work, its just creates a distributed monolith — all the coordination overhead, none of the macro-efficiency.
A well-designed modular monolith gives you:
The package includes C4 diagrams at every level, decision records for the key integration choices, and a team structure recommendation that maps module ownership to squad boundaries.
You don't need to go distributed to go fast. You need to go reasonably modular.
]]>I have seen widly different mistakes at different scales of the client, product or organization.
A small-scale system — a few engineers, a few weeks — doesn't need microservices. If you hand that team an enterprise architecture package and ask them to adapt it, they'll spend more time stripping out what doesn't apply than building the thing in the first place. The overhead becomes the project, and you can kiss goodbye to your investment.
An enterprise-scale system — multiple squads, year-long horizon, regulated environment — can't be solved at the module level. A single-service design is fine as far as it goes. Monoliths can be easily successful too. But it doesn't show you the system boundaries, the data flows, the regulatory touchpoints. It answers the wrong scaling problem, your scale is at the organization, not at the product or even the users.
The complexity tier you are at determines where you want to go and how you get there. My Tech North Star packages take these into account.
Pick too simple: you'll outgrow it before you ship meaningfully. Pick too complex: you'll spend your budget on scaffolding.
Each OTF Tech North Star package is calibrated to a specific scope. Not one-size-fits-all. The right skeleton for the right engagement.
]]>Imagine a supertanker, fully loaded, engines running at full capacity, sailing the ocean, loaded to the brim.
Now imagine changing course every few days, or even hours.
It doesn't matter how powerful the engines are. Every course correction costs speed, time, and fuel. The ship never reaches its full velocity because it's always in the middle of turning.
That's what happens to engineering teams without a shared architectural direction. Their momentum is shattered, then you ask why they are not delivering. Then throwing more money or resources onto the problem that never had a solution in those areas.
Each new senior hire arrives with their own opinions. Each quarter brings a new strategic priority. Each undocumented decision becomes a revisited argument. The team is capable. The engines are running. But you're always turning, turning and turning.
A Tech North Star doesn't lock your direction forever, but gives a good sense and a narrower arc to turn in. It records why you chose this one — so when circumstances change, you change the decision based on updated facts, not because someone new in the room has a different instinct.
Teams with a Tech North Star move faster because they stop losing momentum to realignment and finally they build the directional momentum that translates to their velocity.
Tech North Stars require real leadership, making the calls for trade-offs. But the compounding return makes it worthwhile to invest.
Start from one that already holds course: technorthstars.hu.
]]>I hear this a lot. And it's true: any LLM can produce a C4 diagram in seconds. But always, there is a catch.
Here's what it can't do:
It doesn't know that your team tried microservices eighteen months ago and burned six months on service mesh complexity before reverting to a modular monolith.
It doesn't know that your regulator flagged a specific data residency concern that ruled out three otherwise obvious vendor choices.
It doesn't know that your lead architect is leaving in Q2 and you need decisions externalised before institutional knowledge walks out the door.
And it doesn't tell you to which context to add, which is irrelevant.
An LLM generates plausible structure with other people's decision inherited and not even spelled out.
An ADR records your decision, with your constraints, for your future team.
The value of a Tech North Star isn't the diagram or the nice slides. It's the reasoning behind it — human-authored, context-specific, and designed to guide the next decision.
Use the LLM to move faster inside the structure. Don't use it to avoid creating a structure.
The structure, written by a human who has had to live with the decisions: technorthstars.hu.
]]>Every package I've ever built in a real engagement is 40% universal things and 60% specific to that company, that team, that regulatory context.
The temptation was to include every dimension. Show all the work, the pieces to fit to any project you can have. Pack in every variant.
But that would have been useless.
What you actually need is the skeleton that's always right — and the space to fill in what makes your situation unique.
So every one of my Tech North Star packages is deliberately incomplete in the right places. The structure is there. The trade-offs are documented. The blanks are clearly labelled blanks.
That's not a bug, that's the feature you need.
Architecture that can't be adapted to reality isn't architecture. It's a day-dream dressed in diagrams and tech jargon.
]]>Well, best practices have context where they work best. My approach is always a self-describing code. Comments are only for the why, the decisions the code doesn't capture and the occasional exceptional implementations.
And I rarely had not enough time to document due to my focus on what matters. However most of their teams, peer engineers said "We don't have time to document." I get it. But after 20+ projects, the same pattern returns.
Those who say they don't have time to document are actually the ones re-litigating decisions on review boards that were made weeks ago, spending another three hours of everyones time. Then another engineer is about to onboard and the dance starts again.
Why we use that stack? Why not a different one? While the users still can't log-in to their account in an embarassing ratio.
The right documentation doesn't waste time or prolong a project. It recovers the time tax you already pay anyway, just hides in your calendar under meetings.
Then I get a different answer sometimes: "We already have the architecture diagrams."
Great. But they you look and those didn't explain the why. They are not even accurate anymore, the code diverged long ago. A new engineer reads the doc, looks at the code and then codes the wrong solution confused by the two worlds, trapped by trade-offs undocumented, repeating mistakes that shouldn't have been repeated.
If you fix these problems, congratulations, you finally got a viable Tech North Star. A documentation that doesn't just tell what is now, but gives a plan how to go ahead and where are you going. That worth all their efforts.
However, given a boxed version, you would say: "But we build our own North Star."
And yes, you absolutely have to. But do you know what goes in to one and how to structure for effect? A Tech North Star no-one buys into or confused by can even damage ongoing or future projects.
Take my package as a starting point. Keep the structure, adapt the content to your context. Throw away what doesn't fit your organization. Wisdom is human.
But the package gets you to "good enough to build on" in days, not months.
]]>And it was about what happened in the room.
"You can connect engineering and business world, you have huge experience and great people skills. Best experience that you entered our project and calmly got it back on track. At the time I could not imagine myself doing that."
— Roland Sz., senior data engineer
That's the thing I keep trying to bottle, the spark to capture so you too can wield it.
Not the C4 diagrams. Not the ADRs. Not the cost model. Those are important but the key lies in between them.
The moment when someone who thought they couldn't do it realises they can — because they finally have the structure to think clearly and communicate at the right level.
My Tech North Star packages are my best attempt at making that transferable to any engineer, heck even to any digital expert, they are understandable for non-techies too.
The frameworks are included. The structure is built. The blanks are clearly labelled to fill in.
You bring the context and you lead the room with better judgement. Not much to wait for the first drop.
]]>A missed security control at design time costs tens of thousands of EUR in remediation. A misaligned system boundary costs six months of rework. An undocumented decision shows only at a key engineer's departure, with institutional knowledge you can't recover.
These were always foreseeable, only if you had a baseline to compare against. A burger at McD's is same all over the world and you can rely on its quality because of a baseline all worker has to follow, a checklist each has at their stations.
As a CTO, you have so many topics, don't you think you need one of those tailored to your job? But all so unique. Content-wise you are right. Structure-wise however...
My Tech North Star packages give you, the executives a validated reference architecture — not a theoretical framework you put to the drawer a day after download. These are real patterns built from real delivery programmes I delivered — so you can benchmark your current state and spot gaps before any of them become a crises.
Customize to your organization and situation in days. Not months and after ludicrous consulting fees. Only an afternoon to orient, a week at most to adapt to your situation.
Then confidently walk into any architecture review with C4 diagrams, ADRs, and cost-of-ownership analysis your board and auditors already understand.
]]>And not even in the same team, that is a whole another pain. Now I talk about the repeated rythm of engagements with new clients, every quarter of half year you switch to another one, doing the same dance.
You know what you need to build. You know the right structure, you did it ten times. But every new engagement, every new team, every new CTO — you start from a blank Confluence page or a blank Miro board with dozens of opinions around you.
That's months of work before you can do the interesting part. You know, the unsexy alignment, the let's figure out how we build before we even know what we build.
OTF Tech North Stars exist to give you the skeleton so you can focus on the real meat right out the door.
Pre-built C4 diagrams. Pre-formatted ADRs. Cost-of-ownership breakdowns ready for a board deck. Security architecture already framed. Business Continuity planned and ready to practice.
You bring the context. The structure is already there. Forget the grunt work of formatting diagrams. Finally you have the bandwidth to think one step ahead of the business and truly shape a successful engagement.
]]>Senior engineers focus on a part, hopefully vertical value more closer to the target userbase. Principal engineers focus on the big picture and how the ecosystem fits, how regulation, safety, security, reliability and team capability influences the outcome.
And they translate to decision makers above - how each dimension impacts the business and propose to change effective levers.
Most senior engineer I've worked with who hit a ceiling had the same pattern:
What changed for the ones who broke through was their mindset: derive business impact of your solution.
Then simplify it to the core of the decision the leaders, executives need to follow. Raise the view to bird's eye - using C4 it is in your veins - and show the trade-offs leaders can reason about.
I got non-tech consulting partners to understand complex systems just by the right few boxes drawn on the second day I joined onto a programme running for half a year - they never understood what they built until then.
Next, learn to write and ADR any stakeholder could actually read and argue with. The decision is rarely about a tech anyway, it is about their trade-offs. Any leader worth their compensation can reason about trade-offs.
Finally, connect a technical decision to a cost line item or a regulatory risk.
Client wants a complex push notification back-off system to not annoy the user. Show the cost while the basic product functionality is not working and they thank you for the insight. Project saved.
That's the jump. From "great developer" to "the engineer who changes the outcome".
At one of my clients, the C4 component diagram I drew on their team room's whiteboard stayed there for a year after I left. It was so useful for them, they didn't want to clear the expensive, large space to use it for anything else.
The OTF Tech North Star packages are the exact treasure trove to teach you this structure, by real examples. Study how a principal engineer thinks then apply it to your own situation. You won't regret it.
]]>Those enterprise diagrams are not wrong, exactly. They're just designed to impress in a review, not to guide a team.
They get drawn once. They live on a Confluence page nobody finds. They're out of date six weeks after the sprint that created them. And when a new engineer joins and asks "why did we choose this approach?" — nobody can answer.
The diagram exists. It is huge, boxes become dots on zoom out. The decision is lost. The team is confused. Each member understands it slightly differently.
Real architecture documentation does three things:
My Tech North Stars are built to do all three. Without becoming the next edition of "War and Peace".
Stay tuned, the first package is about to drop soon.
]]>For years, every time I joined a new engagement, I rebuilt the same architecture artefacts from scratch. C4 diagrams. ADRs. Cost breakdowns. Security layers.
Different industry, different company, different team — but the same skeleton underneath every time.
Banking. Ecommerce. Logistics. Even game development. Eight countries. Twenty-something projects. The patterns don't change as much as you'd think.
About a year ago I started writing down the patterns instead of just applying them. Partly for myself, partly because the engineers I work with kept saying: "I don't get it, why this decision? Why not this better one?" Partly because I built my startup as CTO, making the same decisions again, for the 21st time.
Decisions, that need their "why" and context so the team buys in and supports all the way.
Not a whiteboard full of boxes. Not a 200-page enterprise framework and endless pages no-one will read. Something they could open, understand in an afternoon, and adapt to their situation by end of week.
That's what an Off-The-shelF (OTF) Tech North Star is.
Off-the-shelf architecture packages — C4 diagrams, ADRs, cost and security angles — for the archetypes I've seen work at the scale that matches certain projects.
Not theoretical. Based on real deliveries, under real constraints, with real teams. From digital channels to full-on enterprise scale systems.
Built for the engineer who needs to stop starting from a blank page and start delivering at the level of a principal leader.
It launches in the coming weeks.
Fun fact. My system diagrams usually live on the team rooms' whiteboards for years, they are so valuable to get everyone aligned in the room. Condensed, well thought out, up-to-date blueprint is king for long running projects.
Check out what I am building for this topic at technorthstars.hu.
]]>It's actually a multiplier lever they're giving up at the start.
Here's what a proper Tech North Star contains — and what each part is worth:
C4 diagrams (Context -> Container -> Component) No complicated and cryptic UML. Not whiteboard screenshots deciphered by sages. Layered maps that let the board, product, and engineering have the same conversation without anyone translating. From bird's eye to ground floor plan, connecting context and detail.
Architecture Decision Records (ADRs) Every non-obvious choice, written down, with the "why" — not just the "what." So when the team changes or priorities shift, you argue from facts, not feelings. And you focus on decisions that matter, not on wishes and dreams individuals bring.
Cost-of-ownership analysis CapEx and OpEx laid out clearly. The thing that makes or breaks a budget conversation with a CFO. Or risk being cut when the bottom line tightens.
Security architecture Never an afterthought. Built into the baseline so auditors stop being a surprise. Data, governance, encryptions and signatures, rotation and procedures, all critical to keep operating.
Tech stack trade-offs The reasoning that lives in the architect's head, externalised. So the decision can be challenged, improved, and survived past that architect's exit.
Business Continuity Plan The risk matrix and the collection of pre-planned steps to mitigate or recover when the unlikely happens. The checklist that saves your business overnight from bankruptcy.
This is the skeleton that separates "we have a plan" from "we have alignment."
Every project I've led that didn't have this cost more and delivered less. Without exception.
As you see, the Tech North Star is much more than just tech. Stay tuned and in the next weeks I show you what it can do for your business. And release the first off-the-shelf variant.
That first variant is out soon — check out the Sales Funnel Tech North Star.
]]>CEO, Product Manager, CTO, architect, tech lead and the engineers all have a mental image about what and how they are building. But short of hours and hours of 1-on-1 communication daily, their thinking drifts away from each other.
All well intentioned, none incompetent.
Yet they argue about coding language and tech stack instead of which experiment to run with customers.
They argue about increasing headcount or optimizing processes before even understanding the goal they need reaching.
They burn the midnight oil to reach an artificial deadline instead of asking, what do we gain by it or by delaying it?
This just means they never had a shared map.
I've seen this playing out over and over again on my 20+ projects across countries, even continents. Banking, telco, automotive and logistics. Even in game dev it is always the same. No matter the industry, no matter the scale.
Decisions are revisited, causing further delays without value to show for. Scope creeps in like water through soil, drowning the project in inefficiency. Every new engineer questions foundational elements before business value was even created, further slowing down progress.
Until one day, the project gets cut, the company reorganizes, the product shelved with all cost wasted. A small document could have avoided the outcome.
A map being updated as we go fixes the alignment with rather small overhead. This is a Tech North Star, that describes the agreement in clear language, what and how do we build, and why we decide this way.
I have spent countless hours in the last 10 years building these for teams, every time with a resounding success (one of my arch diagram stayed up on a whiteboard for over a year, referenced almost daily even in stakeholder convos).
In the coming weeks, I start releasing off-the-shelf versions.
More on that soon.
Check out what I am building for this topic at technorthstars.hu.
]]>So many details you can say a digital transformation stalls on:
Easy to hide behind all of these excuses. They are all forseable from day 0, yet they end up in the post-mortem or on steerco decks months after the start of spending? Yep, always.
If so many pitfalls for a project and known ahead of time, why would you even attempt it? Market pressure, loss of market share, competitiveness, my peer companies will beat me, etc. Or just pure "let's make our org the best it can be" good intentions behind. In our modern world, there is not really a choice to go digital on as many aspects as you can.
But then how not to loose the company on the new bet? Every leader wants to be a hero, a saviour of the company, a market genius. But the most successful ones do one thing right: hedge their bets.
Take a calculated risk, prove it works on the minimum cost possible and then double down to scale it.
Choose a smaller vertical slice of your company and transform that first. A new digital sales channel while you operate all other areas. Maybe lower a little bit their operations, like 10% to move in-house talent to the new initiative. Experienced operators learning new skills will beat any new hires in DX.
Talent shortage? You need 4-5 really good people, augmented by 1-2 from the market. Hard to fail on this in a thousands of people org.
Not the right tech or architecture? Start with a Tech North Star of how it should look like in 10 years and build only the new pillar on it. Don't fall back on existing ones, keep to the new approach for the whole project, scrap or integrate afterward.
Org schema wasn't revised well? Smaller orgs are easier to shift and change before scale, learn and integrate the insights before costly office politics kick in.
Internal politics? Pushback? Easier to isolate a small team with a clear KPI/OKR for them, support them from top when they inevitable hit red-tape roadblocks. Success beats politics, hard to argue with "but it drive 20% revenue growth" in steercos.
Misalignment of stakeholders? Minimize resposnible people. 1 decision maker with budget and ownership at the same time. Bring on board the others based on success metrics, not on promises. Smaller scope makes alignment easier too.
Focus your digital transformation to a 3-4 months runs, each with tangible results. The only way for a permanent improvement of your organization.
What was the worst problem you had to face during a digital transformation?
]]>Stay with me for a second.
When 3D printing came along, there were a lot of voices it will revolutionize manufacturing. Had its mini-boom, and by today it is normalized along its natural constraints. It did revolutionize a very specific part: prototyping. But scale remains part of other, specialized processes and manufacturing develops further.
See the parallel? I think that is where genAI eventually really end up: prototyping digital products has been revolutionized. However its constraints still unknown at this point.
What is a chocolate bar? A temporary good feeling, maybe even a pinch of energy and a tickle to your brain’s happiness spots. But when you consumed it, it is gone, and costly to replenish for next round. The more you eat, the less one piece feels satisfying. And the hidden costs appear way down the line. I think now it is a perfect parallel for genAI.
It feels good to use in the moment, but the hidden costs kick like a horse way later:
I frequently use genAI myself for coding and prototyping, it can be great but I already feel the negatives on my own skin every day. I don’t think the world was ever constrained by how much code we can write.
It is indeed constrained by how costly the code is. Just code doesn’t have a linear or simple cost structure. Most of the cost is in the understanding of a problem, designing a dozen or more solution, and try them until one fits. You can automatically test if code works but can’t always test correctness.
And making code cheap now just creates a world where everyone asks only the “can I do it?”, rather we need to ask as always: “should we do it?”
]]>