The faster you could move from idea to implementation, the more valuable you became. Our entire careers were built on being able to hold complex systems in our heads and translate them into working software with speed and consistency.

That model is beginning to shift quietly, significantly, and quickly because code itself is becoming cheaper, not cheap in quality, at least not always. Cheap in production. Cheap in accessibility. Cheap in volume. Today, a developer can scaffold applications, generate endpoints, write tests, refactor functions, and even build entire features with the assistance of AI tools in minutes. Things that once took hours now take prompts.

Naturally, this has led to the usual conversations:

• Will AI replace engineers?

• Will junior developers survive?

• Does learning to code still matter?

I think those are the wrong questions.

The more interesting shift happening underneath all of this is that software engineering is moving up a layer of abstraction. The future of software engineering is specification. The bottleneck is no longer writing code alone. The bottleneck is defining what should actually be built, and surprisingly, this is where many teams still struggle the most.

Most software failures are rarely syntax failures. Systems rarely collapse because someone forgot a semicolon. They fail because requirements were vague, assumptions were misaligned, edge cases were ignored, or business intent was never properly translated into technical reality. AI does not remove unclear thinking. It amplifies it. A vague engineer with AI simply produces vague systems faster.

That is why specification is becoming increasingly important. And when I say 'specification,' I do not simply mean lengthy documentation or Jira tickets filled with corporate jargon. I mean the ability to clearly define intent. To describe systems precisely. To think deeply about constraints, behaviors, tradeoffs, and outcomes before implementation even begins.

In many ways, we are entering a phase where the ability to think clearly about software may become more valuable than the ability to manually write every line of it. That radically changes the engineer's role.

The highest leverage engineers in the coming years will likely spend less time fighting syntax and more time translating ambiguity into clarity. They will define systems, orchestrate tools, validate assumptions, reason about tradeoffs, and ensure that what gets built actually aligns with reality.

This is why I do not fully agree with the idea that AI flattens engineering skills.

If anything, it may widen the gap because senior engineering has never really been about typing speed. The best engineers I have worked with were valuable because they could navigate ambiguity. They could identify what mattered, foresee operational risks, simplify complexity, and make good technical judgments under imperfect conditions. Those skills become even more important in a world where implementation becomes increasingly automated.

The engineer who cannot think clearly will struggle, even with powerful AI tools, and this is where I think many people misunderstand the current moment. There is a difference between prompting and specification. There is a difference between generating code and designing systems, and between “vibe coding” and engineering.

AI can generate code from vibes. Production systems still require precision. As software becomes more interconnected, distributed, regulated, and AI-assisted, the cost of ambiguity increases. Small misunderstandings compound faster. Poor assumptions scale more quickly. Undefined constraints become operational incidents.

The future engineer may spend less time writing code and more time defining reality precisely enough for machines to execute. That is not a reduction of engineering. If anything, it is engineering becoming more mature because, at its core, software engineering was never really about code alone. Code was simply the medium. The greater skill has always been structured thinking, the ability to take messy human problems and turn them into predictable systems.

AI does not remove the need for that.

It makes it more important.

And yet, every time I opened my laptop, I’d suddenly remember a million things that needed my attention, none of which moved the needle on what I said I wanted to do.

I wasn’t tired. I wasn’t distracted.

I just… didn’t want to do it.

And then came the self-talk.

“Why are you like this?”

“You said this was important.”

“Maybe you’re just being lazy.”

But here’s the truth I’ve slowly come to accept:

Most of the time, I’m not lazy. I’m misaligned.

“Lazy” is the word we use when we can’t explain our resistance.

But if you scratch just beneath the surface, the story is almost always more layered.

Sometimes I’m avoiding a task because:

• I’m unclear on why it matters.

• I’ve outgrown the reason I took it on.

• I’m trying to perform someone else’s definition of success.

• Or I’m chasing a goal that’s no longer mine.

It’s not that I don’t want to work.

It’s that I don’t want to work on this.

When I was a kid, I had energy for days, but only for what I was deeply connected to.

I used to rearrange the living room furniture every couple of weeks.

The TV stand is in a new corner. Cushions switched around. Plastic flowers replaced.

My parents and older brother thought I was a little mad, but they let me have my fun.

It wasn’t “work” to me. It was joy.

Even when it was exhausting.

But ask me to do my math homework? Suddenly, I was sleepy.

Looking back, I realize that wasn’t laziness. That was alignment.

I was energized by things I could shape. Things I could feel. Things that made me feel powerful in a world where I often felt small.

That pattern never really changed.

Misalignment at Work

As adults, we call it burnout. Or procrastination. Or writer’s block.

But sometimes, it’s just this:

You’re trying to force your energy into a container that no longer fits.

• A job that used to light you up, but now feels off.

• A relationship where you’re doing all the emotional lifting.

• A startup idea that once felt revolutionary, but now feels forced.

• A daily routine that’s optimized for productivity, not purpose.

You keep pushing, but it continues to drain you.

So you call yourself lazy.

But what if that feeling is actually wisdom?

What if it’s your inner system waving a flag and saying:

“This is not your path anymore.”

Discipline ≠ Alignment

I love discipline. It’s gotten me far.

But I’ve also learned this the hard way:

Discipline can help you climb.

But only alignment ensures you’re climbing the right mountain.

I’ve fought to stick with things that no longer fit jobs, partnerships, or even identity labels.

Because giving up felt like failure.

Because pivoting felt like starting over.

Because “not finishing” felt like weakness.

But here’s the deeper truth:

Letting go isn’t laziness. It’s leadership.

So what do you do when you feel “lazy”?

I check for misalignment.

I pause.

I listen.

I ask:

• Is this still mine?

• Do I care about the outcome, or am I putting in effort?

• What would feel more true, not easier, but more honest?

Finally, here’s what I think:

You’re not broken. You’re evolving…and I think I am too.

And sometimes, what we call laziness is just the soul’s way of saying:

“I’ve moved on. Catch up.”

Give me a well-trained agent that can save me 3 hours of grunt work, and I’ll light a candle in its name.

But lately, I’ve been thinking deeply about judgment, especially as AI agents get more powerful. It’s one thing to know that they can write your test files, clean up your code, and draft documentation. It’s another thing to know what not to let go of.

Because here’s what I’m learning:

Not every task is meant to be automated.

And not every decision should be outsourced.

What I am gladly letting Agents handle

1. Boilerplate Code & Repetitive Patterns - Writing DTOs, mapping interfaces, generating CRUD scaffolds - yes, please (don’t judge me). These tasks don’t need my creativity. They need accuracy and speed.

2. Test Stubs & Refactoring Suggestions - Let the agent scan my codebase and surface what needs cleanup or coverage. I’ll still review it, but I don’t need to spend time thinking about where the camelCase slipped into snake_case.

3. Summarising Long Threads & Docs - I don’t need to manually crawl through a 200-message Slack channel to know what the debate was about. Let the agent summarise it. I’ll verify what matters.

4. Converting JSON Payloads to Typed Structures - A task I’ve done more times than I can count, and never once enjoyed. Off you go, agent.

What I’d probably never delegate

1. Defining what to build - Product sense is sacred. It’s one thing to ask, “Can this be built?” It’s another to ask, “Should this even exist?”

   AI can surface trends but it takes human context to feel real pain points.

2. Shaping Systems and Boundaries - Understanding what belongs together and what doesn’t, that’s not just about structure. It’s about clarity. About anticipating change. That’s still a job for thoughtful engineers.

3. Naming - Honestly, naming isn’t just semantics. Good naming forces clarity of thought. Have you ever lost control of your codebase? I mean, a codebase you wrote yourself but months later could not understand how parts of it work? Bad naming leads to long-term confusion. Agents don’t yet know why UserActivityTracker is better than EventLoggerX3.

4. Giving Feedback to People: I’ll delegate summarizing a PR. But when it comes to offering kind, constructive feedback? That requires emotional context, empathy, and presence. It’s a privilege, not a task so this is something I don’t delegate.

I strongly believe that the real skill today is knowing the difference.

The temptation now is to ask: “What can I automate?” But the better question is:

“What should I automate, and what should I stay close to?”

That’s what separates reactive engineers from strategic ones.

That’s what turns tooling into leverage, not just noise.

In this AI age, judgment is the new 10x.

And your greatest strength might just be knowing when to stay human.

What about you?

I’m curious, what’s one thing you’re now letting an AI tool or agent do for you?

And what’s one thing you’re holding onto very deliberately?

Let’s talk.

More often than you can imagine I have thought about something I wanted to build and all I thought about was the technical cost of building such feature, as if that was going to suddenly make it more desirable to users.

There is this inherent thought pattern that seem to be very recurrent everytime I speak to builders about something they are working on, it is this constant need to justify the depth of technical complexity of the feature/product they are working on, now whether they do that because of my technical background or because of theirs, I can’t say for sure but one thing I can say for sure is that they all believe that the more technically complex the product/feature is, the more they are justified for building it.

But here’s the problem:

• Every feature adds weight.

• Every new flow increases maintenance.

• Every extra endpoint invites more edge cases.

• Every toggle, every integration, every shiny dropdown… compounds.

So if you’re not careful, you end up with something technically beautiful but functionally hollow.

A product that nobody uses but you can’t help but admire the architecture.

I’ve had to learn the hard way, through failed experiments, bloated apps, and nights questioning why nobody cared about the thing I poured months into.

Eventually, I realised I needed a framework not just willpower.

Because willpower fades. Frameworks scale.

So I created 3 grounding questions I now ask myself (and my teams) before we build anything.

They help me slow down. Zoom out. Regain clarity.

Let me walk you through them.

1. Is this solving an itch or am I just itching to build?

   Early in my career, I had a habit of building “cool” things.

   One time, I spent 3 weeks building a mood-based playlist app that automatically adjusted song recommendations based on your typing speed. Technically? Super fun. Practically? No one cared. I wasn’t solving a problem. I was solving boredom.

   Now, whenever I feel the urge to start something new, I pause and ask: “Whose itch is this?”

   If I can’t name the user, the context, and the pain…I’m probably just scratching my own.

2. What happens if this feature didn’t exist?

   This one came from a hard moment. I was pitching a feature to a team once, I believed in it. Designed mockups. Built an early version. But then someone asked: “What if we didn’t ship this? Would anything break?” Silence.

   That question haunted me because the truth was, nothing would break.

   No one would email support. No key flow would suffer. No user would churn.

   That’s when I learned:

   urgency is a signal.

   If your feature isn’t solving something time-sensitive, painful, or revenue-sensitive, it might be fluff, not function.

3. Will this make the product better, or just bigger?

   I once worked on a product that had everything. Search, filters, dashboards, auto-tags, email summaries, onboarding flows, activity scoring…

   It looked like it could do everything. But for new users? It did nothing well.

   I learned that more features don’t equal more value. In fact, they often dilute it. Now I ask: “Does this make the product sharper?

   Or are we just adding weight without increasing clarity?” Because in a world full of bloatware, restraint is a superpower.

The Point of All This

These questions aren’t magic.

But they help me pause when I’m tempted to chase complexity over clarity.

And in the AI era, where agents can scaffold an app in 10 minutes, and LLMs can make anything feel buildable, these questions have become even more important.

The tools are faster. The hype is louder.

But the responsibility to build what matters still sits with us.

Final Thought

You don’t need more features. You need sharper ones. You need clarity. Constraint. Conviction.

So next time you’re excited about what you could build, ask:

1. Who’s itching?

2. What breaks if we don’t do this?

3. Does this make the product better or just bigger?

They’ve saved me countless times. Maybe they’ll save you too.

Want to explore these questions with your team?

Copy them to a doc. Bring them to your next standup.

And ask: “What are we not building this week, and why?”

Let’s build with intention.

Let’s stay human.

LLM-powered. Smart. Slick.

It listened in on Zoom calls, transcribed meetings in real-time, pulled out action items, and even drafted follow-up emails based on who said what.

It felt like magic.

It worked.

It was clever.

And… nobody cared.

The feedback was humbling: “Cool, but I already use Google Docs.”

“I still double-check the transcript.”

“Not sure I need this.”

And that was it.

I sat there - quite tired, caffeinated, slightly offended - wondering how something that smart could feel so… forgettable.

That’s when I realised something I wish I had known earlier:

People don’t care about AI. They care about what hurts.

They care about time they can’t get back.

Money they can’t afford to lose.

Situations where they look unprepared, forgetful, or foolish.

AI? That’s just plumbing.

Let’s take a closer look.

Imagine a fictional app called Meetwise: an AI meeting assistant.

Here’s what we thought we built:

User joins Zoom → Audio transcribed → LLM parses content →

Custom prompts run:
    → Summary  
    → Action Items  
    → Follow-up Emails →

Synced to Slack / Notion / Email →

Done.

Sounds impressive, right?

But here’s what actually matters to the user:

User joins Zoom → Feels less pressure to take notes → Feels present during conversation → Meeting ends →

Gets a clean summary:
    → What they promised  
    → What others owe them  
    → What will make them look sharp in the next call →

They feel calm. In control. Competent.

That’s what we were really selling.

Not AI.

Not automation.

Not “cutting-edge LLMs.”

We were selling relief. Reputation. Time.

The Diagram I Wish I’d Drawn Earlier

The user never sees it.

And truthfully? They don’t care to.

They care that they didn’t forget that one task.

That they looked sharp in front of the CEO.

That they got their time back.

Before You Ship Your Next AI Feature…

Ask yourself three simple questions:

1. Does it save someone time?

2. Does it save or make money?

3. Does it protect people from looking foolish, unprepared, or overwhelmed?

If the answer is no, it might be technically cool, but emotionally irrelevant.

And if your product doesn’t feel like it solved a pain, it didn’t solve anything.

The Real KPI of an AI Feature?

Time saved, Money earned or protected, Embarrassment avoided

If it doesn’t hit one of those?

It’s a demo, not a product.

So, here are my final thoughts:

AI is the hammer.

But the nail still matters.

If you want to build something people use, and love — don’t start with “We use AI.”

Start with:

“We help you avoid missing the one thing you’ll regret later.”

That’s a story people remember.

And that’s what people pay for.

I’d love to hear from you, what’s the best (or worst) AI feature you’ve seen lately?

And what problem did it actually solve?

Drop a comment or share this with the one friend still pitching “AI for vibes.”

If this resonated and you’re building something real in the AI space, or just tired of fluff - follow me.

I write for founders, engineers, and builders trying to create value, not just features.

Clean code? Check.

Lightning speed? Check.

Terminal set up like he hacked the Pentagon for fun? Check.

Give him a task, and within 48 hours he’d respond with a pull request, a 60-line commit message, and a Slack message that started with “so I made a few improvements…”

Problem was: he didn’t solve the problem.

He had rather solved twelve adjacent problems elegantly, masterfully, unnecessarily.

The bug was that users couldn’t reset their password because the code they received wasn’t working when they tried using it.

He built a fully decoupled auth service with biometric fallback support.

For a product with 47 users.

I remember looking at his PR like: Sir… nobody asked for this.

Here’s what I learnt that day and what I have always preached: brilliance without judgment is actually just expensive energy.

And in today’s world where the tools are even faster, frameworks are fancy, and GPT can write your tests while you sleep, technical judgment is the new 10x skill.

Wait. So what is technical judgment?

It’s the invisible skill no one puts on their resume.

It’s not about knowing the best solution - it’s about knowing what actually matters right now.

It’s asking things like:

Is this problem real, or just annoying?

Do we need a scalable system or just a working one?

Is this a clever idea or am I just bored?

It’s that moment when your inner voice whispers:

We could rewrite this in Rust… but also, we could go outside and touch grass.

The best engineers I’ve worked with aren’t just good at coding.

They’re good at not coding the wrong thing.

They know when to slow down, when to zoom out, when to say, “Actually, this should live in a Notion doc, not our repo.”

I once asked a staff engineer why he didn’t refactor something messy.

He said, “Because I’ll be gone in 3 months, and no one after me will care.”

Was it heroic? No.

Was it wise? Absolutely.

That’s judgment.

And it’s rare.

Here’s why it matters more now than ever

AI is coming for everything that’s fast, repeatable, and syntactically correct.

You can prompt your way to boilerplate.

You can auto-generate a landing page.

You can ship something that looks like software in a weekend.

But you can’t prompt your way to taste.

You can’t autocomplete why something matters.

You can’t Copilot your way through hard tradeoffs, team context, or legacy debt wrapped in ego.

In short: the future is full of tools.

Your leverage is judgment.

So what do we do?

If you lead teams → model judgment. Reward it.

If you hire → look for people who ask good questions, not just give fast answers.

If you’re building → slow down long enough to ask:

“Am I solving the problem or just performing competence?”

Because the next decade won’t be about who codes faster.

It’ll be about who decides better.

As usual, here are my closing thoughts:

Your ability to choose well, consistently, under pressure, with context.

That’s what makes you valuable.

That’s what can’t be cloned.

And that, my friend, is the real 10x.

Seems like we are moving towards the age of thinkers yet again.

Last weekend, though, I watched this show on Netflix - it’s called Medieval. The protagonist, Jan (pronounced Ýan - fancy, right?), keeps repeating this phrase whenever he buries someone close to him: “Death brings life.”

And it struck me: That’s exactly what I wanted to say.

Death brings life.

Endings make space for beginnings. Collapses make room for something stronger. And once that clicked, it unlocked the juice. Lol.

I grew up on self-help. My dad’s library was stacked with titles like An Enemy Called Average and Think and Grow Rich. Those books shaped my early life philosophy: Never. Give. Up.

If the door was locked, you find the right key. If the key didn’t work, you break the door down. Giving up was failure, the kind you tell no one about.

It made me resilient, no doubt. But lately, I’ve realised not every door is meant to open, and not every foundation is worth saving.

Let me tell you a story: so, a few years ago, we built this social networking platform for Africans in the diaspora. It was supposed to help people find casual connections — friends, community, someone to share life with away from home. The pitch deck looked sexy. The TAM slide was shiny. Our early users loved the idea.

But we ignored some cracks in the foundation.

First, casual connections are great in theory, but they don’t generate the kind of return you need to stay afloat. Second, we didn’t factor in that this was peak remote work era, people were already living on Zoom. Who wanted more digital “Hey, let’s connect” pings when they were exhausted from staring at screens all day?

But because I was raised on “Don’t give up,” I kept pushing. More hours, more iterations, more mental gymnastics to convince myself we were just one tweak away from glory.

It felt noble at the time, like loyalty. But sometimes loyalty is just stubbornness in disguise.

Eventually, we made the hard call: Pivot. We let the old idea collapse and shifted to something that actually made sense. It felt like a funeral. We had no answers for ourselves, for our tiny team, for the people we’d told, “This will change everything.”

But three months later, we had a buggy, half-baked version of the new product, and 30,000 users were knocking on our metaphorical door. We’d barely marketed it. We’d spent less time, less money, less stress. But the foundation was strong this time, and the need was real.

Sometimes death really does bring life.

I’ve fought to keep more than a startup.

I’ve fought to keep friendships that had expired.

I’ve fought to keep a version of love that wasn’t really love anymore.

I’ve fought to keep parts of myself that were doing more harm than good, just because I once said, “This is who I am.”

But here’s the thing: not every decision is meant to be final.

Maybe very few are.

Marriage? Salvation? Sure - you wake up and choose those again every single day. And maybe that’s the point: those choices are living covenants, not dead commitments.

But your career? That project you’re dragging along, out of ego or sunk cost? The friendship you’re propping up because you promised “forever” when you were 19 and didn’t know better?

Let it collapse.

Sometimes letting something die is the only way you make space for what’s meant to live.

Don’t get stuck because you once made a decision.

Don’t be loyal to something that can’t carry the weight of who you’re becoming.

Some doors are shut for a reason. Some foundations crack because they weren’t meant to hold the house you’re trying to build.

If it’s rotten, let it fall.

If it’s done, bury it.

And if someone looks at you like you’re reckless for walking away, just smile and say, “Death brings life.”

If you’re in that space…

I hope you find the courage to walk out of the crumbling house before the roof falls on your head.

You’re not giving up. You’re making room.

Let it collapse.

If you’re standing in a crumbling house you’ve outgrown, consider this your nudge. You’re not alone. Let it fall.

You can build something better!

But deep down, I think I knew I wasn’t really changing anything. The cracks in the walls were still there. The old rug was still worn. All I’d done was shuffle the pieces around.

It’s funny how that same impulse follows us into adulthood.

I see it in the way we build companies. We call it a pivot. You feel stuck, so you move the furniture, you switch the market, the pitch deck, the logo. Sometimes it’s needed, but sometimes it’s just your fear of doing the hard, repetitive work of fixing the cracks in the walls.

I see it in myself as an engineer too.

I’ve lost count of how many times I’ve flirted with a shiny new programming language or framework. Maybe we should rewrite this in Rust. Maybe we’d scale better with Go. Let’s rebuild the whole front end in the newest JavaScript flavour of the month. The dopamine hit is real, the promise that if you just change stacks, you’ll feel alive again.

But underneath, you know the truth: switching stacks doesn’t fix your fundamentals. You can rearrange the chairs all you want your messy architecture, your leaky abstractions, your team’s lack of trust, they don’t disappear just because you’ve slapped a new coat of paint on your repo.

When I look back at the work I’m proudest of, it’s never the stuff that gave me that instant rush. It’s the things that forced me to stay. The codebases I refactored bit by bit instead of burning down. The conversations with co-founders that felt like pulling teeth but built real trust. The product vision that didn’t pivot five times in six months just because the metrics were slow to come.

We love to chase the spark. It’s human. But spark alone won’t keep you warm.

I think about my grandma’s mango trees - the way she’d fence them off so goats wouldn’t eat the leaves before they could root. She’d usually say, “Anybody can plant. But who’s patient enough to water?” The sweet fruit comes only after you’ve tended the same soil, season after season.

And yet, we keep wanting to move the garden every time we get bored.

When I talk to friends in tech, whether in Lagos or London - the pattern’s the same. Jump jobs every six months, switch titles, build half-finished products, collect new shiny skills. But the ones who really build leverage are the ones who stick around. Who keep showing up when it’s boring. Who master the same tools so well they can bend them to their will.

Rearrangement is easy. Depth is costly.

Rearrangement looks productive. Depth looks repetitive.

But only one will outlast your adrenaline.

So here’s what I’m still learning: when the itch for something new comes, thank it. Let it remind you you’re alive, that you still crave growth. But don’t confuse the rush for the reward. The reward is the fire, and the fire needs tending, time, and the discipline to stay when every part of you wants to run.

Adrenaline will get you started. Depth will get you home.

Practical Takeaways

When you feel that itch to move the furniture again, ask yourself:

• Is this a real need for change, or is it just boredom masquerading as strategy?

• What cracks in my foundation am I avoiding?

• If I stayed and tended the same soil for one more season, what fruit could come?

Related

If you liked this, you might also enjoy: Clarity is a Feature. Ship It

.

You move fast. You get things done. People admire your initiative.

But there’s a hidden cost to your ability. One that sneaks in quietly.

It’s not burnout. It’s not impostor syndrome. It’s something more subtle:

You’re executing faster than you’re thinking.

When Speed Becomes the Enemy

I’ve launched products before fully defining the problem.

I’ve registered domains before validating the idea.

I’ve shipped systems before, asking who would use them or if they should exist at all.

The irony? I did it all with pride. With momentum.

But when you’re gifted, speed becomes deceptive.

You mistake action for clarity. You confuse movement with strategy.

Your ability allows you to bypass the challenging parts - the ones that require you to grapple with ambiguity, friction, and depth.

The Waste We Don’t Talk About

We don’t talk enough about the waste that comes from talent unchecked:

• Hours spent building what shouldn’t exist.

• Emotional fatigue from seeing promising ideas fall flat, not because they were wrong, but because they were rushed.

• Trust is lost when teammates sense motion without meaning.

The cruel part? You were right - just too early. You executed before the idea was ready to stand.

Pause & Reflect

Let’s try something.

Think of the last 3 things you built or started.

Now ask yourself:

• Did I deeply validate the problem?

• Did I give myself time to think before building?

• Did I seek diverse feedback before execution?

Now flip the script:

What’s an idea you abandoned?

Was it bad?

Or was it just half-baked when you launched it?

Be honest with yourself.

A Counter-Discipline: Design Before Build

Here’s what I’m learning (slowly, painfully, but thankfully):

Speed is good.

But friction is necessary.

Friction is the tension that births clarity. It’s the drag that sharpens your direction.

Here are 3 simple tools I now use to build less and think more:

1. The Idea Parking Lot

Write it down. Let it sit for a week.

Still excited? Revisit it. If not, you saved yourself weeks of premature effort.

2. The Thinking Partner Rule

Before executing something important, I now run it by someone different from me — a designer, PM, user, or non-technical friend. I want friction, not echo.

3. Clarity Gates

Before code:

• Who is this for?

• What exactly does it solve?

• What would success look like 6 months from now?

If I can’t answer these, I’m not ready to build. Not yet.

To My Fellow Builders

This piece isn’t asking you to slow down.

It’s asking you to slow down just enough to aim.

Being capable isn’t bad. But capability without discipline can lead to waste, regret, and burnout masquerading as productivity.

And here’s the most dangerous thing:

You might never know what brilliant idea you killed by launching it too soon.

A Better Way Forward

These days, I still build.

But I also pause.

I journal. I ask dumb questions.

I walk. I reflect.

Sometimes, I resist the urge to buy another domain.

Because I’ve realized:

It’s not about how fast you ship.

It’s about what survives the shipping.

If this hit a nerve, I’d love to hear from you. What’s something you launched too early? And what would you do differently now?

Bonus: Tools That Helped Me Grow

• The Creative Act – Rick Rubin

• Thinking in Systems – Donella Meadows

• The Spirit of Leadership – Myles Munroe

• Four Thousand Weeks – Oliver Burkeman

• The Dip – Seth Godin

I have had the privilege of leading people in various forms, whether it was leading my class as a high school or college student, or heading entire student bodies, departments, and even organizations. I may not be 30 years old yet, but life has truly given me that level of exposure. You’re expected to steer the ship while still assembling the compass. Sometimes, you might even be building the ship - in a storm - with half the crew asking if we’re really heading north.

I have been there. Leading teams, managing budgets, making hires, raising capital, all while learning, fumbling, adjusting.

There were days I gave a pep talk on focus and strategy in the morning… and spent the evening rewriting the roadmap because something just didn’t sit right.

The truth is, most of us are making it up as we go. Not in a reckless way, but in that honest, uncomfortable, fully human way where we’re doing our best with the information we have, while collecting more as we move.

No book or podcast truly prepares you for the moment a teammate cries on a call. Or when a board member questions your conviction. Or when you realise the strategy you pitched six weeks ago… doesn’t work anymore.

But here’s the thing I’ve come to believe: the ability to lead while learning might be the most underrated skill of all.

Not perfection. Not pretending. But posture.

It’s being transparent without losing trust.

It’s saying, “I don’t know yet, but I’m going to find out.”

It’s inviting your team into the process without making them feel adrift.

And maybe, it’s admitting that leadership isn’t about having all the answers - it’s about making sure the right questions are being asked.

These days, I’ve stopped aiming for flawless. I aim for honest, intentional, and adaptive.

I still make mistakes. I still ask dumb questions in smart rooms. I still wake up some days wondering if I’m the right person for the job.

But I’ve also seen what happens when you lead with humility, when you invite your team to think with you, not just follow you. That’s when trust builds. That’s when momentum compounds. That’s when people show up not just for the job, but for the journey.

So if you’re reading this and you’re in that messy middle, and you’re like me…leading and learning - I’d like to say hang on, you’re not alone. There are many of us, and the world needs us to keep trying.

You’re not behind. You’re just human. And you’re probably doing better than you think.

But before I wrap this up, I’d like to leave you with some books that have helped me on my journey to being a better leader; here’s a simple list:

1. The Spirit of Leadership - Myles Muroe

   A foundational and values-based guide on vision, purpose, and inner conviction.

2. The Hard Thing About Hard Things – Ben Horowitz

   No sugarcoating. Just real stories and strategies about leading through chaos.

3. Atomic Habits – James Clear

   Because leadership isn’t just about big moves—it’s about the small disciplines that stick.

4. High Output Management – Andy Grove

   A practical masterclass in team productivity, management cadence, and scaling performance.

5. The Five Dysfunctions of a Team – Patrick Lencioni

   A leadership fable packed with insight into what breaks (and builds) cohesive teams.

6. Turn the Ship Around! – L. David Marquet

   A powerful story of shifting leadership from command-and-control to trust and ownership.

7. Radical Candor – Kim Scott

   How to care personally and challenge directly — especially when leading people you value.

8. Leaders Eat Last – Simon Sinek

   A compelling case for servant leadership and the biological foundations of trust.

9. Trillion Dollar Coach – Eric Schmidt, Jonathan Rosenberg, Alan Eagle

   Lessons from Bill Campbell, legendary coach to Silicon Valley’s best.

10. Principles: Life and Work – Ray Dalio

    A structured approach to decision-making, self-reflection, and team dynamics.

We're all completely obsessed with speed.

Build fast! Ship faster! Stay ahead of the competition!

There are entire religions built around this. Methodologies, tools, and motivational Instagram posts. We act as if you just run fast enough, somehow everything will work out.

Plot twist: I used to believe this, too. Has that changed? Well... let me tell you what I've learned the hard way.

Most of what slows down product teams isn't some gnarly technical problem. It's that nobody knows what the hell they're actually building.

• Requirements that change faster than a toddler's mood

• Problem statements are so vague that they could mean literally anything

• Priorities that contradict each other every single day

• Missing context that leaves everyone just... guessing

You can't sprint if you're lost. Trust me, I've tried.

Here are a couple of things I know about clarity today:

Clarity is a Superpower

Here's the thing: clear goals don't just make decisions easier, they make the right decisions obvious. When your team actually understands why something matters (not just what to build), they start giving a damn. Real autonomy happens. And accountability stops feeling like your manager breathing down your neck.

Check out these two ways to ask for the same thing:

The vague way: "We need to improve conversion."

The way that actually works: "Our onboarding is bleeding 60% of users at step 3. Let's run three experiments next sprint to get that under 40%."

Same goal. But one of these gets your team excited to solve a real problem, and the other gets you a series of threads with 52 messages asking, "What do you mean by improve?"

Clarity Saves You From Expensive Disasters

Most of those painful rewrites, pivot-every-two-weeks situations, and missed deadlines? They're not from technical failures. They're from building the wrong thing because nobody was clear about what the right thing was supposed to be.

We love talking about being "agile," but constantly changing direction isn't agile - it's just expensive chaos. The fix isn't more meetings. It's getting clear about what you're doing before you do it.

Real talk: I once spent months being absolutely furious with my growth team. Nothing they shipped moved the needle. I was ready to fire everyone and hire some "real growth experts" who would show them how it's done.

The problem wasn't them. It was me being a terrible communicator.

I hadn't given them any clarity about what we were actually trying to achieve. Once I figured out what I wanted (and could explain it like a normal human), they started crushing it.

Here's the uncomfortable truth that took me way too long to learn: Great marketing can't fix a confused product. Amazing engineers can't fix unclear requirements. Perfect execution can't fix a strategy that makes no sense.

Clarity Doesn't Just Happen (Unfortunately)

The paradox of clarity is that it's not free. It takes effort to ask better questions, write precise specs, and challenge your own assumptions. But the payoff is immediate and compounds.

Story time: My co-founders and I once had this amazing idea. We were so high on our own genius that we kept dodging the world's most boring question: "But like... how do we actually make money?"

We'd go on to say something like: "If you build it, they will come!"

Spoiler alert: They didn't come. Our business died faster than a phone battery at 1%.

These days, I'd literally rather take a nap than move without clarity. And look, I'm not asking for a PhD thesis on the future, but if someone asks "How's this gonna work?" and your answer is "Uh... we’ll figure that out…" then congratulations, you're about to learn some expensive lessons.

Your landlord doesn't accept vision boards as payment. Your credit card company is not moved by your passion. The real world runs on boring stuff like... actual plans.

There's this old design thing that's basically true everywhere: simple is brutally hard, complex is embarrassingly easy. Any developer can add seventeen new features by lunch. It takes actual skill to look at your product and go: "You know what? Half of this is garbage" and delete it.

Kill ambiguity before it kills your velocity. And your bank account. And your sanity.

Treat Clarity Like Code

Here's what I wish someone had told me earlier: Clarity isn't just nice communication. It's a feature of your development and growth process. Build it in. Maintain it like you do your test suite. When clarity breaks, everything else breaks with it.

When you're not sure what to do next? Ship something small. Measure what happens. Learn from the real data instead of your assumptions. Then fix both your code and your thinking.

That's how you build stuff that actually moves forward instead of just... moving.

Clarity isn't about having all the answers. It's about asking the right questions before you waste six months building the wrong thing. (Don’t worry, I have done it on your behalf, so you don’t have to.)

He told me that his best days in engineering were when he was still an IC (individual contributor).

Not when he was managing big teams. Not when he had final say. But when he was simply writing code.

“Those were the best days because success felt tangible,”

“You push, you ship, you win.”

He wasn’t dismissing leadership. He was illuminating a truth I’ve since come to understand deeply: the higher you go, the fuzzier success gets and the more it depends on things you can’t control.

The Durability of Success

A mental model has stuck with me ever since: the durability of success factors.

Ask yourself these two questions:

1. What determines my success right now?

2. And how much of that do I actually control?

As an IC, your inputs and outcomes are often tightly coupled. Ship features, write tests, fix bugs…success flows from your keyboard.

But as you grow in leadership, that coupling stretches. You start managing dependencies. Timelines. Team dynamics. Emotional weight. Stakeholder expectations.

Suddenly, your success hinges on how well others are doing — and whether they trust you enough to let you help.

Let Me Tell You a Story

There was a time in my career, early days of a fast-growing product, where we were close to launch but behind schedule. The pressure was insane. The team was tired.

And I…didn’t write a single line of code.

Instead, I made sure stand-ups were clear, blockers were unblocked, the team wasn’t getting fried, and leadership had transparency without panic.

We launched on time. But no one clapped for me. The win belonged to the team.

And yet, that week taught me the true job of an engineering leader: to multiply output, not to create it yourself.

Are You Sure That’s What You Want?

It’s easy to fall into destination bias, the idea that the next role, next title, next jump will finally feel like success.

But sometimes we’re just climbing ladders we never meant to climb.

Management is not a promotion. It’s a career change.

So many brilliant engineers take the leap, only to find themselves missing the clarity and flow of their IC days. They miss the adrenaline of closing a ticket at 1 AM. The joy of solving a gnarly bug no one else could. The pride of owning something end-to-end.

Leadership trades adrenaline for ambiguity.

You’re not paid to do - you’re paid to think, enable, and trust.

Engineering Is a People Problem

The deeper I go into engineering leadership, the more I realize this:

The real work isn’t the architecture. It’s the alignment.

The hardest bugs to fix are team dynamics. Miscommunication. Silent tension. Lack of ownership.

That’s the real tech debt.

If you’re thinking about stepping into a leadership role, ask yourself this:

Do I love empowering others more than I love being the smartest person in the room?

If the answer is yes, you’re ready.

If it’s not, that’s okay too. There’s incredible value in staying close to the craft.

A Book That Helped Me

If this resonated, here’s a book that’s shaped how I think about engineering leadership:

📚 Systems of Engineering Management by Johan Larrson

It’s not just about managing people. It’s about thinking in systems, aligning clarity, culture, and technical decisions to create velocity at scale.

Because great engineering teams don’t run on code. They run on trust.

Code is easy. People are hard. But people are also the most rewarding part of the job.

If you’re building teams or thinking about your next step, I hope this gave you something to reflect on.

Have you transitioned from IC to leadership? What surprised you the most?

“We realized the market wasn’t right, so we shifted to something better.”

“We listened to customers, made the switch, and 10x’d growth.”

It sounds clean. Strategic. Like an act of genius.

But what no one tells you is that real pivots feel like grief.

Before the clarity comes the chaos.

I’ve lived through three different pivots that tore through everything we thought we knew.

It didn’t come as a brilliant idea in a strategy session. It came after months of tension, user confusion, stalled numbers, and hard conversations with my co-founders.

We had built something we believed in. We’d spent years on it. Raised thousands of dollars.

But somewhere along the way, the data and the truth started whispering different things.

What we were building, at least in its current form, wasn’t going to work.

Not because we didn’t care.

Not because we weren’t smart.

But because the market had shifted, or we misunderstood something core, or we were just… early.

For one of those times, I still remember clearly, it was because COVID struck, our product had to do with people getting online to have calls with each other, what we didn’t envisage was that our target audience (black professionals) was going to be dealing with something called “Zoom Fatigue.”

And that’s when the real pain sets in.

Pivots don’t start with new ideas.

They start with letting go.

Letting go of the product you loved.

Letting go of your past roadmap.

Letting go of your ego (this is one of the biggest battles you’d have to deal with as a first-time founder).

Sometimes, they also mean letting go of team members.

Or watching a co-founder lose belief.

Or realizing you’ve spent the last 6 months avoiding the truth because it was too painful to admit.

And the worst part? You won’t always be sure the new direction is better.

You’ll be staring at a half-built bridge, wondering if there’s land on the other side.

Every time we’ve had to pivot, it was never really a moment of glory or this insane clarity; it was about taking a hard bite with as much conviction as you can muster. It was a long, murky stretch of half-belief and heavy responsibility.

My last venture was a pivot of a pivot, and guess what: it doesn’t matter.

What I’ve learned is this:

• Pivots are emotional, not just strategic.

  You’re not just changing the business. You’re breaking an identity and trying to rebuild one in real time.

• Pivots test everything.

  Your team’s trust. Your intuition. Investor patience. Your ability to hold tension without flinching.

• The “new direction” won’t always be the right one.

  But not pivoting? That might kill you faster.

• You can pivot too late. Or too early.

  The difference is usually found in painful, clear conversations, not brainstorming.

• Sometimes, pivots break things that can’t be fixed.

  And sometimes, they’re the only thing that lets something better emerge.

If you’re in the middle of one right now…

I see you. I know how disorienting it can be.

You’re probably getting advice from people who only see the surface.

You’re carrying more uncertainty than anyone outside your team realizes.

And you’re probably grieving a version of your dream that didn’t make it.

But here’s the thing:

Just because something didn’t work, doesn’t mean you didn’t.

The courage to pivot isn’t about quitting something.

It’s about choosing to adapt while it still hurts, rather than waiting until it’s too late.

It’s about moving forward, even when the map is blurry, because staying put means sinking.

Final thought:

This might sound cliche at this point, but I’d like to say:

You’re not starting from scratch.

You’re starting from experience.

If you’ve ever pivoted or are considering one now, just know I am rooting for you.

Until next time,

Jephtah

Early in my career, I thought success would come from mastering the technical stack, choosing the right language, the optimal architecture, and the perfect deployment pipeline. And I did grow as an engineer, eventually becoming a tech lead and even co-founding a startup. But as I moved from solo coding into managing and mentoring others, a pattern became clear: even the slickest tech stack can crumble if the human side is lacking. I’ve seen a product with brilliant code fail because the team building it couldn’t communicate. I’ve also seen a scrappy prototype succeed beyond expectations because a passionate, aligned team willed it into existence.

Lessons in People, Growth, and Failure

So what do I mean by “The Human Stack”? It’s a tongue-in-cheek term I use for the layers of human elements that underpin every successful project. Just as a software stack has layers (database, backend, frontend, etc.), the human stack is made of things like communication, trust, empathy, resilience, and leadership. These are the building blocks that don’t show up in your architecture diagrams, but absolutely determine whether your app will thrive or die.

One lesson I learned the hard way is that growth isn’t just a technical scaling problem. When my startup began to grow rapidly, I thought our biggest hurdles would be things like server capacity or adding new features fast enough. Those did matter, but what kept me up at night were questions like: Are we hiring the right people? Are we maintaining our culture as we scale? Can our team handle the stress of fast growth? In one chapter of this journey, I watched a talented team nearly burn out because we neglected those human questions. It became clear that scaling the human side (roles, relationships, processes) was just as critical as scaling our systems.

And then there’s failure, something every builder faces sooner or later. I’ve had my share of all-nighters and failed releases, and even an entire product that we had to shut down. Those moments hurt. In retrospect, though, they taught me more than any success ever could. I learned to embrace humility and to listen. I learned how important it is to foster an environment where it’s okay to talk about what’s not working. Blaming technology for a failure is easy (“the algorithm didn’t scale,” “we had a bad roadmap”), but often the root cause is human. Maybe we didn’t understand the customer’s real needs, or the team wasn’t aligned on the mission. A strong human stack means owning up to mistakes, supporting each other, and turning failures into lessons. It’s not about avoiding failure at all costs (that’s impossible); it’s about building the trust and grit to navigate failure together when it happens.

Throughout these experiences, I started paying as much attention to people as I did to code. I began to prioritize one-on-ones over pull requests, design discussions over new libraries, and team retrospectives over deployment scripts. Don’t get me wrong, clean code and solid architecture are still vital. But I now see them as half the equation. The other half is how we work together and who we become in the process. This insight is both humbling and empowering: humbling, because it showed me how much I had to learn about leadership and empathy; empowering, because it means even thorny problems can be solved if we focus on the human fundamentals.

Why I’m Starting this Newsletter

I’m kicking off “The Human Stack” newsletter to share this journey and hear about yours. Over the years, I’ve gathered stories, moments of bright triumph and dark frustration, that all taught me something about the human side of tech. I plan to explore questions like: How do you build a team culture that outlasts any project? What does effective leadership look like in a startup sprinting at breakneck speed? How can we, as makers, take care of our mental health in an industry that glorifies hustle? And how can we center users and communities in the products we create, not just as metrics but as people?

My goal is not to preach or offer quick fixes, but to open up an honest conversation. Some posts will be personal stories from my time in the trenches, shipping product updates at 2 AM, grappling with co-founder disagreements, mentoring junior devs, and being mentored in return. Other times, I might distill lessons I’ve learned (and am still learning) about leadership, productivity, or balancing innovation with stability. I’ll celebrate the wins, but I won’t shy away from the messy stuff either. After all, the messy stuff is where the real growth happens.

If you’ve read this far, chances are something in this topic resonates with you. Maybe you’re an engineer who was suddenly thrust into a management role and felt completely unprepared. Maybe you’re a founder figuring out how to keep your company culture intact as you scale. Or maybe you’re just someone who cares about the people part of building cool things.

Welcome 🙏

I hope my stories and reflections will spark your own, and that you’ll chime in with your perspective. I truly believe that by sharing these insights, we can all get a little better at this whole human+tech thing.

Thank you for reading The Human Stack. This is just the beginning of a conversation I’m excited to have. In the coming weeks, I’ll be writing about some specific principles of the human stack, and I invite you to reply or comment with your thoughts. Let’s learn from each other as we go.

Until next time,

Jephtah

If you enjoyed this, consider subscribing or sharing with someone who might find it valuable🤝

But if I had the chance to do it all over again, I wouldn’t do it the same way.

The Highs

We grew fast. Four product lines. 85+ team members. Over 500,000 businesses onboarded. I led engineering from day zero: from writing the first lines of code to building distributed teams, designing infrastructure, and leading delivery through chaos.

But here’s what most people don’t see in those headline numbers: growth that outpaced clarity. Fundraising momentum that made it harder to say “no.” The quiet cost of trying to scale before the foundation was solid.

The Lessons

1. Too much money, too fast, is not always a blessing

Capital can accelerate, but it can also blur vision. When you haven’t fully found product-market clarity, the money creates noise. It feeds the instinct to build faster instead of deeper. I wish we had been slower to scale and quicker to focus.

2. Investor alignment matters more than you think

It’s easy to celebrate a “big round.” It’s harder to measure the pressure that comes with it, especially if the board is pushing in a direction that pulls you away from the core of what you’re trying to build. We felt that tension.

3. Product clarity should always outrank optics

We shipped a lot. We built well. But in hindsight, I see where we built things because they sounded impressive, not because they were essential. Especially in early-stage teams, clarity is currency. Without it, everyone runs but in different directions.

4. Not all disagreement is misalignment, but not all alignment is real either

As co-founders, we had different instincts about where the company should go. I tried to stay aligned for as long as I could, but over time, I stopped waking up excited. That matters. And I didn’t realize how much until I left.

It’s hard to walk away from something you built from scratch. Especially when you’re still emotionally invested. I didn’t cash out my equity. I stayed up shipping. I believed in the mission. But I also knew I couldn’t fake alignment, not for the team, not for myself.

We celebrate raising money, but we rarely talk about the weight that comes after, the trade-offs, the tensions, the responsibility to people, and the vision.

I don’t regret building Kippa. I gained more than I lost. But if I’m ever building again, I’ll obsess less about momentum and more about meaning.

Because capital is fuel. But without clarity, all it does is burn faster.

Subscribe now