You need better questions around the ones you already have.

I learned this the annoying way...

A few years ago I was looking at engineering activity across a large product suite.

• Multiple teams.

• Multiple applications.

• Multiple managers.

• Multiple dashboards.

And a lot of green numbers.

_{Every team can be green while the system is struggling.}

• Team A looked healthy.

• Team B looked healthy.

• Team C looked healthy.

• Team D looked healthy.

• Everyone seemed busy.

• Deployments were happening.

• Pull requests were moving.

• Sprint goals were being hit.

• The dashboards looked good.

But the product suite was still struggling.

• Customers were feeling friction.

• Teams were waiting on other teams.

• Small changes took longer than expected.

• Some releases created problems somewhere else.

And nobody could point to one metric and say:

“There. That’s the problem.”

That was the moment I started looking at engineering metrics differently.

The numbers weren’t necessarily wrong.

The story we were telling ourselves about those numbers was wrong.

And that’s a much more dangerous problem.

When the number becomes the goal

This happens more often than we like to admit.

We choose a metric because we want to improve something.

Then we start managing the metric.

Then...

without noticing it...

the metric becomes the goal.

Story points are a good example.

A team completes more story points this quarter.

Everyone celebrates.

But did the product get better?

Maybe.

Maybe not.

The team could have broken work into smaller pieces.

They could have estimated differently.

They could have optimized for points instead of customer value.

The number went up.

The outcome might not have.

The same thing happens with deployment frequency.

More deployments can be great.

But more deployments can also mean more tiny changes.

Or more risky changes.

Or more rollbacks.

Or more production noise.

Cycle time can fall while teams simply push easier work through the system.

PR volume can rise while the real work gets harder.

This is basically the trap behind Goodhart’s Law:

When a measure becomes a target it can stop being a good measure.

People aren’t stupid.

They respond to incentives.

If I tell you I’m measuring something...and then judge you based on it...you’re probably gonna optimize for it.

That’s not gaming the system.

Sometimes it’s just rational behavior.

Four levels of Productivity

One reason engineering metrics get confusing is because we measure different things as if they’re the same thing.

I find it useful to think about four levels.

_{4 levels of Productivity: Activity → Output → Outcome → Impact}

This is where the conversation gets interesting.

Most engineering dashboards are strongest at the bottom.

Activity is easy to count.

Output is fairly easy to count.

Outcome is harder.

Impact is harder still.

So we end up with dashboards full of numbers because numbers are convenient...not necessarily because they’re useful.

The most dangerous metric is the one that looks reasonable

Bad metrics are easy to ignore.

If I show you a completely ridiculous metric you probably won’t trust it.

The dangerous ones are different.

They look sensible.

Deployment frequency.

Cycle time.

Lead time.

PR throughput.

Defect rate.

Change failure rate.

None of these are bad metrics.

That’s important.

The problem isn’t the metric.

The problem is believing the metric explains more than it actually does.

Imagine deployment frequency drops.

What happened?

Maybe the team slowed down.

Maybe a release process changed.

Maybe the team spent two weeks fixing a major production issue.

Maybe another team became a dependency.

Maybe the product was stable enough to need fewer deployments.

The metric tells you something moved.

It doesn’t tell you why.

And that’s the part we often skip.

We see the graph.

We tell ourselves a story.

Then we act as if the story was a fact.

Your team might not be the problem

This is where things get uncomfortable.

Sometimes a team looks slow because the system around the team is slow.

Think about everything between writing code and delivering value:

Architecture.

Approvals.

Testing.

Environments.

Security reviews.

Release processes.

Dependencies.

Legacy systems.

Shared services.

Handoffs.

Ownership boundaries.

External vendors.

Other teams.

A team can improve every metric inside its boundary...

and still make very little progress at the system level.

I’ve seen this happen.

One team optimizes its workflow.

Another team does the same.

A third team does the same.

Everyone gets locally better.

The overall product still feels slow.

Why?

Because local optimization doesn’t guarantee system improvement.

So instead of only asking:

“How productive is Team A?”

sometimes the better question is:

“What is slowing the system down?”

That’s a very different conversation.

And usually a much more useful one.

The Watermelon Effect

There’s a name for another version of this problem.

The Watermelon Effect.

Everything looks green on the outside.

But it’s red on the inside.

Imagine an IT dashboard showing green across the board.

SLAs are being met.

Servers are up.

Technology metrics look healthy.

The reports say everything is fine.

Then you talk to the people actually using the systems.

And you hear something very different.

“It’s slow.”

“I have to work around it.”

“This process wastes my time.”

“I still can’t get my work done.”

Now we have a problem.

The dashboard says green.

The experience says red.

That’s the Watermelon Effect.

Green outside. Red inside.

The metrics aren’t necessarily wrong.

They’re measuring only part of reality.

And this matters far beyond IT.

The same thing can happen inside engineering.

A team can hit its delivery target while developers are drowning in interruptions.

A platform can meet its uptime target while users struggle with poor performance.

A service can meet its SLA while employees spend hours finding workarounds.

The Watermelon Effect isn’t really a story about bad dashboards.

It’s a story about incomplete truth.

We’re looking at the outside.

Users and employees are experiencing the inside.

And the gap between those two things is where a lot of engineering problems hide.

Measure the experience too

This changed how I think about engineering productivity.

We usually talk about:

Activity → Output → Outcome → Impact

But there’s another dimension running through all four.

Experience.

People don’t experience your deployment frequency.

They experience whether the product works.

They don’t experience your uptime percentage.

They experience whether they can get their work done.

They don’t care how healthy your engineering dashboard looks if the product feels painful.

So I like thinking about this as:

Metric → Experience → Outcome → Impact

The metric is the signal.

The experience tells us what it feels like in the real world.

The outcome tells us what changed.

The impact tells us why it matters.

If those layers agree...

great.

If they don’t...

don’t hide the disagreement.

Investigate it.

That disagreement might be where the real problem is.

Should we stop measuring engineering?

No.

Please don’t throw away your dashboards because I wrote an article about dashboards.

I’ve made enough mistakes without adding that one to the list.

Metrics are useful.

They help us see trends.

They help us spot changes.

They help us compare periods.

They help us ask better questions.

The problem starts when we confuse measurement with understanding.

A metric is evidence.

It’s not an explanation.

So the question isn’t:

“Is this metric good?”

A better question is:

“What became better because this number moved?”

If you can’t answer that...

you probably need to investigate before celebrating.

Subscribe now

The Engineering Metrics Truth Audit

Here’s the simple audit I use to challenge the story behind a metric.

Take any important engineering metric.

Then ask five questions.

1. What are we actually trying to improve?

Be specific.

Not “developer productivity.”

That’s too vague.

Maybe it’s:

“Reduce the time it takes customers to complete checkout.”

Now we have something real.

2. What does this metric tell us about that?

Suppose the metric is deployment frequency.

Does more frequent deployment directly tell us checkout is improving?

Probably not.

It may be related.

But related isn’t the same as proven.

3. How could we improve the metric without improving the outcome?

This is my favorite question.

Because it forces you to attack your own metric.

Could deployment frequency increase without customers getting more value?

Yes.

Could PR volume increase without productivity improving?

Absolutely.

Could story points increase without delivering more value?

Of course.

If the answer is yes...

you’ve found a blind spot.

4. What important thing does the metric leave out?

Every metric leaves something out.

That’s normal.

The mistake is pretending it doesn’t.

Maybe your cycle-time metric ignores waiting for approval.

Maybe your defect metric ignores customer frustration.

Maybe your uptime metric ignores usability.

Maybe your delivery metric ignores business impact.

Ask what’s missing.

5. What decision will we make when the number changes?

This question is brutally practical.

If deployment frequency falls...

what will you do?

If cycle time rises...

what will you do?

If PR volume doubles...

what will you do?

If you don’t know what decision the metric should trigger...

why is it on the dashboard?

Build a better engineering dashboard

I like making this painfully simple.

For every important metric write down five things.

MetricWhat it tells usWhat it doesn’tWhat else could explain it?DecisionDeployment frequencyHow often changes are deployedWhether releases create valueSmaller changes, automation, release policyInvestigate changeCycle timeHow long work takes through the flowWhy work waitsReviews, dependencies, queues, environment issuesFind bottleneckPR volumeAmount of PR activityBusiness valueSmaller PRs, workflow changesCheck contextDefect rateNumber of reported defectsTotal user painReporting behavior, severity, exposureLook at impact

The last two columns are where the magic happens.

What else could explain it?

That’s where you challenge the story.

Decision

That’s where measurement becomes useful.

A dashboard shouldn’t just tell you what happened.

It should help you decide what to investigate next.

KEEP. CHANGE. REMOVE.

Once you’ve audited your metrics you don’t need to keep everything.

I use three simple buckets.

KEEP

The metric is useful.

It connects reasonably well to the thing you’re trying to improve.

Keep it.

But still question it.

No metric gets a lifetime membership card.

CHANGE

The metric contains useful information...

but it’s incomplete.

Maybe it needs another metric beside it.

Maybe you need an experience signal.

Maybe you need to segment it by product area.

Maybe you need to change the way it’s interpreted.

Don’t throw it away.

Improve it.

REMOVE

The metric creates more confusion than value.

Maybe nobody knows what decision it supports.

Maybe people optimize for the number instead of the outcome.

Maybe it has become a vanity metric.

Remove it.

Yes...

even if you’ve been reporting it for three years.

Sunk cost isn’t a measurement strategy.

Look beyond the team boundary

Here’s another test I like.

When a metric moves...

look one level outside the team.

Then another.

A team’s cycle time might be high because reviews are slow.

Reviews might be slow because another team owns a dependency.

That dependency might be slow because the architecture creates a bottleneck.

The architecture might exist because of an old product decision.

Suddenly your “team productivity problem” isn’t really a team productivity problem.

It’s a system problem.

This is why engineering metrics need context.

The closer you get to the real constraint the less useful a single-team metric becomes.

Talk to the people experiencing the system

This is the easiest way to look for the red inside the watermelon.

Talk to the people using the product.

Ask:

What’s getting in your way?

What’s slower than it should be?

What wastes your time?

What works technically but feels painful?

You don’t need a giant survey.

You need honest signals.

The dashboard might say:

99.9% uptime.

The user might say:

“I still can’t get my work done.”

Both can be true.

That’s why experience belongs beside your engineering metrics.

Not instead of them.

Beside them.

The five-minute metric audit

You don’t need a three-month transformation project.

Pick one metric.

Just one.

Then write:

Metric:
What number are we looking at?

Intent:
What are we actually trying to improve?

Signal:
What does the metric tell us?

Blind spot:
What does it leave out?

Alternative explanations:
What else could cause the number to move?

Experience:
What are users or employees experiencing?

Outcome:
What changed in the real world?

Decision:
What should we do if the number moves?

Action:
KEEP / CHANGE / REMOVE

Five minutes.

That’s enough to expose a surprising amount of nonsense.

Your dashboard isn’t the strategy

I’ve sat in enough meetings to know how this goes.

Someone shares the dashboard.

The lines move.

Someone asks why.

Another person gives an explanation.

Everyone nods.

Then we move to the next slide.

The dangerous part isn’t the dashboard.

It’s the confidence we place in the story around it.

A metric can be accurate.

A dashboard can be technically perfect.

The data can be clean.

The calculations can be correct.

And you can still make the wrong decision.

Because accuracy isn’t the same as meaning.

Your deployment frequency can be accurate.

Your cycle time can be accurate.

Your PR count can be accurate.

Your uptime can be accurate.

The question is...

What do those numbers actually tell you?

And what are you assuming they tell you?

That’s where engineering leaders need to slow down.

Not because metrics are bad.

Because metrics are powerful enough to make weak stories look convincing.

The real goal isn’t more measurement

I used to think better engineering management meant getting better data.

Now I think it means getting better questions.

The goal isn’t to build the biggest dashboard.

It’s to build a dashboard that helps you see reality.

Sometimes that means adding a metric.

Sometimes it means removing one.

Sometimes it means talking to users.

Sometimes it means looking across team boundaries.

Sometimes it means admitting the number you celebrated last quarter didn’t mean what you thought it meant.

That’s not failure.

That’s learning.

And honestly...

I’d rather discover a bad story than keep making good-looking decisions based on it.

Final takeaway

A green metric next to a red experience isn’t a contradiction.

It’s a signal.

Something is missing.

That’s what a good metrics audit is designed to find.

Take the five metrics you trust most.

• Try to break them.

• Find their blind spots.

• Talk to the people experiencing the system.

• Look for the friction between teams.

• Ask what outcome actually changed.

• Then decide what to keep what to change and what to remove.

Keep the metrics. Question the story.

Because the dashboard isn’t the strategy.

The questions you ask about it are.

Want the playbook?

If this article made you look at your engineering dashboard a little differently...

I put the practical version into an Engineering Metrics Truth Audit Playbook.

It gives you a simple way to:

• audit the metrics you already use

• find misleading or incomplete metrics

• spot the blind spots in your dashboard

• connect engineering activity to real outcomes

• uncover the Watermelon Effect

• bring employee and user experience into the picture

• find system-level constraints

• decide what to keep, change or remove

• turn metrics into better engineering decisions

No giant framework.

No 47-page consulting report.

Just a practical playbook you can use with your team.

If you want to stop collecting numbers and start getting better decisions from them... Get the playbook.

Get the Playbook !!!

Because you don’t need more engineering metrics.

You need better questions around the ones you already have.

The system nobody used…

Eighteen months! That’s how long it took to build the platform “right?”

• Event-driven from day one.

• A service mesh before we had a second team to justify one.

• Multi-region active-active, because “what if we need to scale globally.”

• A schema flexible enough to absorb business models we hadn’t even conceived of yet.

Every design review ended the same way: someone asking “but what if we need to handle 10x?” and the room nodding along, because who wants to be that person who didn’t plan for scale?

We shipped a cathedral. But what the business needed was a tent.

And the part I don’t love admitting: I was one of the people nodding along in that room. Nobody forced this on us. We talked ourselves into it, one reasonable-sounding “what if” at a time.

Eighteen months after launch, the product had pivoted twice -

• The multi-region setup we’d sweated over never saw traffic outside one data center.

• The event bus we’d designed for massive throughput was carrying a few hundred messages a day — quiet enough that on-call engineers joked about hearing crickets.

• The flexible schema, built to absorb business models we never ended up building, sat there as unused columns and

• forgotten migration paths, a monument to a future that didn’t arrive.

We hadn’t built a system. We’d built an insurance policy against a future we guessed at — and paid for that guess in the currency that matters most in this industry which is - Time.

Eighteen months we didn’t get back, in a market that moved on without waiting for us.

We built for a future that never showed up. That’s the sentence that kept nagging at me long after the project wrapped. And it forced an uncomfortable admission: we weren’t really doing architecture. We were trying to predict the future — and dressing those predictions up in diagrams to make them feel like engineering.

Why we keep calling it a Blueprint?

We inherited the word “blueprint” from construction, and it’s a seductive metaphor — precise, complete, drawn before a single brick is laid. A blueprint implies that if you think hard enough up front, you can specify the final state, and execution becomes a matter of following the plan.

Buildings can work this way because they operate inside constraints that hold still. Gravity in 2026 behaves exactly like gravity in 1926. The ground doesn’t pivot to a new business model six months into construction.

Software systems don’t get that luxury. The market shifts. Competitors ship something that changes what “table stakes” means. A regulation appears. Someone in the C-suite reads an article about AI agents and suddenly the roadmap has a new top priority. Your blueprint was accurate the day you drew it, and it started decaying the moment ink hit paper.

Yet we keep architecting as if the ground will hold still. We produce artifacts — the diagrams, the ADRs, the sprawling design docs — that read with the same false confidence as a building’s structural plan, describing a future we don’t actually know.

When was the last time you saw an architecture doc that admitted, in writing, “we’re not sure about this part”? I can’t remember the last one I wrote that did either.

The tell is in the language itself. Nobody asks “what did we bet on in Q2?” in an architecture review. They ask “did we follow the design?” That question only makes sense if you believe the design was knowable in advance. Which, usually isn’t.

The Reframe: Architecture is a Bet !

Here is the model that’s actually stuck with me since - the one I keep coming back to whenever a design review starts sounding a little “too certain”: every consequential architectural decision is a bet on the future.

Not every decision qualifies, to be fair —

• some are constraints you don’t get to choose,

• some are pure engineering hygiene with no real uncertainty attached.

But whenever we’re choosing an architecture in the face of an unknown future, we’re making a bet. We just usually don’t call it that.

A bet has a few characteristics that a blueprint doesn’t. Once you start looking for them, you can’t unsee them in every design conversation you sit in.

The 5 properties of an Architectural Bet !

1. Thesis — what are we betting will happen? When you choose event-driven over synchronous, multi-region over single-region, build over buy — you’re not deriving the correct answer from first principles. You’re staking resources on a specific belief about what the future needs. Naming the thesis out loud is the first discipline blueprint-thinking skips.

2. Confidence — what evidence makes us believe it? Good architects don’t ask “is this the right design?” — an unanswerable question about an unknowable future. They ask “given what we actually know, how confident are we in this thesis?” That’s a fundamentally different, and more honest, conversation than the one most design reviews have.

3. Size — how much complexity, time, and money are we willing to commit? You don’t bet your whole stack on a guess about hypothetical scale. Size the bet to the confidence you have, not to the worst case you can imagine. Low confidence, small bet: a lightweight event log instead of a full mesh, a modular monolith instead of a microservices platform you don’t yet have the team to run. High confidence — you’ve seen this pattern before, the signal is strong — size up.

4. Optionality — how expensive is it if we’re wrong? A good bet doesn’t require certainty. It requires a way to survive being wrong — that’s what optionality is for. The less certain we are, the more valuable it is to preserve our ability to change direction. A modular monolith preserves the option to extract services later. An abstraction around a vendor preserves the option to switch providers. A migration path left open prevents today’s decision from becoming tomorrow’s trap.

5. Review trigger — what evidence would cause us to change course? Nobody re-litigates a blueprint once it’s approved — that’s the point of a blueprint, its authority comes from being settled. A bet, by contrast, is supposed to be revisited as new information arrives. You don’t abandon it at the first sign of trouble, but you also don’t treat “we already decided this” as a reason to keep doubling down on a losing position.

Now, let’s go back to my eighteen-month build.

Every “what if we need 10x” question was really an unsized, unhedged, never-revisited bet — and none of us in that room named it as one.

And now, let’s run the same conversation through the five properties instead, and see - it plays out completely differently: What’s the thesis, exactly? What’s our actual confidence that we hit that scale in the next 12 months? What’s the smallest version of this decision that preserves optionality if we’re wrong? What would tell us to reconsider? That’s a different meeting, totally. Honestly, I wish someone had asked it in ours.

Architecture isn’t about maximizing the odds you’re right

It’s about minimizing the cost of being wrong.

If a decision is cheap to reverse, you don’t need much certainty before making it. If it’s expensive to reverse, you should demand real evidence before committing.

This is the same logic Amazon built into its “one-way door / two-way door” framing for decision-making: some decisions are two-way doors — cheap, fast, reversible, you can just walk back through. Others are one-way doors — expensive, disruptive, sometimes impossible to undo. The more irreversible the architectural decision, the more evidence it deserves before you commit.

That gives you a decision mechanism, not just a philosophy. Instead of asking “could this happen?” — a question almost anything passes — ask three questions together: What’s the probability this actually happens? What does it cost us if we’re wrong? What does it cost us to prepare for it right now?

A low-probability, high-preparation-cost bet (full active-active multi-region for traffic you don’t have yet) rarely clears the bar.

A cheap hedge against a plausible near-term risk (an event contract that costs you an afternoon) almost always does.

What this looks like in practice?

Microservices:

• Thesis: “we’ll probably need independent scaling.”

• Confidence: maybe 30%, mostly speculative.

• Bet: a modular monolith with strong internal boundaries, not a service mesh.

• Optionality: boundaries clean enough to extract services later.

• Review trigger: real scaling pressure or real team-boundary friction — not a hunch.

Multi-region:

• Thesis: “we might become globally distributed.”

• Confidence: maybe 15%, no signal yet.

• Bet: design for portability — keep infrastructure choices from locking you into one region, without paying for active-active yet.

• Optionality: swapping in a second region later is a project, not a rebuild.

• Review trigger: an actual customer on the other side of the world, not a hypothetical one.

Event-driven integration:

• Thesis: “future teams will need to integrate asynchronously.”

• Confidence: maybe 60% — this one’s more likely than the others.

• Bet: establish clean event contracts now, on lightweight infrastructure.

• Optionality: contracts are portable to a heavier platform later; today's plumbing isn't load-bearing.

• Review trigger: message volume that actually justifies running a dedicated streaming platform, not the possibility of it.

Same underlying uncertainty, three very different bet sizes — because the confidence, and the cost of being wrong, are different in each case.

What changes when you architect like a “Bettor”?

This isn’t an argument for recklessness or for skipping analysis — bets built on no evidence are just gambling, and gambling isn’t what good architects do. It’s an argument for running the five-property discipline on every consequential decision:

• State the thesis. Say what future you’re betting on, explicitly, in the room where the decision gets made.

• Record the evidence and your confidence. Not “what if” — what do you actually know, and how sure does that make you?

• Size the investment to the confidence. Low confidence gets a small, cheap bet. High confidence earns a bigger one.

• Preserve optionality when uncertainty is high. Pay for reversibility in proportion to how unsure you are — and stop paying for it once you’re not.

• Define what would change your mind. Put a review trigger on the bet before you make it, not after it’s already failing.

The thing though is— our eighteen-month cathedral wasn’t a failure of technical skill. Everyone in that room was smart, experienced, and genuinely trying to do right by the business, myself included. The real failure was capital allocation: we committed eighteen months of scarce engineering capacity to a future that hadn’t earned it. Architects aren’t only choosing technologies. We’re deciding where an organization spends its complexity, its engineering time, its attention, its future flexibility. That’s a much bigger job than picking the “right” pattern off a slide.

Architecture was never really about knowing the future. It’s about allocating resources wisely when you don’t. We don’t need architects who can predict what happens next — nobody can — we need ones who make good decisions when the future, inevitably, refuses to cooperate.

So next time someone asks “did we follow the design?” — try a different question instead: what did we bet on, how big, what happens if we’re wrong, and what would make us change our mind? See how different the room feels.

Keep this in mind:

• Thesis — what future are we betting on?

• Confidence — what evidence actually supports it?

• Size — how much are we willing to invest, given that confidence?

• Optionality — how do we survive being wrong?

• Review trigger — what evidence would make us change course?

A template worth stealing for your next ADR:

We believe: [thesis] Because: [evidence] Confidence: [rough %] We’re investing: [size/scope of the bet] If we’re wrong, it costs us: [cost of reversal] We’ll reconsider when: [review trigger]

Subscribe now

Why Modern Tech Guild?

You didn’t get here by luck !

You shipped the hard features, fixed the systems no one else could, and became the person people turned to when things got difficult.

Then the game changed.

Somewhere between “senior engineer” and “the technology leader,” you’re expected to make architecture calls, lead through ambiguity, navigate organizational complexity, and make sense of AI rewriting the rules beneath you.

No one handed you a playbook.

Most technical leadership is learned the hard way — in public, under pressure, one decision at a time.

That’s why I created Modern Tech Guild.

After more than two decades working across technology transformation, architecture, cloud, engineering and emerging technology, I’ve seen the same patterns play out again and again — what works, what doesn’t, and what only becomes obvious after you’ve lived through it.

This publication is where I distill those lessons.

Not as theory.

Not as technology hype.

But as Practical thinking you can use when the answers aren’t obvious.

What you’ll find here

Modern Tech Guild explores four questions.

🏛️ 1. Architecture & Technology Strategy

How do we build and evolve technology that can withstand change?

Architecture decisions, modernization, cloud, platforms, technical debt, technology strategy and the trade-offs that rarely fit neatly into an architecture diagram.
Architecture decisions, modernization, cloud, platforms, technical debt, technology strategy and the trade-offs that rarely fit neatly into an architecture diagram.

🤖 2. AI, Agents & the Future of Software

What is AI actually changing — and what isn’t?

GenAI, agentic systems, AI architecture, AI adoption and the implications for software engineering and technology leadership.

No AI hype. No breathless predictions.

Just an attempt to understand what is actually changing — and what technology leaders should do about it.

⚙️ 3. Engineering Leadership & Organizations

How do we build engineering organizations that execute?

Scaling teams, engineering effectiveness, operating models, organizational design, technical leadership and the uncomfortable reality that many “technology problems” are actually organizational problems.

🧭 4. The Technology Leader’s Journey

How do technically excellent people become technology leaders?

The journey from senior engineer to Staff, Principal, Architect and beyond — developing judgment, influencing without authority, navigating ambiguity and learning to operate at a different altitude.

What you can expect

I’m not interested in publishing just to fill a content calendar.

You’ll find:

Deep dives — thoughtful explorations of difficult technology and leadership problems.

Field notes — shorter observations drawn from real-world experience.

Frameworks & playbooks — practical ways to approach decisions, not just opinions about them.

Contrarian takes — because some of the most useful lessons begin with questioning what everyone else accepts.

I’ll typically publish once or twice a week, with occasional shorter pieces when there’s an idea worth sharing.

The publication will start free. Over time, some deeper research, frameworks and practical resources may become available to paid subscribers.

Who is this for?

Modern Tech Guild is for people who have moved beyond simply writing the code.

It’s for:

• Senior and Staff engineers

• Principal engineers and architects

• Engineering leaders

• Technology strategists

• CTOs and technology executives

• Technical professionals figuring out what comes next

If you’re being asked to make bigger technology decisions with less certainty, you’re probably in the right place.

One final thought

Technology changes quickly.

The tools change.
The architectures change.
AI is changing the economics of software.

But the harder problems remain remarkably consistent:

How do we decide?
How do we build?
How do we lead?
And how do we know what’s worth doing in the first place?

That’s what Modern Tech Guild is here to explore.

Hard-won lessons. Better frameworks. Clearer thinking.

If that sounds useful, join the Guild.