The wave just arrived — in quarterly earnings calls, in layoff announcements, in the slow realization that the job description you had last year looks a little different now. Maybe a lot different.
If you’re reading this from inside that uncertainty, this post is for you.
I recently finished The Coming Wave by Mustafa Suleyman — co-founder of DeepMind and one of the people who helped build the technology now reshaping how we all work. It’s not a comfortable book. But it’s an honest one. And honest, right now, is more useful than comfortable.
Suleyman’s central argument is blunt: this wave — AI, synthetic biology, and the technologies converging around them — cannot be uninvented. There is no “undo.” There is no version of events where we collectively decide it was a bad idea and walk it back.
The question was never whether it would arrive. The question is always: what do we do now that it has?
That reframing matters more than it sounds. Because a lot of the anxiety I see — and feel — is rooted in the wrong question. We keep asking “will AI take my job?” when the more actionable question is “given that AI is here, what does my next move look like?”
One question traps you. The other gives you somewhere to go.
I went through a layoff a couple of years ago. Different circumstances, but the feeling is recognizable: the calendar empties, the noise stops, and you’re left sitting with a version of yourself that was defined by a role that no longer exists.
It’s disorienting in a specific way. Not because you’ve failed — but because the ground moved and nobody asked your permission.
That’s what AI disruption feels like for a lot of people right now. The ground is moving. The roles that felt stable don’t feel that way anymore. And the uncertainty isn’t about whether you’re good enough — it’s about whether the map you’ve been using still matches the territory.
It mostly doesn’t. And that’s genuinely hard.
But here’s what I took from Suleyman, and from my own time in that stillness: disruption doesn’t erase what you’ve built. It just changes where it applies.
One of the book’s most useful ideas is about containment — the instinct to try to slow, limit, or control the wave. Suleyman is skeptical. Not because he thinks regulation is bad, but because history suggests that no single actor, government, or company has ever successfully contained a genuinely powerful general-purpose technology.
The internet wasn’t contained. Mobile wasn’t contained. AI won’t be either.
This matters for how you think about your own response. If you’re waiting for the disruption to stop before you make your next move, you may be waiting a long time. The more useful posture is to stop optimizing for a world that’s going away — and start building leverage in the one that’s arriving.
That’s not resignation. It’s navigation.
Here’s the part that gets lost in every “AI is eating jobs” headline: the things that matter most about good work are remarkably stable.
Judgment. Context. Trust. The ability to read a room, to hold a standard, to make a call when the data is ambiguous. The capacity to bring people together around a hard problem and keep them moving when momentum stalls.
AI is accelerating execution. It’s making the what faster and cheaper. But it hasn’t — and may not — replace the why and the who.
The engineers and leaders I’ve watched thrive through this transition aren’t the ones who learned the most AI tools the fastest. They’re the ones who stayed clear on what they bring that the tools can’t replicate — and got better at that, specifically.
Suleyman frames it as a question of co-evolution: how do humans and these technologies grow together, rather than in opposition? That framing opens up a different kind of thinking. Less defensive. More deliberate.
If you’re anxious about what AI means for your work or your team, that anxiety is worth listening to — not as a sign that something is wrong with you, but as a signal that your environment is changing faster than your map.
The response to that isn’t to panic. It’s to update the map.
What skills are becoming more valuable in your domain? Where are the new bottlenecks forming now that execution is cheaper? What do the people and teams doing well right now have in common?
These are navigable questions. They don’t require certainty about the future — just honest attention to the present.
The Coming Wave doesn’t offer easy reassurance. Suleyman is clear that this is a genuinely difficult moment, with real risks that deserve serious attention. But the tone underneath the complexity isn’t despair — it’s urgency. The urgency of people who believe we still have meaningful choices to make about how this unfolds.
I find that steadying. Not because it makes the wave smaller, but because it reminds me that agency is still part of the equation.
The uninvited guest is here. It’s sitting at the table and it’s not leaving.
The question isn’t how to make it go away. It’s how to figure out what the table looks like now — what role you play, what you bring, what you build next.
That’s not a small question. But it’s the right one.
And you don’t have to answer it all at once.
Inspired by Mustafa Suleyman’s The Coming Wave — a book I’d recommend to anyone trying to think clearly about this moment, not just react to it.
]]>He wasn’t the fastest coder on the team. He wasn’t the one with the flashiest resume or the deepest systems knowledge at the start. What set him apart was something quieter: he cared about the product in a way that most engineers simply don’t.
He’d question a feature’s purpose before writing the first line. He’d push back on designs that technically worked but felt wrong to a user. He’d refactor not because the ticket said so, but because the code didn’t reflect what the product was trying to be.
The other engineers on his team weren’t bad. Some were quite good. They shipped clean code, hit deadlines, and worked well together. But they stayed inside the boundary of what was asked. He kept crossing it — not out of restlessness, but out of care.
That difference — care at the level of craft and product — is what I’ve come to think of as missionary energy. And it changed how I think about building teams.
John Doerr popularized this framing years ago: missionaries build because they believe in something; mercenaries build because there’s a job to do.
It’s a useful distinction, but it’s often misused. Leaders romanticize missionaries and quietly look down on mercenaries — as if caring less makes someone lesser.
That’s wrong.
Mercenaries — and I use the term with respect — are the execution backbone of any team. They show up, they deliver, they don’t need the work to feel meaningful to do it well. They’re pragmatic, scope-aware, and emotionally resilient in ways that missionaries sometimes aren’t.
The junior who became a staff engineer? He was extraordinary. But a team of five of him would have spent half its time debating product direction and the other half refactoring code that was already fine.
You need both. The question is how to mix them.
Genuine missionary energy is rare — not because people lack passion, but because most environments quietly suppress it.
When priorities rotate every quarter, ownership erodes. When “just ship it” is the default culture, craft becomes a luxury. When product context is locked inside a PM’s head and never shared with engineers, there’s nothing for a missionary to attach to.
Most engineers don’t start as mercenaries. They become transactional because the system rewards transactions.
The junior who stood out didn’t have more talent than his peers. He had an environment where product context was visible, where asking “why are we building this?” wasn’t seen as slowing things down, and where someone — his lead, his PM, the culture around him — gave him permission to care beyond the spec.
Missionaries aren’t born. They’re uncovered — in systems that make caring safe and visible.
There’s a subtler version of this I’ve seen more than once: the engineer who exhibits deep ownership, quiet pride, attention to detail — but doesn’t identify as “passionate.” They’d never call themselves a missionary. They just think they’re being thorough.
These are the most dangerous ones to miss.
They don’t perform enthusiasm. They don’t pitch vision in meetings. They just quietly hold the quality bar when no one’s watching. And because they don’t signal loudly, they get managed like everyone else — same check-ins, same expectations, same level of investment.
That’s a mistake. These quiet missionaries often carry more institutional knowledge, more product intuition, and more influence on team culture than anyone realizes — until they leave.
Here’s what no one warns you about: the same energy that makes a missionary valuable makes them fragile.
When you care deeply about the product, you feel every shortcut. Every compromised release. Every decision that trades quality for speed. It accumulates — not as resentment, but as fatigue.
The junior who grew into a staff engineer? There were stretches where I could see the weight of caring more than his environment demanded. He wasn’t burning out from workload. He was burning out from the gap between his standards and the team’s defaults.
Missionaries don’t need less work. They need their care to be met — with clarity, with standards, and with at least a few people around them who operate at the same frequency.
Without that, purpose eats balance. And the best people quietly start protecting themselves by caring less.
Mercenaries bring something missionaries struggle with: detachment.
They can ship a feature they don’t love and sleep fine. They can pivot away from a project they invested in without grieving. They can look at a messy codebase and say “it works, let’s move on” — and sometimes that’s exactly right.
This isn’t apathy. It’s pragmatism.
In a team, mercenary energy provides:
A team with no mercenary energy stalls in idealism. A team with no missionary energy delivers without soul. The magic is in the mix.
This is where leadership gets practical. Not every role needs missionary energy, and not every person needs to care at the same depth. The leader’s job is composition.
Where missionary energy matters most:
Where mercenary clarity works well:
How to pair them:
How to protect the balance:
Looking back, what made that engineer’s trajectory possible wasn’t just his wiring. It was that the team around him — a mix of people who cared at different levels — created a space where his energy had somewhere to go.
The mercenaries on the team kept things shipping. The missionaries (quiet or loud) kept things meaningful. And the tension between them — the debates about “is this good enough?” — was the engine that drove quality up without grinding velocity to a halt.
If everyone had been a missionary, the team would have been slow, intense, and emotionally exhausting. If everyone had been a mercenary, the product would have been functional but forgettable.
The blend was the point.
The goal isn’t to convert mercenaries into missionaries. It’s not to find a team of people who all care at the same depth.
The goal is clarity — clear enough that missionaries can find meaning in the work, and mercenaries can find structure in it. Clear enough that different levels of care aren’t judged, but channeled.
The best teams I’ve been part of weren’t unified by passion. They were unified by respect — for the mission, for each other’s wiring, and for the reality that building something good requires people who dream and people who ship.
Your job as a leader isn’t to make everyone a missionary.
It’s to make the mission worth caring about — and then trust that each person will bring exactly what they can.
]]>What made it interesting is that this person might actually be a bit junior. Which means the micromanagement likely isn’t intentional. It’s probably a well-meaning attempt to reduce risk, keep things aligned, or prove ownership during a handover period.
And here’s the part that made me reflect instead of just react: I’ve micromanaged people too, especially under pressure. I knew it was a shortcoming in the moment, but still did it because it felt safer than trusting the process.
So this post isn’t a rant. It’s a field guide — written from both sides.
Most micromanagement is a symptom of one or more of these:
In temporary supervisor setups, all of that is amplified: the person wants to be helpful, wants to look responsible, and might not have a mature management playbook yet.
Micromanagement doesn’t just feel bad. It changes how teams behave:
Worst case: the team learns helplessness. Best case: productivity drops quietly.
Micromanagement is usually an attempt to buy certainty with control.
The fix is not “push back harder.” The fix is: replace control with visibility + clear interfaces.
Start from: “This person is trying to reduce risk.”
But still treat the disruption as real and worth fixing.
If someone keeps checking, they’re telling you: “I don’t have a reliable way to know what’s happening.”
Your move: build a simple visibility system that’s easier than interrupting people.
If the conversation becomes about hours, tasks, or detailed step-by-step updates, translate it back:
Define clean edges:
Boundaries aren’t rejection. They protect focus and reduce churn for the whole team.
Trust forms fastest via predictable delivery + short feedback cycles.
When stress spikes, your default behaviors get louder. If you can design your behavior under pressure, you’ll lead better when it matters.
You don’t need a label to judge someone — you need it to pick the right response.
Give them something better than interrupting you.
A lightweight visibility bundle:
Key idea: make visibility pull-based (they can read) instead of push-based (they ping).
When they message mid-flow, respond warmly — but route it to the system:
“Good point. I’ll add this to the decision log and we’ll review it in the daily checkpoint so the team stays in flow.”
Boundaries land better when you provide a replacement behavior:
“If we can batch feedback into one daily check-in, I can keep the team moving while still giving you full visibility.”
When they suggest changes in the middle of execution:
“There are two options here. Trade-off is speed vs quality (or flexibility vs compliance). Which outcome matters most?”
If there are public contradictions, rework, or team confusion, escalate with facts:
Keep it boring. Boring wins.
I’ve done it. Especially under pressure. Here’s what helped me reduce it.
Micromanagement often looks like:
Instead of: “Do it like this.”
Try: “Here’s what success looks like, constraints, and when we’ll review.”
That single change preserves ownership while keeping risk under control.
Delegate in layers:
A simple template:
Then give them room to execute.
Pick one rule for stressful periods:
Micromanagement isn’t a personality trait. It’s often just a bad coping strategy for uncertainty.
“I think you’re looking for tighter visibility and risk control (fair). I’ll set up a daily update + decision log so you can see progress without us interrupting team flow.”
“Good catch. I’ll capture this in the doc and we’ll review it in our checkpoint — so we keep execution focused.”
“Just to align: is the priority speed, quality, or compliance here? The approach depends on which one we’re optimizing.”
“To avoid mixed signals for the team, can we align that I’ll drive day-to-day direction, and we’ll use the checkpoint to adjust priorities and risks?”
“Thanks — let’s sync quickly so we can align on one direction. I’ll consolidate and post the final call in the thread.”
Healthy leadership doesn’t mean “hands off.” It means:
The most useful reframe I’ve found is this:
Micromanagement is usually a signal that the system doesn’t feel safe yet.
So instead of fighting the person, improve the system: visibility, outcomes, interfaces, cadence.
And if you’re the one micromanaging (like I’ve been), don’t beat yourself up — just treat it like any other leadership smell: identify it early, install guardrails, and rebuild trust through clarity.
]]>Nothing critical.
Nothing on the roadmap.
No decision required — at least on paper.
But internally, it surfaced a familiar leadership tension:
when does showing up build trust, and when does it simply cost energy?
At first glance, it looked like a binary choice — go or don’t go.
But the real question underneath was subtler:
I noticed an old instinct kick in — to either fully commit or opt out entirely. That pattern is comfortable, but rarely thoughtful.
Leadership often lives in the middle.
In the early days of joining a team, presence carries disproportionate weight. Before people see your work, they notice how you show up:
Presence doesn’t require overcommitment.
It requires intentional participation.
Showing up briefly, attentively, and with clarity sends a stronger signal than either endurance or absence.
Outside formal meetings, people aren’t evaluating performance. They’re observing something quieter:
These moments don’t reward charisma or volume.
They reward calm judgment.
I’ve learned that trust is often built not through what you say, but through how safe and grounded you feel to be around.
Whether it’s time, energy, or attention, the strongest boundaries are usually the simplest ones.
Short answers.
No apology.
No over-justification.
Confidence closes loops faster than reasoning ever will.
Managing your energy isn’t disengagement. It’s long-term reliability.
Another quiet lesson: how you exit matters more than how long you stay.
Leaving while the conversation is still warm preserves goodwill. Staying past your energy peak rarely adds value — and sometimes erodes it.
Leadership isn’t about maximizing time spent.
It’s about preserving clarity for what comes next.
Looking back, the moment didn’t change any outcomes. But it clarified how I want to lead.
Not by being everywhere.
Not by withdrawing to protect focus.
But by showing up with intent, managing energy without apology, and treating informal moments with the same care as formal ones.
Because some of the most important leadership decisions don’t appear on calendars.
They show up quietly — in how we choose to spend an evening, how we hold a boundary, and how we leave the room.
]]>Same role titles.
Same delivery expectations.
Very different people.
It reminded me that leadership isn’t about applying a single style consistently. It’s about paying attention first — then responding with intent.
One of the most senior people on the team stood out immediately — not because of authority, but because of generosity.
Deep experience.
No ego.
Open to coaching even the most junior team members.
This kind of person doesn’t need more direction. What they need is protection — protection of time, focus, and energy. Left unmanaged, they easily become a single point of failure because everyone gravitates toward them.
My role here isn’t to lead from the front. It’s to amplify their impact without letting them burn out.
Another team member is very early in their career. Friendly, collaborative, easy to work with — the kind of person teams naturally feel comfortable around.
What’s still forming is ownership.
That’s not a flaw; it’s a stage. The risk is confusing collaboration with readiness, or waiting for confidence to appear on its own.
Leadership here is about creating small, safe ownership zones: clear expectations, clear boundaries, and enough support to build confidence — but not so much that responsibility never truly lands.
Collaboration builds trust. Ownership builds credibility. Both matter, but they don’t grow the same way.
Then there’s the senior who doesn’t engage much socially. Direct. Reserved. Strong sense of ownership. Sets clear direction and expects autonomy and respect.
This is where leaders often make mistakes — trying to “warm people up,” mistaking friendliness for alignment, or forcing engagement styles that don’t fit.
Some people don’t want closeness. They want clarity.
With profiles like this, leadership is about setting expectations, aligning on outcomes, then stepping back. Trust is earned by not interfering unnecessarily.
Not every strong contributor wants frequent touchpoints. Respecting that is part of respecting their professionalism.
Another senior team member works fully remotely, has a complicated background, communicates very directly, and values autonomy highly.
Distance — physical and cultural — changes how trust is built. Informal alignment doesn’t happen naturally, and context doesn’t transfer by accident.
Here, leadership can’t rely on hallway conversations or assumptions. It has to be explicit.
Clear agreements.
Clear ownership.
Clear communication contracts.
When expectations are visible and consistently respected, trust follows — even without proximity.
In one week, I saw four very different working styles — none of them wrong, all of them requiring different leadership responses.
If there’s one principle this experience reinforced for me, it’s this:
Lead people differently. Hold outcomes consistently.
Not everyone needs the same level of guidance.
Not everyone wants the same kind of connection.
But everyone deserves clarity, respect, and high standards.
Leadership, to me, isn’t about being liked or applying a framework perfectly. It’s about earning trust through deliberate action — knowing when to lean in, when to step back, and when to get out of the way.
The fastest way to lose strong people is to manage them all the same.
The fastest way to lose direction is to lower the bar.
My job sits in the tension between those two — and this team reminded me of that in just one week.
I’m sure this mantra will evolve. But for now, it’s the one I’m choosing to lead by.
]]>That structure often takes the form of playbooks and guidelines.
When done well, they don’t limit thinking. They accelerate it.
In many teams, learning looks like this:
This works — eventually. But it comes with hidden costs:
The result isn’t just slower learning. It’s uneven growth.
A good playbook is not:
A good playbook is:
Think of it as:
“This is how experienced people tend to approach this problem — start here.”
New joiners don’t start from zero.
Instead of asking:
They ask:
That shift alone accelerates confidence and autonomy.
Playbooks make quality explicit. They answer questions like:
When expectations are visible:
Guidelines create alignment without daily supervision.
People make different decisions, but within the same boundaries:
This is especially powerful in distributed or fast-growing teams.
With a playbook, coaching shifts from opinion to reflection:
This builds judgment — not dependency.
Juniors get safety rails while they build fundamentals.
Seniors use the same playbook to:
Over time, the playbook evolves with the team — not ahead of it.
A common fear is:
“If we document everything, people will stop thinking.”
In reality, the opposite happens.
When basics are standardized:
Rules handle the routine. People handle the nuance.
The real power of playbooks isn’t immediate — it’s cumulative.
Over time:
That’s not documentation. That’s organizational memory.
Experience will always matter. But experience without structure is slow and fragile.
Playbooks and guidelines don’t replace learning — they multiply it.
They turn individual growth into team growth, and team growth into a sustainable system.
If you care about scale, quality, and long-term capability building, learning with playbooks isn’t optional — it’s a strategic advantage.
]]>I consistently excelled when working with high performers and juniors who showed strong attitude and a growth mindset. But I struggled — sometimes deeply — with juniors who lacked ownership, curiosity, or willingness to improve.
At first, I questioned myself.
Was I being unfair? Impatient? Not empathetic enough as a leader?
Situational leadership helped me answer that question — but not in the way most leadership articles describe it.
This is how I’ve come to apply situational leadership personally, shaped by experience rather than theory.
Situational leadership traditionally asks you to diagnose two things:
That framework is useful — but incomplete for me.
It didn’t explain why:
The missing variable was obvious in hindsight.
Over time, I realized I was already using a third diagnostic axis — just unconsciously.
Intent: the willingness to learn, take ownership, and grow.
Once I made this explicit, everything clicked.
I wasn’t reacting to seniority or skill gaps. I was reacting to pull vs. push:
My leadership style naturally amplifies pull. It struggles with push-heavy situations.
That’s not an excuse. It’s a reality to work with.
When a junior shows:
I instinctively shift into high-support coaching mode:
These juniors don’t just improve — they accelerate. And I, in turn, feel energized rather than depleted.
This is situational leadership at its best: high direction + high support → rapid growth.
When intent is missing, situational leadership on paper says I should:
In reality, something else happens:
What drains me isn’t low skill. It’s low ownership.
That’s when I learned a hard but important lesson:
Situational leadership is a diagnostic tool — not an obligation to invest endlessly.
Beyond skill and confidence, I look for signals:
Intent shows up quickly if you pay attention.
With juniors who struggle, I say this early (in my own words):
“I’ll support you closely at the start.
But effort, curiosity, and ownership are expected.
If those don’t show up, we’ll need to change how we work together.”
This creates clarity — for them and for me.
Instead of open-ended patience:
This keeps coaching intentional rather than emotional.
This was a mindset shift.
I don’t treat everyone identically — but I treat everyone fairly.
I adapt my leadership style to capability, but I scale my investment based on intent.
That’s not favoritism. That’s sustainable leadership.
Situational leadership isn’t about being endlessly flexible or endlessly patient.
It’s about:
Some people need guidance. Some need confidence. Some need boundaries.
And some — despite support — aren’t ready.
Recognizing that doesn’t make you a bad leader. It makes you an accurate one.
I no longer judge my leadership by how much I give, but by whether my investment creates growth.
Situational leadership, applied personally, isn’t about saving everyone.
It’s about creating conditions where those who want to grow can truly thrive — and having the courage to stop pushing when growth isn’t being met halfway.
That’s the version of leadership I stand by.
]]>The Golden Path is a counter-measure.
Originally popularized in platform engineering, a Golden Path is a well-supported, opinionated default way of doing things that makes the right way the easy way. What’s powerful — and often overlooked — is that this idea scales far beyond DevOps or infrastructure.
Used correctly, the Golden Path becomes a unifying principle across engineering, product, data, AI, security, and leadership.
A Golden Path is:
It is not:
Think of it as a paved road: you can still go off-road, but most people shouldn’t need to.
As organizations scale, specialists deepen while alignment weakens. Golden Paths create shared leverage:
Most importantly, they free experts to focus on hard problems, not repeatable ones.
Golden Path examples
Impact
Key principle: Optimize for flow, not freedom.
Golden Path examples
Impact
Key principle: If it’s not self-service, it’s not a Golden Path.
Golden Path examples
Impact
Key principle: Reduce ambiguity before it hits execution.
Golden Path examples
Impact
Key principle: Consistency beats cleverness.
Golden Path examples
Impact
Key principle: Make responsible AI the default, not an afterthought.
Golden Path examples
Impact
Key principle: Shift security left — and hide it in the path.
Golden Path examples
Impact
Key principle: Make expectations explicit, not tribal knowledge.
A Golden Path succeeds when it follows these rules:
Here’s the hidden power move:
A Golden Path is how senior people encode their judgment into the system.
Instead of:
Experts design paths that:
This is how organizations move from hero culture to system excellence.
Golden Paths are not about control. They’re about clarity, leverage, and trust.
When every discipline has a clear, well-supported way forward, teams move faster together — without sacrificing autonomy where it matters.
Build fewer rules.
Build better paths.
This post introduces the 🟡 Golden Planning Stack: a lightweight, AI-first planning system designed for Cursor-style development that keeps direction, intent, and architecture intact while throughput increases.
This is not Agile theory, Scrum mechanics, or Jira process. It’s a pragmatic layering of intent + constraints so AI speed doesn’t become entropy.
Cursor fundamentally changes how software gets built:
Without guardrails, that turns into:
Traditional planning systems (task lists, sprint boards, PRDs) can’t keep up with AI velocity. What you need instead is a stack — layers of intent and constraint that absorb speed without collapsing.
Think of this stack as gravity:
flowchart TB
NorthStarOutcome --> IntentBrief --> DesignMap --> ExecutionBoard --> CursorSessionPlan --> TodoScratchpad
Question: What meaningful outcome are we trying to change?
This is not a feature. It’s a measurable change in the world.
Good examples
Bad examples
Rule: If Cursor generates hundreds of lines of code that don’t move this outcome, the code is noise.
A 1–2 page living document, not a heavy PRD. It defines:
Why this matters with AI: Cursor is powerful, but unopinionated. The Intent Brief gives it opinions. Paste it into prompts repeatedly to anchor decisions.
Not full architecture — directional clarity. Include:
Best formats:
Rule: If you can’t explain the design in five minutes, Cursor will invent one for you.
This is where most projects start — and why they fail.
Use a Now / Next / Later structure:
Each “Now” item must be:
Golden rule: Cursor writes code. You decide what exists.
This layer is unique to AI-assisted development.
Before each focused Cursor session, define:
This prevents:
Think of this as prompt hygiene for humans.
This is where ideas go so they don’t distract you. Capture:
Most of this should never reach the Execution Board.
Rule: A good planning system absorbs ideas without obeying them.
flowchart TD
Outcome --> IntentBrief
IntentBrief --> DesignMap
DesignMap --> ExecutionBoard
ExecutionBoard --> CursorSession
CursorSession --> TodoScratchpad
TodoScratchpad --> Outcome
↺ Weekly reflection back to Outcome.
You don’t need complex tools. A simple repo structure works:
1
2
3
4
/docs/intent.md
/docs/design.md
/docs/decisions.md
/docs/scratchpad.md
Execution board options:
Cursor lives inside this system, not above it.
Cursor gives you near-infinite acceleration. The Golden Planning Stack gives you direction. Without both, you’re just moving very fast — in random directions.
If you want next steps, this framework can be extended into:
Happy to build those out next.
]]>2026 feels less like a reset and more like a refinement.
I’m orienting this year around three themes:
Fewer things, taken further.
Ship less noise. Build systems people trust.
Fundamentals that compound.
Great work isn’t always fast — but it always lasts.
Smarter paths over harder paths.
Better abstractions, clearer ownership, stronger teams.
This shapes:
No big aspirational list.
Just an invitation to think more deeply and build more meaningfully, together.
— See you in the next post.
]]>