Alright, let’s get into it. Nobody cares if you ship code like Amazon ships cardboard. Seriously, nobody. Because when things go wrong, and they always do, your neatly packaged syntax doesn’t matter. What counts is your ability to think.

Yeah, I said it. Think. Terrifying, isn’t it?

Junior Developers Don’t Fail Because They Miss Semicolons

Early in my career, I had a mentee named Alex (obviously not their real name, I’m sarcastic, not cruel). Alex was passionate, eager, and about as good at critical thinking as a goldfish at algebra. This person could code like the wind. Lines flew from their fingertips. But ask Alex why their solution worked, or worse, why it didn’t, and they'd stare back like a cat caught watching dog videos.

Here’s the bitter truth: Syntax errors rarely tank careers. But an inability to frame problems? That's career suicide.

"Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
- Abraham Lincoln

Preparation, thinking clearly, framing the problem, that's sharpening your axe. Mentors, it's your damn job to teach them this.

Stop Coding, Start Architecting

Here’s a controversial claim: Mentorship isn't about transferring skills. It's about transferring mental models. Skills become obsolete faster than celebrity marriages. But mental models? They’re forever.

One day, Alex frantically messaged me, drowning in their IDE, buried under bugs. I told Alex, “Step away from the damn keyboard. Breathe. Stop coding. Let’s think.”

We sketched the problem on paper. We broke it down. Inputs, outputs, constraints, no magic syntax spells, just simple logic. Alex’s eyes widened, not in horror, but in revelation. They were seeing the matrix. It was glorious.

In that moment, Alex stopped being a code monkey and became an architect. The bugs practically fixed themselves. (Spoiler: They didn't. Alex fixed them, but you get the point.)

Why Thinking Beats Shipping Every Single Time

Let’s be clear: shipping matters. But shipping without thinking is just throwing problems into the future. Research backs this up. Dr. Carol Dweck’s groundbreaking work in Mindset: The New Psychology of Success explains that those with a growth mindset, people who see problems as puzzles rather than barriers, consistently outperform those who rely purely on fixed skills and rote practice.

Your junior devs aren’t failing because they suck at JavaScript. They're failing because nobody taught them how to think through a JavaScript problem like it’s a chess game. Every good chess player thinks five moves ahead. Why the hell aren't we teaching developers to do the same?

How to Teach Thinking (Yes, Really)

Here’s the deal:

• Stop spoon-feeding answers. Ask questions instead.

• Force them into architecture mode: diagrams, pseudocode, coffee-stained napkins, whatever works.

• Encourage the why: Demand explanations. Make it awkward. It’s fun!

• Celebrate clarity, not just speed: Reward thoughtful solutions, even if they take longer initially.

You’re not teaching them to code; you're teaching them how to solve problems. That's mentoring. That’s leadership.

Ok, let’s open this up:

Most mentors treat thinking like it’s optional, a “nice to have” skill that juniors will magically pick up by osmosis. Spoiler: they won’t. If you don’t deliberately teach thinking, you’re just raising fast typists with expensive salaries.

Stop spoon-feeding answers.
When a junior asks, “Why isn’t this working?”, your instinct is to jump in with the fix. It feels good. You look smart. They look grateful. But in reality, you’ve just robbed them. You stole the rep. It’s like going to the gym, spotting someone, and then bench pressing the bar for them. Sure, they “finished the set,” but they didn’t get stronger. Good mentors don’t hand out fish. They hand out fishing rods, bait, and maybe a sarcastic comment about falling in the water.

Force them into architecture mode.
Syntax is seductive. It makes you feel productive. Lines of code = progress, right? Wrong. Lines of code are like calories, too many of the wrong ones and you’re bloated, sluggish, and praying for mercy. Thinking, on the other hand, is the diet plan. Take away the IDE. Get them to diagram the flow, sketch pseudocode, draw boxes and arrows. My favorite exercise? Make them explain their design without touching a keyboard. If they can’t explain it in crayon, they don’t understand it in code.

Encourage the why.
“Why” is where the magic lives. Don’t just accept, “It works now.” Push: “Why does it work?” Watch them squirm. That discomfort is growth. Daniel Kahneman, in Thinking, Fast and Slow, calls this System 2 thinking, the slow, effortful, logical kind. Most people avoid it because it feels like work. But this is where problem-solving muscles form. If they can’t tell you why, they don’t own the solution.

Celebrate clarity, not just speed.
Anyone can hack something together with Stack Overflow or nowadays ChatGPT duct tape at 2 a.m. But speed without clarity is like sprinting blindfolded. You’ll hit a wall eventually, probably face-first. Celebrate when they pause to sharpen the axe, when they diagram, when they articulate trade-offs. That’s not wasted time. That’s investment. Slow is smooth, smooth is fast.

Teach them to zoom out.
Thinking isn’t just about solving the current bug. It’s about asking, “What problem am I really solving? And for whom?” That’s the leap from coder to engineer, from engineer to architect. Encourage juniors to see the bigger system: the user, the business, the constraints. Code is the tool, not the goal.

Embrace mistakes as case studies.
Stop fixing errors for them. Let them bomb. Then dissect the wreckage together. It’s not punishment, it’s practice. A mistake is just tuition you already paid, might as well learn the damn lesson. Make post-mortems part of mentorship, not just production outages.

Because here’s the uncomfortable truth: you’re not teaching them to code. Anyone can Google syntax. You’re teaching them to think. To frame problems. To explain trade-offs. To anticipate consequences. That’s mentoring. That’s leadership.

And if you do it right, they’ll surpass you. They’ll outgrow your guidance. They’ll start teaching you. Which is the point. The best proof of mentorship isn’t loyalty, it’s obsolescence.

TL;DR:
Shipping fast is cute. Thinking first is powerful. Great mentorship transfers mental models, not just skills.
Stop producing code monkeys. Start creating architects.

References:

• Dweck, C. S. (2006). Mindset: The New Psychology of Success. Random House.

• Lincoln, Abraham. (Attributed quote).

“While we teach, we learn.” - Seneca

I remember back in Iran, the first time I failed a class, I spiraled. I didn’t ask, “What went wrong?” I asked, “What’s wrong with me?” Like most humans, my default response to failure was self-blame. The pain didn’t just sting, it stuck.

In a desperate attempt to fix it, I tried everything: extra classes, study groups, structured learning programs where a teacher spoon-feeds you the syllabus. But none of it really clicked.

What did change things was this strange little experiment: every time I read something new, I tried to teach it.

Now you might ask, “Teach who? You don’t even know the topic yourself.” Fair enough. Stay with me.

I found a few methods that worked:

• Teaching myself out loud, as if I were the instructor. No silent reading. I stood up and explained the concept like I was running a class.

• Finding people who wanted to learn, and asking them if I could teach the topic for free. That gave me a reason to study faster, dig deeper, and find answers to questions I hadn’t thought of.

• Cornering my friends (bless their patience) and turning our hangouts into impromptu lessons. I’d explain what I just learned and see if I could make it make sense to someone else.

There were more hacks, but let’s not get lost in the weeds.

The point is: teaching saved me. It wasn’t just a tool for others; it was a mirror, a motivator, and a method to turn confusion into clarity.

And that’s what brings us back to the main topic: teaching.

1. Teaching Forces You to Actually Understand

“If you can't explain it simply, you don't understand it well enough.” - Albert Einstein

The truth is, we developers often think we understand something… until we try to explain it to a beginner.

When I first taught the difference between a monolith and a microservice, I realized I’d been using metaphors and BS that only made sense to someone already deep in the trenches. Teaching forced me to revisit assumptions, clarify my logic, and simplify.

Most of the time, when someone tries to explain something in the team meeting, I take the role of the dummest person in the room and I kindly ask them, “Try to explain as if I’m 5”.

It’s like writing tests; teaching exposes the edge cases in your own knowledge.

Try this:
Pick a concept you use daily, Git rebase, dependency injection, Kubernetes pods, and explain it to a non-technical friend. Watch where you stumble. That’s your gap.

2. Teaching Builds Empathy, a Superpower for Any Leader

“The single biggest problem in communication is the illusion that it has taken place.” - George Bernard Shaw

Technical brilliance is great. But communication? That’s leadership.

In my first year of “trying to be a leader“, I made a crucial mistake: I assumed everyone had the same mental models I did. I’d say things like “Just abstract that into a service,” or “Push it into the audio queues”(My Internet Radio days), and be met with blank stares.

Teaching forced me to slow down. To ask what do they need to hear, not just what do I want to say. That shift built empathy, and empathy became my leadership foundation.

Every time I taught something, I was also practicing how to read the room, rephrase ideas, and check for real understanding, not just nodding heads. Those are the exact same muscles you need when guiding a team through complexity.

Now, maybe you’re thinking, “Well, people should just ask if they don’t understand.” Sure. In theory.

But how often have you seen someone stay quiet in a meeting, nod along in a crowd, and then completely miss the mark later?

Yeah. Me too. More times than I can count.

As much as I believe in “be the dumbest person in the room” as a learning mindset, if you’re the one leading, the burden’s on you to make things clear. You don’t get to blame silence. You have to notice it.

Teaching taught me that. If your audience isn’t following, it’s not their failure; it’s your feedback.

Alternative perspective:
Could this make senior developers too “soft,” less focused on technical mastery? In my experience, no, if you see empathy as a tradeoff instead of a multiplier. But the best tech leaders I’ve known? They blend depth with humanity.

3. Teaching Is the Fastest Path to Leadership Without the Title

Here’s the kicker: You don’t need permission to lead. We already talked about it in older posts.

I’ve seen junior engineers become cultural anchors simply by running a Q&A group on weekends. I’ve seen mid-level devs fast-track into team leads because they mentored a struggling colleague through system design.

Teaching makes you visible, not in a show-off way, but in a trusted guide way. And teams follow trust. Not just teams, humans follow trust.

“A leader is one who knows the way, goes the way, and shows the way.” - John C. Maxwell

You don’t have to wait for a promotion. Start teaching. It might become your promotion.

4. It Connects You to a Greater Purpose

Sometimes we forget: code is just a tool.

What matters is the people we empower with it, and teaching is a direct line to that impact. Whether it’s a junior dev breaking into tech, or a peer finally understanding Kubernetes, you made that possible.

In a world of burnout, layoffs, and impostor syndrome, teaching grounds us in meaning.

It reminds us: we’re not just building systems, we’re building people.

Let’s Flip the Lens

Now, let’s challenge some assumptions, shall we:

Assumption: Teaching is for experts.
Counterpoint: Teaching is how you become one. You only need to be one step ahead to help someone behind you.

Assumption: It takes too much time.
Counterpoint: You’re already explaining things in Chat, code reviews, and pair programming. Why not do it intentionally?

Assumption: It’s not part of my job.
Counterpoint: If you care about your team, your craft, or your own growth, teaching is your job.

How to Start

• Run an internal workshop on a topic you love.

• Write a blog post explaining a tricky concept simply.

• Host a coding session for juniors or interns.

• Speak at meetups (start small, even 5 people counts).

• Record a short screencast for your team’s wiki.

Don’t wait until you feel “ready.” Teaching makes you ready. Drop the perfectionist act.

Final Thought

“When one teaches, two learn.” - Robert Heinlein

I love this quote, so simple yet so deep.

Whether you’re a backend wizard, a frontend artist, or somewhere in between, you have something worth teaching. And in the process, you’ll grow sharper, kinder, and more influential than ever.

So here’s my challenge:

What will you teach this month?

You Don’t Need a Crown to Change the Kingdom

Let me tell you about a guy named Martin.

It was a Wednesday. That kind of Wednesday where everyone create urgency out of nothing and nobody knows why they’re in the meeting. Managers were zooming in on dashboards like they were CSI detectives. Juniors were Googling “how to fake your own offboarding.”

Then Martin, a senior IC, leaned forward and said, “Here’s what I’d do…” Five minute later, the noise stopped. The room adjusted itself like gravity just shifted, Some questions were asked and we had a plan.

Nobody gave Martin a title. He had no team to “own.” He wasn’t even on the project. But he led anyway.

Why? Because leadership has nothing to do with job titles and everything to do with credibility and timing.

Let’s Kill the Myth:

You Need Authority to Lead

We’ve been spoon-fed this nonsense for years. That power comes from job levels and LinkedIn headers. That to lead, you need someone’s permission. Spoiler: that’s how you get managers who micromanage and engineers who mentally check out.

“Leadership is not about titles, positions or flowcharts. It is about one life influencing another.”- John Maxwell

Authority is something you’re given.

False. Authority is something you earn when people know they can count on you.

Influence requires approval.

Also false. Influence often starts exactly where formal leadership stops caring.

Counterpoint from skeptics:
“Yeah, but if we let ICs lead too much, it turns into chaos.”
Yes, if you’re managing like a paranoid robot. But when you build strong culture, senior ICs don’t go rogue. They go first.

My 3 Rules of Leading Without a Title

1. Clarity Beats Charisma

Senior ICs who lead well don’t inspire with rants. They lead with clarity. Their words land because they’re thoughtful, not flashy.

Instead of fake leadership talk like:
“Let’s synergize cross-functional outcomes.” or “We need to realign on our alignment.”

Try:
“This service is the bottleneck. We need to fix that first.”
“I’ve seen this fail before. Want to know why?”
“We’re treating symptoms. Let’s isolate the root cause.”

Andy Grove once said, “How well we communicate is determined not by how well we say things but how well we are understood.”

2. Act Before You Ask

Want to lead? Start doing the thing no one asked you to do, but everyone needs done, and you know how to do it good.

You don’t need permission to fix a broken script. You don’t need a Jira ticket to explain a system. You just need initiative and nerve.

“Don’t move information to authority, move authority to the information.”- David Marquet

Senior ICs don’t wait to be asked. They act, because they’re already standing where the decision needs to happen.

3. Don’t Be Additive. Be a Multiplier.

You can write perfect code and still be useless to the team. If you’re not mentoring, you’re just hoarding insight like it’s gold.

Why? Because output isn’t the same as impact.

If you’re not mentoring, you’re not leading, you’re hoarding. You’re sitting on a mountain of experience like it’s Bitcoin circa 2011, hoping someone decodes your cryptic commit messages.

Senior ICs multiply value.
They review code like they give a damn.
They pair program to teach, not to show off.
They answer questions by building frameworks, not just offering fixes.

Leadership is communicating other’s worth and potential so clearly that they are inspired to see it in themselves. – Stephen R. Covey

Leadership isn’t about being the smartest person in the room. It’s about making sure you’re not the only one who knows what’s going on.

Mentorship is leadership without ego.
It’s not a favor. It’s the actual job.

So if your impact ends with your editor window, you’re not a multiplier. You’re just noise with syntax highlighting.

Managers, look:

If you’re not giving space for ICs to lead, you’re the bottleneck. Congratulations. You’ve officially become the process people complain about behind your back.

The real job is not to tell. It’s to observe who already leads and give them room to grow.

Want better team dynamics? Stop waiting for potential and start noticing action. Leadership isn’t unlocked at level six. It’s happening now.

TL;DR: No Title Needed

Senior ICs lead without authority all the time. They see problems and solve them. They guide others without a schedule. They build trust in the gaps.

If you’re a senior IC, act like a leader today.
If you’re a manager, stop holding the reins so tight. Someone already stepped up. All you have to do is get out of the way.

• If you’re a Senior IC: Take up space.

• If you’re a manager: Make room.

• If you’re a company: Stop confusing title with talent.

Leadership isn’t earned by climbing. It’s proven by showing up when it matters.

We force humans into linear frameworks. Then we wonder why they burnout.

Ladders Are for Buildings. Humans Need Loops.

Picture this: You’re 28, already leading a team, and someone says, “Next stop: Director!” You nod. Because that’s what grown-ups do, right? Climb the ladder. Play the game. Wait for the title. Wait for permission. Wait for… what, exactly?

Now fast-forward five years. You’re a VP. You’ve got the money, the parking spot, and enough migraines to qualify as a small pharmaceutical trial. You’re bored. Stuck. Disconnected from your craft. And you quietly ask yourself, “Is this it?”

That’s not ambition. That’s autopilot. And it’s time we call it what it is: a socially accepted midlife crisis in slow motion.

The Myth of Linear Growth

People think growth is linear, but growth is messy, cyclical, and often requires U-turns and breakdowns.

Think about it. Nobody tells an artist, “First you draw stick figures, then by year four, you’re Michelangelo.” But in tech, in law, in finance, we cram people into paths so narrow they should come with a safety warning.

David Epstein’s Range makes this painfully clear: generalists who zigzag, explore, and pivot outperform specialists. Why? Because they know how to think, adapt, and learn. That’s real agility. Not title inflation.

“It is no measure of health to be well adjusted to a profoundly sick society.” – Jiddu Krishnamurti

The Manager’s Trap

Camille Fournier’s The Manager’s Path is brilliant, and a little damning. It lays out the classic IC → Tech Lead → EM → Director → VP progression.

Clear. Sensible. Also: a trap if you never question it.

Not everyone wants to manage. And good Lord, not everyone should. Some lead through influence, not headcount. Some scale systems, not org charts. Some grow deep, not tall.

But traditional paths treat that like stagnation. As if mastery isn’t worth as much as meetings.

Better Models: Growth Loops, Jungle Gyms, and Career Arcs

If the old-school ladder is broken, what actually works? You need a model that fits how humans really grow, messy, multi-directional, and shaped by seasons, not salary ranges. Here’s how you build something better:

Growth Loops: Learn, Stretch, Reflect, Repeat

Instead of climbing higher for the sake of a title, think in loops:

• Learn a skill.

• Apply it to a real challenge.

• Reflect on what worked (and what didn’t).

• Build deeper mastery.

Then do it again, but bigger. No new job title required. No performative career theater needed.
This model is about actual capability, not just box-ticking.
It’s how experts are made, through iteration, not ladder rungs.

Jungle Gyms: Grow Sideways, Not Just Up

Sheryl Sandberg first popularized this idea in Lean In, and it’s still one of the best metaphors out there.
Instead of vertical-only promotions, think lateral moves, side quests, cross-functional projects, job shadowing, secondments.

On a jungle gym:

• You can climb sideways.

• You can jump to another part entirely.

• You can even swing backwards for a while to build momentum.

In short: You build range, not just rank.
The modern economy rewards the people who know how to pivot, not just how to stand taller in one spot.

Career Arcs: Seasons, Not Checklists

Here’s a heretical thought: Not every decade of your life needs to be about climbing.

Maybe:

• Your 30s are about learning broadly and taking creative risks.

• Your 40s are about depth, building true mastery.

• Your 50s are about mentoring, legacy, and picking projects that light you up inside.

Your career should feel like a novel, not an assembly line.
There are chapters. Some short. Some sprawling. Some that blow up halfway through and demand a rewrite.
That’s not failure. That’s living.

The Senior Who Said No

I remember her, she was brilliant. Empathetic. Technically lethal. So naturally, the company said: “Time to lead people!”

She said: “I’d rather not.”

They panicked. We didn’t. We built a role around her that fit her strengths, technical strategy, system thinking, mentoring without people management.

Years later? She built the most critical product in the company, and on the way of doing that she mentored many. She didn’t climb. She anchored.

So What Should You Do?

If you’re a leader: burn the ladder. Build something modular, flexible, and human. Give people mobility, not metrics.

If you’re a developer: don’t wait for permission to explore. Track growth by depth and curiosity, not titles and bands.

If you’re in HR: stop designing tracks like pipelines. People aren’t water. Create career maps, not career prisons.

TL;DR: Ladders Are for Firemen. Not for You.

Career ladders are outdated. They’re rigid, joyless, and built for an economy that no longer exists. People grow in spirals, not straight lines. The future belongs to those who loop, leap, explore, and sometimes sit the hell down to think.

You don’t need to climb. You need to evolve.

Sources:
– Range by David Epstein
– The Manager’s Path by Camille Fournier
– The Fearless Organization by Amy C. Edmondson
– Lean In by Sheryl Sandberg
– Krishnamurti, public domain lectures

The Lie We Tell Ourselves as Leaders

Most managers will nod sagely when you talk about “autonomy.” They’ll quote Daniel Pink or throw around “Spotify squads” like candy at a TED talk. But behind closed doors?

They don’t actually want autonomous teams.

They want obedient soldiers dressed as creative thinkers. They want control with the illusion of freedom. It’s easier to say, “I empower my team” than to sit in the anxiety of not knowing what they’ll do next.

Here’s the truth:
If your team can’t make a decision without you, you’re not a leader. You’re a bottleneck.

“The best executive is the one who has sense enough to pick good people to do what he wants done, and self-restraint enough to keep from meddling with them while they do it.” – Theodore Roosevelt

Autonomy Isn’t a Perk – It’s the Whole Damn Point

Let’s stop sugarcoating it.

Autonomy isn’t a “nice to have.” It’s not a perk like gym membership or Donut Fridays. It’s the fundamental difference between:

• A team that builds products,

• And a team that builds trust.

And here’s the brutal part – autonomy exposes weakness. Not just in your team. In you.

When you fear autonomy, it says:

• “I don’t trust my team to make the right call.”

• “I secretly believe I’m the smartest person in the room.”

• “I don’t know how to fix things if they go wrong.”

In other words: I’m not leading. I’m managing my own fear.

Micromanagement Is a Cult of Control

Micromanagers aren’t evil. They’re scared.

But fear makes us hesitant. And teams can sense it.

• You rewrite their code “just to make it cleaner.”

• You hover in every sprint planning meeting “just to help.”

• You pull back decision-making “because it’s critical.”

You justify it to yourself as “maintaining quality.”
But what you’re really doing is training your team to stop thinking.

If you’re making all the decisions, here’s what you’re building:

• A team of yes-people

• A backlog of dependency

• A future where you are the single point of failure

Autonomy Without Competence Is a Suicide Pact

Let’s not pretend the opposite of micromanagement is a utopia.

Giving autonomy to an unskilled or misaligned team isn’t empowering – it’s neglect.

Autonomy without competence creates:

• Wandering priorities

• Narcissistic heroism

• Decision whiplash

• Unaccountable chaos

It’s not noble. It’s lazy. It’s abdication.

Your job as a leader is not to “let go.”
Your job is to prepare them to be let go of.

“Don’t give people autonomy until they’ve proven responsibility. Otherwise, you’re just letting toddlers drive your car.” – (Me)

Warning Signs You’re Faking Autonomy

If you’re doing any of the following, you’re pretending to offer autonomy – and your team knows it:

• You say “You own this,” but override decisions during reviews.

• You assign “accountability” but never ask how they’re solving things.

• You allow decisions only within pre-approved templates.

• You demand “innovation” but punish deviation.

That’s not autonomy. That’s theater.

Real autonomy means:

• They choose the tools – and own the consequences.

• They pick the architecture – and debug it when it burns.

• They challenge your idea – and you don’t flinch. You get curious.

The Real Test: Would They Still Thrive Without You?

Here’s your crucible:

If you took a 3-week vacation and turned off your phone, what would happen to your team?

• Would they freeze?

• Would they fight?

• Would they fly?

That tells you everything.

The most effective leaders are anti-fragile creators of leaders, not followers waiting for instructions. They don’t create dependency – they breed independence.

“The best leaders are those whose teams continue to thrive long after they’re gone.” – Liz Wiseman

But Wait – What About Accountability?

You might say:
“Autonomy sounds great until someone screws up. Then I get blamed.”

Yes. You will. Because you’re the leader.

But here’s the thing:
You’re already responsible. The only question is whether your team is strong enough to carry it with you.

The solution isn’t control. It’s clarity.

• Clear vision.

• Clear priorities.

• Clear boundaries.

And then? Get out of the way.

How to Actually Build Autonomy

Let’s get tactical. Here’s how to start today:

1. Set decision boundaries

Map out what the team can decide, what they should escalate, and where the overlap is. Make it visual. Revisit monthly.

2. Kill the “approval mindset”

Ban questions like “Is it okay if we…”
Replace with: “We plan to do X because of Y. Objections?”

3. Reward initiative, not compliance

Celebrate how people think – not just that they followed instructions.

4. Get brutally honest in retros

Ask: Where did you wait for permission? Where did I insert myself where I shouldn’t have?

5. Make leaving not a disaster

Train people to replace you. Make knowledge sharable. If you’re hit by a bus(or win the lottery), the team should keep running. If not – you failed.

Final Word: Autonomy Isn’t Comfortable – It’s Courageous

Stop pretending this is easy.

It takes guts to loosen your grip.
To watch your team fail.
To let them fix it.

But that is leadership.

“If you want to build a ship, don’t drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea.” – Antoine de Saint-Exupéry

Your Turn: Do This Today

Audit your own leadership:

• What decisions am I clinging to?

• Where am I being the bottleneck?

• Which team members are ready for more space – and which need more coaching?

Then do the hard thing: let go. Even a little.

Because in the end, the only thing scarier than giving your team autonomy…

…is never seeing what they’re truly capable of.

If this hit a nerve, these books dig deeper into the leadership truths we keep avoiding:

Drive – Daniel H. Pink
Turn the Ship Around! – L. David Marquet
Multipliers – Liz Wiseman
The Fearless Organization – Amy Edmondson
Team Topologies –  Matthew Skelton and Manuel Pais

“Every legacy system was once a greenfield project that succeeded.”

Every new wave in tech arrives with a promise to replace the old, cleaner code, faster deployments, better scalability. We are now deep in the age of microservices, serverless, and distributed everything. And yet, beneath countless companies’ most critical infrastructure lies something many engineers scoff at: the monolith.

But what if we’ve been too quick to dismiss it?

Let me take you back.

The Story We’ve All Lived: “We Inherited a Monolith…”

It’s a sentence uttered with dread in many engineering retrospectives.

The monolith, we’re told, is the villain, unscalable, untestable, unmaintainable. It’s the digital equivalent of a haunted house: nobody wants to go in, everyone just wants to tear it down.

But let’s pause.

That monolith? It’s still standing. It’s been running for 20+ years, processing millions of transactions, surviving team churns, poor documentation, and shifting priorities. It supported the company before Kubernetes was a word, before CI/CD was cool, before “DevOps” was even a job title.

Shouldn’t that resilience earn some respect?

Assumption Check: Are Monoliths Really the Problem?

We assume monoliths are:

• Inherently slow to change

• Impossible to scale

• Difficult to test

• Anti-agile

But let’s test that.

What makes them slow to change? Poor architecture? Or the absence of any architecture decisions? Often, the issue isn’t the monolith itself, it’s how carelessly it was grown.

Hard to test? Not necessarily. Many monoliths can be split cleanly into modules and benefit from clear separation of concerns (think Hexagonal Architecture). Martin Fowler, who helped define microservices, also said:

“You shouldn’t start a new project with microservices, even if you’re sure your application will be big enough to make it worthwhile. Start with a monolith, keep it modular, and only split it out into microservices once the monolith becomes a problem.”

And base on many aspects, I would say:

“Modular monoliths are underrated.”

So maybe it’s not the format. Maybe it’s the discipline (or lack of it).

Counterpoint: Microservices Aren’t Saints Either

Let’s not forget:

• Microservices introduce complex orchestration

• Distributed systems bring network failures, timeouts, latency

• They require more DevOps maturity, not less

• Debugging becomes a treasure hunt

A poorly designed microservice architecture is often worse than a well-maintained monolith. As Simon Brown noted in Software Architecture for Developers:

“If you can’t build a structured monolith, what makes you think microservices are the answer?”

Because if your team can’t manage a modular monolith, they’ll definitely struggle with 40 interdependent services.

Reframing the Legacy: Wisdom Over Worship

Legacy doesn’t mean outdated. It means battle-tested.

Think about Linux. The kernel dates back to 1991, yet it powers everything from smartphones to supercomputers. Or look at PostgreSQL, nearly 30 years old, but still a go-to choice for critical data infrastructure. Why? Because maturity brings stability, community wisdom, and decades of optimization.

Or take Unix philosophy. It’s older than most of us writing code today (1978), yet it continues to influence how we design software, modular, composable, reliable.

If age were a disqualifier, these pillars wouldn’t still be holding up half the internet.

What legacy systems offer:

• Proven reliability under pressure

• Deep, often undocumented domain expertise embedded in logic

• Business-critical processes that just keep working

The respectful mindset isn’t: “Let’s replace it.”

It’s: “Let’s learn from it, adapt it, and evolve it with care.”

Because wisdom doesn’t scream for attention, it hums quietly in the background, keeping things running.

Lessons From the Field: My Own Transformation

Years ago, I joined a company that ran a spaghetti-coded monolith. No tests, no pipelines, and no documentation. Sounds like a nightmare?

But here’s what we did:

1. We mapped the domain.

2. Introduced modular refactoring.

3. Wrapped the edges in APIs.

4. Slowly built microservices only where justified.

5. Used the monolith as the stable core, not an anchor.

We didn’t fight it. We collaborated with it.

And guess what? The business didn’t grind to a halt. Our team didn’t burn out. The CEO didn’t worry about losing years of logic.

What a Skeptic Might Say

“Aren’t you just slowing down innovation by defending old tech?”
– No. I’m advocating for wise innovation. Evolution, not disruption for its own sake. When engineers run into legacy systems, the goal shouldn’t be to rewrite, it should be to redeem.

“But our monolith is a mess!”
– Then fix the mess. Don’t assume microservices will solve poor design. They’ll magnify it.

What We Should Be Asking Instead

• Is this legacy system still delivering business value?

• Have we truly understood its architecture before judging it?

• Can we make incremental improvements rather than betting everything on a rewrite?

• Are we ready to support the operational load microservices demand?

Conclusion: Smart Architecture Is Context-Aware, Not Trend-Driven

The most effective engineering teams today don’t obsess over being “pure” microservices or “fully modern.” They focus on what works best for the business, in the context of their current constraints.

That often means embracing hybrid architectures:

• Keeping the monolith where domain logic is mature, well-understood, and stable.

• Carving out microservices for fast-moving, independently deployable features, like user notifications, billing, or analytics dashboards.

• Using serverless for lightweight, event-driven tasks like image processing or webhooks.

This isn’t compromise. It’s strategic composition.

Companies like Amazon still run monoliths internally. Shopify famously evolved towards a modular monolith architecture to regain teams productivity and deployment ease. These aren’t failures, they’re smart responses to real engineering problems.

So the next time someone scoffs at your monolith, say:

“It’s not a relic. It’s a reliable foundation. And we know when to build on it, and when to build beside it.”

That’s not old-fashioned thinking. That’s architecture with intent.

Your Turn: Respect Before Refactor

• Audit your legacy system’s value.

• Identify bounded contexts before carving anything out.

• Treat the monolith as a partner, not a problem.

• Choose evolution over revolution.

And remember: Software that works is never obsolete.

There was a time when I believed that learning anything outside of my core expertise was a waste of time. As someone deeply rooted in IT and software development, skills like photography, audio editing, and voice-over work felt completely irrelevant to my future. They had no obvious connection to coding, system architecture, or managing technical teams. So why bother?

Yet, years later, these so-called “useless” skills became some of the most valuable assets in my personal and professional life. They enhanced my creativity, improved my ability to communicate, and gave me a unique perspective on problem-solving. Looking back, I realize that the concept of “uselessness” isn’t about whether a skill has value, but whether its value is immediately apparent.

When I refer to “useless” skills, I mean those that don’t seem to align with an obvious career path. These are the things we learn for fun, out of curiosity, or simply because they spark our interest. At first glance, they may seem disconnected from our work, but over time, they can shape us in ways we never expected. Some of the skills I once thought were distractions, like color grading, painting, or learning to brew pure over coffee or pull a great espresso shot, turned out to teach patience, precision, and pattern recognition, all of which became unexpectedly useful in my IT career.

The Myth of “Uselessness”

We live in a culture obsessed with efficiency, productivity, and measurable outcomes. If a skill doesn’t directly boost income, career opportunities, or immediate practicality, society often labels it “useless.” This belief, ingrained even within many families, unfairly limits our potential and creativity.

But history has repeatedly shown that skills deemed “pointless” can lead to breakthroughs. Leonardo da Vinci’s fascination with sketching the human body, considered an indulgent distraction at the time, directly influenced his innovations in engineering and art. Albert Einstein, known for his scientific genius, played the violin as a way to clear his mind and think differently about physics. The greatest minds have always embraced curiosity, regardless of common expectations.

When I first started photography, I was an IT consultant collaborating with a photography studio. What began as simple curiosity quickly turned into deep passion. I pursued certifications, honed my skills, and discovered how powerfully photography reshaped my perception. It taught me how to see details clearly, frame problems differently, and zoom out to grasp broader landscapes, a skill invaluable in my technical roles and now as a CTO. Similarly, pursuing a degree in audio engineering was dismissed by some as niche and unprofitable. Yet, it not only enabled me to launch a successful radio station and learning platform but also taught me patience, precision, and incremental improvement, crucial qualities in software engineering and leadership.

Beyond career benefits, these skills enriched my personal life. Photography helped me appreciate the beauty in everyday moments, while audio editing refined my attention to detail. Voice-over work, initially just a playful experiment, later improved my confidence in public speaking and storytelling. Skills like learning origami can teach us focus and dexterity, while practicing card tricks helps us understand misdirection and the psychology of attention, which became useful in software interface design.

Discovering Hidden Connections

In his compelling book Range, David Epstein argues that generalists, those who embrace a wide array of seemingly unrelated skills, excel in innovative problem-solving. Each “useless” skill enriches our mental toolkit, empowering us to face complex challenges creatively.

Studies in neuroscience also suggest that learning diverse skills strengthens cognitive flexibility, the brain’s ability to switch between tasks, adapt to new challenges, and approach problems from fresh perspectives. Those who engage in multiple disciplines are often better equipped to navigate uncertainty and solve problems in unexpected ways.

Engaging in seemingly unrelated disciplines fosters cross-pollination of ideas. Many technological advancements come from unexpected intersections: artists influencing product design, musicians shaping sound engineering innovations, and athletes bringing their discipline into corporate leadership.

Reflecting on my own journey, I’ve realized that openness to learning without immediate purpose made me adaptable, versatile, and ready to pivot during uncertain times. In moments of career transitions, leadership challenges, or personal reinvention, these so-called “pointless” pursuits became my greatest strengths. Even learning vector design, a skill I thought would serve no practical purpose, helped me refine my attention to detail and aesthetic sensibilities, which later influenced my UX/UI decisions.

The Surprising Benefits of Exploring the Unconventional

Consider my experience with voice-over and storytelling. Initially developed through my podcasting and radio endeavors (perhaps soon returning, in English), these skills unexpectedly enhanced my public speaking. They gave my presentations authenticity, presence, and trustworthiness. People remembered not just what I said, but how I said it.

The ability to tell a compelling story, control vocal tone, and engage an audience are skills that many corporate leaders, sales professionals, and educators actively struggle to master. Yet I acquired them unintentionally, simply by following my interests.

What’s fascinating is how one skill naturally reinforces another. Photography improved my ability to compose visual narratives, which in turn made my video editing more dynamic. My voice-over work strengthened my confidence in speaking, making me a better leader. In hindsight, none of these were “useless”, they were building blocks for greater versatility and depth.

This revelation reminded me of Steve Jobs’ iconic 2005 Stanford commencement speech, where he shared how studying calligraphy influenced Apple’s aesthetic excellence. Such seemingly unrelated interests can profoundly ripple through your life.

Embrace Curiosity, Reject Limitations

Learning without expectations frees you from constraints. Curiosity-driven learning helps you thrive amid ambiguity, fosters creativity, and cultivates resilience. Each “useless” skill acquired nudges you beyond comfort zones, empowering you to courageously embrace uncertainty, one of life’s greatest strengths.

We often underestimate the compounding effect of seemingly insignificant skills. A person who learns to sketch casually may later become an expert in UX/UI design. A hobbyist coder experimenting with game development could discover a passion for AI programming. A chef exploring exotic cuisines might eventually launch a global food venture. What seems irrelevant today could be the catalyst for something transformative tomorrow.

Expanding your skillset also makes life more enjoyable. Imagine a life where learning is purely about exploration, joy, and creative self-expression rather than just career advancement. A life where trying new things isn’t a means to an end, but a celebration of curiosity itself.

Why You Should Start Learning Something “Useless” Today

Life is unpredictable. Today’s trivial skills could become tomorrow’s greatest strengths. Whether it’s pottery, dancing, gardening, or something more obscure, dive in without hesitation. Learn without guilt. Trust curiosity. Your future self will thank you.

Take a moment and reflect: What skill have you always wanted to explore but dismissed as “unnecessary”? What if, instead of questioning its usefulness, you embraced it simply because it intrigued you?

As I’ve discovered, profound wisdom and growth await discovery within every “useless” skill, patiently anticipating your courage to embrace them. The skills that seem disconnected today may turn out to be the puzzle pieces of your future success.

“The future belongs to those who learn more skills and combine them in creative ways.” – Robert Greene

For decades, the world has favored specialists. The conventional wisdom has been clear: pick one field, master it, and success will follow. Society rewards deep expertise, from academia to corporate careers, where people build their reputations by knowing more and more about less and less.

But the world is changing, and so are the skills needed to navigate it. Industries no longer evolve in isolation, it needs complex structure build with resources management in mind. Technology, business, and science are increasingly interconnected. Problems are complex, requiring solutions that don’t fit neatly into one discipline. In this new landscape, generalists those who think broadly, adapt quickly, and draw insights from multiple domains, are not just relevant. They are becoming indispensable.

The Myth of Specialization

“We can’t solve problems by using the same kind of thinking we used when we created them.” – Albert Einstein

Specialization has been the backbone of progress for centuries. Scientists, engineers, and experts have pushed the boundaries of human knowledge through deep focus. The logic is simple: if you want to be the best, you need to dedicate yourself to a single path. And in some cases, this remains true. Surgeons, elite athletes, and researchers cannot afford to spread themselves too thin.

But specialization has its limits. It often creates tunnel vision. The deeper someone goes into a single subject, the harder it becomes to see beyond it. Industries that rely too much on specialists tend to get stuck in rigid ways of thinking.

History offers many examples of companies and industries that failed because they were too specialized and lacked the broad vision to adapt.

When Specialization Led to Failure

Kodak (Photography & Film) – Invented the digital camera in 1975 but ignored it, fearing it would cannibalize their film business. As digital technology took over, Kodak collapsed, declaring bankruptcy in 2012.

Nokia (Mobile Phones) – Dominated the mobile industry in the early 2000s but focused too much on hardware and ignored the shift to software-driven smartphones. Meanwhile, Apple and Google revolutionized the industry with iOS and Android. Nokia’s mobile division was sold to Microsoft in 2014.

And last but no least, Blockbuster (Entertainment & Video Rentals) – Specialized in physical video rental stores but underestimated the rise of streaming. Netflix, founded in 1997, embraced digital distribution and eventually crushed Blockbuster, which went bankrupt in 2010.

When Generalists Led to Breakthroughs

On the flip side, some of history’s most innovative individuals and companies have thrived precisely because they thought beyond specialization, applying knowledge from multiple disciplines.

Jeff Bezos (E-Commerce, Logistics, Cloud Computing) – Founded Amazon as an online bookstore but saw potential in cloud computing and logistics, expanding into AWS, entertainment, and artificial intelligence. Amazon’s success is due to a broad, interconnected vision, not narrow expertise.

Steve Jobs (Technology, Design, Business) – Jobs’ interest in calligraphy shaped Apple’s focus on typography and aesthetics. His ability to merge technology, user experience, and design created products that revolutionized multiple industries.

Tim Berners-Lee (Computer Science, Information Management) – A physicist by training, he combined his knowledge of computing and information management to invent the World Wide Web in 1989, changing the way the world communicates.

Why Generalists Excel in Innovation

If specialization is about depth, generalism is about connection. Instead of mastering a single skill, generalists master the ability to combine knowledge from different fields. This ability is where breakthroughs happen.

Leonardo da Vinci was not just an artist but an engineer, scientist, and anatomist. His understanding of the human body shaped his paintings, and his artistic sensibility influenced his inventions.

David Epstein, author of Range: Why Generalists Triumph in a Specialized World, argues that generalists have an edge in problem-solving because they develop “far transfer”, the ability to apply learning from one context to another. Unlike specialists, who refine one approach, generalists are flexible and adaptable, allowing them to succeed in unpredictable environments.

The Future Belongs to Those Who Can Navigate the Unknown

“In an age of rapid change, the learners will inherit the earth, while the learned will find themselves beautifully equipped to deal with a world that no longer exists.” – Eric Hoffer

The world is shifting, and those who remain fixed in a single path may find themselves trapped in its fading light. Rapid advancements in AI, automation, and technology are challenging traditional expertise, making deep technical knowledge less valuable when kept in isolation. The ability to see beyond a single field, to blend disciplines, perspectives, and ideas, will determine who thrives in the future.

In the midst of uncertainty, generalists hold the advantage. They are the ones who can bridge knowledge gaps, connect ideas from different domains, and navigate the unknown with clarity. Where specialists see only what is in front of them, generalists illuminate new possibilities by drawing from diverse experiences.

Innovation does not happen in the light of certainty. It happens in the shadows of the unknown, where those who can think across disciplines and adapt to change will carve the future. The ones who dare to find light in the darkness of disruption will not just survive, they will lead.

Where Generalism Does Not Work

“If you try to be everything to everyone, you’ll be nothing to anyone.” – Patrick Lencioni

Generalism is not a one-size-fits-all solution. There are industries where specialization remains essential. Medicine, engineering, and academia require years of focused training. Some companies, especially large bureaucratic ones, still prefer narrowly defined roles.

Even in fields where generalists thrive, being too scattered can be a weakness. A successful generalist is not someone who dabbles without direction but someone who finds connections between disciplines and uses them effectively. The key is to balance breadth with depth, what some call a T-shaped skillset. You go deep in one area but remain broad enough to draw insights from others.

The New Path Forward

Careers were once like straight roads, predictable and well-marked. But today, success is found in the spaces in between, where rigid paths dissolve and new ones emerge. The world no longer rewards those who follow a single predefined track but those who can navigate change with agility.

Like this winding path between water and land, the most successful individuals are those who balance depth and breadth, who know when to specialize and when to expand, when to focus and when to explore.

The future doesn’t belong to specialists alone, nor to generalists without direction. It belongs to those who adapt to the landscape ahead, flowing with change rather than resisting it. The greatest asset is no longer just what you know but how seamlessly you can connect knowledge, move between disciplines, and shape your own way forward.

1. Observe Before You Act

Leadership begins with observation, truly seeing what’s in front of you before making decisions. Street photography works the same way. The best photos don’t happen by rushing to click the shutter. They’re born from walking around the subject, viewing it from every angle, and waiting for the right moment.

Once, I stood in front of a plain gray building. It looked lifeless, uninspiring. But instead of moving on, I explored it further. I circled the structure, crouched low, climbed higher, and noticed how the building’s shape from behind told a completely different story. That dull building transformed into something extraordinary, it was almost like a building without windows. It wasn’t, of course, but the perspective made all the difference. That day, one of my favorite photos was born.

I once had a team member who seemed disengaged. At first glance, his lack of initiative felt like disinterest. But instead of assuming, I took the time to observe and have a one-on-one conversation. I learned he was struggling with imposter syndrome, which held him back from taking risks. By understanding his perspective, I was able to provide mentorship and see him grow into one of the team’s most innovative contributors. Just like the building revealed its hidden beauty, people often shine when you take the time to truly see them.

2. The Power of Perspective

Perspective changes everything. A building, puddle, or street corner can look entirely different depending on how you frame it as that building from the last one. Sometimes, the magic lies in shifting your angle to find a hidden story.

One rainy fall day, I was walking down my usual path when I noticed a leaf shining with rain droplets. Viewed at a glance, the street seemed ordinary, cold and wet. But when I zoomed in and focused on that leaf, it became otherworldly. That small shift in perspective turned the mundane into something extraordinary, and I captured one of my favorite shots.

During a project where a customer raised concerns about a deliverable. From our perspective, the product met all requirements, but they were dissatisfied. Instead of pushing back, I encouraged the team to see it from the customer’s point of view. When we did, we realized their frustration wasn’t about the deliverable itself, but about their unmet expectations during the process. This shift in perspective helped us rebuild trust and create a better outcome for everyone involved.

3. Embrace Uncertainty

Street photography thrives on unpredictability. Unlike studio photography, where every element is controlled, the streets are chaotic. You can’t plan for the perfect moment, it just happens. Success depends on how quickly you adapt to what unfolds.

I’ll never forget walking through a park with my camera in my bag when I spotted an older man standing near a lake. The way he stood, the tilt of his head, and the light catching his silhouette created a scene that felt almost choreographed. The scene lasted only seconds. I quickly grabbed my camera, took a deep breath checked the light and shutter speed really fast, then composition and took the shot just before he moved on in about seconds. That moment was gone forever, but I had my photo. For every success like this, there are countless missed opportunities, but that’s part of the process.

During a production issue, the team and I faced data loss. The team proposed an untested fix, but it could have worsened the situation. I chose to rollback the update first, ensuring the team felt calm and supported. This decision restored customer data, gave us time for proper testing, and delayed the release by a day. The fix was implemented successfully, minimizing disruptions and teaching us valuable lessons. Like capturing the man by the lake, leadership sometimes requires quick, calm decisions, even without guarantees of perfection.

4. Patience Creates Masterpieces

While some moments in photography demand quick reflexes, others require patience. Waiting for the golden hour, watching the light change, and timing your shot just right are all part of the process. You can’t rush perfection.

Once, I spent hours waiting to photograph a lone tree framed by the setting sun. I planned my angles, adjusted my settings, and prepared for the perfect shot. Just as the light hit the tree, a crow flew in and perched on a branch. It wasn’t what I had envisioned, but it gave the photo a whole new dimension. That unexpected twist made the shot unforgettable.

I remember mentoring a junior developer who struggled with debugging complex code. Instead of stepping in to fix it for them, I guided them through the process, allowing them to learn at their own pace. It took longer, but the result was a confident, self-sufficient team member. Just as the crow added an unexpected beauty to my photo, their growth brought an unexpected depth to the team’s dynamic.

5. Celebrate the Small Details

In photography, it’s the tiny details that often stand out: the flashes of sunlight on a blade of grass, the vibrant color of a doorframe, or the texture of a cobblestone street. These small elements add richness and depth to an image.

One of my favorite photos is a close-up of a burned wood. At first glance, it’s nothing remarkable. But when I studied it through my lens, the intricate details and light and also thinking forward what I want in post-production of it being black and white and the whole thorn surrounding it captivated me. That detail made the photo unforgettable for me, and it was one of the memorable ones in my exhibition in Germany.

These small details are often moments of recognition. I once worked with a team where one member consistently handled critical but overlooked tasks. During a meeting, I called out their contributions and thanked them in front of the team. That small gesture transformed their engagement and morale. Just as the details in a photo can elevate it, recognizing small but meaningful contributions can elevate your team’s spirit and performance.

Street photography taught me that leadership isn’t about perfection, it’s about presence. Observing deeply, embracing uncertainty, exercising patience, shifting perspectives, and finding joy in the details are the keys to both a great photo and a great team. Whether you’re capturing a fleeting moment on a busy street or guiding a team through challenges, the principles remain the same: show up, adapt, and celebrate the journey.

Prologue

So, you’ve mastered the Engineering Manager role. Congrats! Maybe you’ve juggled deadlines, team morale, and stakeholder expectations so well that people have started calling you the “human Swiss Army knife.” Now you’re looking at the next peak: the CTO role at least it was my next one maybe yours is something else like VP or … but from EM to higher some points are same.

Moving into the CTO position isn’t just a promotion, oh no it is NOT, it’s a seismic shift. Your responsibilities expand from leading teams to steering the entire technical vision of an organization. You’re no longer focused on just the next sprint or quarter; now you’re thinking years ahead, aligning technology with business goals, and preparing the company to scale.

Let’s break it down: strategy, culture, and innovation.

Act 1: From Tactical to Strategic

When I was CEO, I often faced tough decisions about balancing innovation with practicality. One moment stands out vividly. Suddenly, traffic to our audio streaming service spiked after some unexpected media coverage, bringing our service to a halt. At the time, we ran everything, audio streaming, the web application, images, pre-recorded audios, all on the same server. It was clear we were hitting our limits.

One of the teams proposed a bold solution: transitioning our entire audio streaming service to a new platform, effectively separating concerns and future-proofing the system. The benefits were clear, flexibility, scalability, and reduced risk. But so were the costs. We didn’t have enough sponsors to support such a transition, and our investors were already cautious about funding new initiatives without guaranteed ROI.

Instead of jumping in with an all-or-nothing approach, we piloted a short-term solution. I spent time calming both sponsors and investors. Sponsors wanted immediate fixes, and investors were worried about peak-hour downtime. After sitting down with the teams, we landed on a compromise: reducing the bitrate of audio streams while maintaining perceived quality. It wasn’t ideal, but with clear communication and hands-on involvement from all, even me, the teams rallied behind the plan. We converted all the audios to lower bitrate and streamed new ones in lower bitrate too, changing some format and automation on recording to delivery long story short: It worked! Reducing the bitrate cut down workloads significantly, allowing us to handle the surge in traffic without sacrificing the user experience. Over time, as the business grew and funding stabilized, we revisited the original proposal, transitioning the service to a better platform when it made financial sense.

Balancing Technical and Business Realities

As a CTO, or in my case, CEO, you’ll often find yourself bridging the gap between technical possibilities and business constraints. It’s not enough to champion cutting-edge solutions; you need to align them with the company’s immediate goals and long-term vision.

In this case, we needed ROI and availability at the same time. That meant implementing a short-term fix that addressed the crisis while paving the way for sustainable growth. The key is learning to speak both technical and business languages fluently, crafting solutions that satisfy stakeholders on all sides. By focusing on short-, mid-, and long-term strategies, you can ensure technical innovation drives business success without risking the company’s stability.

Act 2: Culture at Scale

As CTO, I witnessed firsthand how rapidly scaling an organization can create both opportunities and challenges. With a growing number of projects and priorities, I quickly realized that attempting to oversee everything personally was impossible, and worse, it would lead straight to micromanagement, the ultimate growth killer.

Instead, I shifted my focus to building a strong leadership pipeline within the organization. I started working closely with Engineering Managers (EMs) and Tech Leads, ensuring we were aligned on core values: prioritizing quality over speed, fostering psychological safety, and maintaining a shared vision. This wasn’t just a set-it-and-forget-it approach; we engaged in regular conversations to tackle both immediate emergencies and long-term goals.

Of course, it wasn’t always smooth. Emergencies cropped up, and we occasionally had to compromise on our principles to meet pressing demands. But these deviations were temporary because our shared foundation kept us steady. Over time, these leaders became multipliers of the culture we wanted to cultivate. They understood the company’s goals deeply, made tough calls, and guided their teams with increasing independence.

They didn’t always get it right, no one does. But the trust we built meant I could step in when necessary, not to micromanage but to refine their approach or offer guidance. What mattered most was that they felt equipped and supported to lead autonomously. That autonomy amplified the impact of our teams and, by extension, our company.

Here’s a critical insight/sidenote I learned along the way: a company isn’t just about R&D or IT; it’s about the business as a whole. As CTO, you can have a significant impact, but there are limits to how far you can grow without alignment across all parts of the organization. It’s like this: you can’t grow the head bigger than the body. At some point, everything, engineering, product, marketing, sales, C-level… needs to work together. Without that collaboration, growth stalls, or worse, the system collapses, so don’t do it alone take others with you if you can.

Build a Leadership Pipeline

As CTO, you can’t manage everything directly. Your success hinges on the strength of your leadership team. Invest in mentoring your EMs and Tech Leads, equipping them to lead autonomously while staying aligned with the company’s vision. They are the ones who will carry your culture forward and amplify your impact across the organization. And remember, true growth only happens when every part of the company works in harmony. Build leaders, but also build alignment across the organization if possible.

Act 3: Innovation Meets Risk

As CTO, I inherited a legacy system that was holding us back—not just in terms of adopting new technologies, but also in our ability to take on new projects and scale effectively. The engineering team was frustrated by how much slower development had become, and we were in emergency mode. A year of stagnation had left the company struggling to stay competitive, and the business side was pushing hard to break into a new market segment.

Replacing the legacy system outright wasn’t an option. It would have meant significant downtime, not to mention the risk of failure. But leaving it untouched wasn’t viable either. We couldn’t implement new protocols or adapt to modern demands—it would’ve been a death wish for the company’s future.

We chose a phased approach instead. New features were built on a microservice’s architecture, while the core monolith continued to handle existing operations. To bridge the gap, we introduced a containerized and non-containerized separation. It wasn’t an easy decision; this path created significant technical debt, required team reorganization, and demanded rapid upskilling in new technologies.

The process was intense. I still remember the big brainstorming meeting where we pitched the idea to the team. Despite the challenges, the developers were excited about the opportunity. It was an 8-month sprint of hard work, filled with bugs, chaos, and growing pains. But the outcome was extraordinary.

We delivered a breakthrough platform that enabled new products, scalability, and orchestration across the company. The legacy system still exists, but now it’s contained, and we know how to move forward without reinventing the wheel. By embracing the chaos, we turned what seemed like insurmountable risks into opportunities for growth and innovation.

Balancing Legacy and Innovation

As CTO, one of your toughest challenges will be balancing technical debt with the need for innovation. Legacy systems often feel like an anchor, but they don’t have to sink your progress. A phased approach, like introducing microservices while maintaining core operations, can mitigate risks and deliver value incrementally.

It’s not about avoiding chaos; it’s about using it as a catalyst to create opportunities. By embracing challenges and rallying your team around a shared vision, you can modernize, innovate, and scale without losing sight of your long-term goals.

Finale

Stepping into the CTO role is not just a promotion; it is a transformation. It is about shifting from tactical execution to strategic vision, from overseeing code to orchestrating culture, and from delivering features to shaping the company’s future. The challenges you face will be bigger, messier, and more complex, but the rewards are just as extraordinary.

If there is one overarching lesson from my journey, it is that leadership is not about having all the answers. It is about creating an environment where the right answers can emerge. And when they do not, remember this: make a decision.some times you don’t even know whether it is right or wrong, as CTO, you need to make the call. That is what sets this role apart from being an Engineering Manager or Tech Lead. You cannot say, “I don’t know!” You are not in the position to defer or wait for clarity. Sometimes, you will be in uncharted territory where no one has the answers. You are the pioneer. You need to make the mistakes and fail fast, learn from them, and lead the way forward.

Whether it is balancing legacy systems with innovation, building a pipeline of leaders who amplify your impact, or aligning technical possibilities with business realities, the key is staying adaptable, collaborative, and focused on the bigger picture.

Remember, a company is not just its technology. It is the people, the culture, and the shared vision that drive everything forward. Growth does not happen in isolation. Like I said before, the head cannot grow bigger than the body. Every part of the organization, including engineering, product, marketing, and beyond, needs to work in harmony to sustain success. If things do not align, know that it is not always your fault. Even as CTO, there are limits to your power.

To me, the heart of being a CTO lies in navigating this delicate balance. It is about embracing chaos to find opportunities, fostering collaboration to drive alignment, and leading with humility and purpose. It is about empowering others, inspiring innovation, and building something that truly matters.

So, enjoy the climb. The view from the top is not just about what you achieve. It is about the people and the legacy you leave behind.

Prologue

So you made it through the Tech Lead phase, nice job! Maybe it felt like you’d finally learned how to juggle chainsaws and not lose a limb. You handled tricky code reviews, tight deadlines, and got your team working together without too much drama. Now it’s time for the next challenge: becoming an Engineering Manager (EM).

This is where the job description adds a friendly, invisible disclaimer: WARNING: This Role Contains More Humans Than Code. As a Tech Lead, you got a small taste of people management. But as EM, you’re stepping into a bigger world: less time in your code editor, more time talking, listening, and helping people grow.

Before start, I will suggest to look at these posts Charting Your Path Beyond the Code and Stories behind “Charting Your Path Beyond the Code”. It will build more context for this one.

Act 1: Broader Horizons

As an Engineering Manager, you still care about architecture and code quality, just don’t expect to do all the coding yourself. Your main mission: create an environment where your engineers feel supported, can tackle tough problems, and come out smiling (most days, anyway).

I remember, I tried to keep coding just as much. I thought I could manage people and still commit a bunch of PRs every week. Guess what happened? I got behind on my 1:1s, communication suffered, and I missed clues that one dev was feeling totally burned out. After that, I learned to put the team’s needs first. Turns out, giving them the spotlight makes them stronger, and frees you up to help in more meaningful ways.

Shift from Doing to Enabling

You’ll write fewer lines of code, but have a bigger impact. Instead of fixing every bug yourself, you’ll guide your engineers to find their own solutions. Think of it like being a soccer coach rather than the star player. You’re making sure the team is set up to win, not scoring all the goals by yourself.

Communication is Key (No, Seriously)

Some engineers will tell you exactly what’s wrong. Others will be quieter than a powered-down server. As an EM, you’ll learn to listen for what’s not being said. Create safe spaces, be patient, and show you care.

I remember one time when a developer who never raised any issues suddenly quit. I tried to get to the bottom of it, but he was already mentally checked out. At first, I didn’t understand, he’d received raises, worked on interesting tasks, and seemed happy enough. It wasn’t until after he left that I realized the issue.

That experience hit me hard. I realized I needed to make 1:1s more relaxed, honest, and intentional. It’s amazing how much you can prevent with open, judgment-free conversations. And yes, you’re probably still wondering what went wrong with that guy. Turns out, he wanted to pursue a completely different path in his career, but he never mentioned it, and I never caught it.

Since then, I’ve made it a point during one-on-ones to ask questions like: “Do you feel like you’re on the right path?” or “Would you like to explore another role, frontend, backend, DevOps, or something else entirely?” It’s a simple addition, but it has made a world of difference in helping my team feel heard and supported.

And, as I’ve said before, one-on-ones are a whole topic in themselves. Maybe in the future, I’ll write about that in a more dedicated manner too.

Act 2: The Wild World of Stakeholders

You’re not just dealing with your team anymore. Product managers, HR folks, other department heads, they all want a piece of your time. Think of it like being the director of a theater production. You’ve got actors (your team), stage crew (HR), scriptwriters (product managers), and producers (upper management), all with their own priorities and demands. The actors need clear direction, the crew wants to ensure everything runs smoothly, the scriptwriters are pushing their vision, and the producers are focused on the budget and audience reception. Your role is to coordinate all these moving parts, ensure everyone stays aligned, and keep the production on track, while also onboarding new cast and crew members seamlessly into the mix. It’s about managing expectations, resolving conflicts, and bringing diverse goals together into one successful performance.(I really out done my self with this example)

I remember a product manager who wanted a major new feature built “yesterday.” (oh I hate this phrase btw) Meanwhile, the team was still struggling with performance issues on existing features. By calmly explaining or better communicating the trade-offs and showing some quick data (like the current bug counts and capacity), we found a compromise that didn’t burn everyone out and pushed the release date further. A little transparency and empathy can go a long way.

Learn to Speak “Business” and “Engineer”

You’re the translator now. Business talks in Cha-Ching, you know? Money, and timelines; engineers talk in tickets, complexity and technology. Your job is to make sure both sides understand each other without rolling their eyes too hard. If you can keep everyone aligned, you reduce pointless debates and nightmares.

Prioritize Like a Pro

You can’t say yes to everything. Sometimes, you’ll have to tell the product team, “Not this sprint,” and back it up with reasons. Or you might have to let your engineers know that they can’t refactor half the codebase right now. By focusing on what truly matters, you help the team deliver consistently without burnout. Less chaos, more actual progress.

I remember one time when a product manager approached me with an urgent feature request. The team was already stretched thin, so I had to say, “Not this sprint.” They weren’t happy and escalated the issue, insisting it was critical for an upcoming launch. On top of that, it was tied to a government regulation, and skipping it could mean missing a massive growth opportunity for the company.

“OK, let me see” I said. Instead of leaving it at a no, I set up a meeting with the PM, Architect and the team to revisit the request. (Spoiler: the team wasn’t happy about the situation either, so tensions were already high.) After hashing it out, we realized we didn’t need the full feature, just a much simplified version to meet the immediate requirements for the launch. By reassigning a few tasks, temporarily shifting some engineers, and delaying a less critical refactor and some projects, we made room to deliver the essentials on time.

The PM got what they needed, and while the team did feel a bit of pressure, we avoided burnout and safeguarded the company’s future. It was a great reminder that saying no doesn’t have to be the end of the conversation, it’s often the beginning of finding a better solution.

Act 3: Career Counselor and Culture Builder

Your job now includes helping your engineers grow, not just in technical skills, but in their careers. That might mean suggesting a conference to attend, sharing books that inspired you, or simply talking through their long-term goals.

I remember one engineer who was on the fence about moving from Frontend to Backend. After a few chats, we reached out to a team working on a related project and asked if they could share their work with her. She started sitting in on their meetings and contributing to smaller tasks. You want me to say: “A year later, she thrived as a Backend Leader, taking on multiple projects and driving real impact.” Right? But here’s the twist, she discovered a passion for Data Engineering after a month or two. At the end of that year, she was designing models and loving it. The thing is, helping people find their path is incredibly rewarding. It’s not about walking the path for them or pushing them in a direction, it’s about showing them the options and being there to support them as they explore. When you see someone thrive because you gave them space and encouragement, it’s the best feeling ever.

One important thing to mention here is that you need to remember these are also resources the company is investing in. In my case, she was successful in all the positions she moved through and completed her tasks well, but she wasn’t fully satisfied until she found her true calling. What I’m saying is that you need to be vigilant about these transitions to avoid wasting time or resources. It’s all about finding the right fit quickly, so remember to fail fast and adjust as needed.

Feedback Early and Often

Don’t wait for some “performance review” months away. If something’s off, talk about it now and in private. Also, remember to call out good work in public if possible. Positive feedback can be a huge morale booster. I once saw a developer beam for hours after I publicly thanked them in a team meeting for refactoring a tricky chunk of code. A little kindness goes a long way.

Roll with the Punches

Change happens, priorities shift, top engineers leave, new hires join mid-sprint. It’s okay. The best EMs adapt and keep everyone calm. Once, we lost two senior devs right before a release. I panicked could not sleep that night thinking how can I do this, I sat with team and other EMs and talk about how we can rearrange the workload to buy time till we can find replacements, and everyone chipped in. We got through it and even learned how to handle chaos more gracefully next time.

Finale

Becoming an Engineering Manager is about seeing the bigger picture. It’s not just about the code, it’s about the people writing it and about people wanting those code to be written. The challenges will be different, messier, and more human. But helping your team grow and succeed is worth every awkward conversation and tricky meeting.

I always have this in my head from Archibald Wheeler about Einstein’s work: “There were three additional rules of Einstein’s work that stand out for use in our science, our problems, and our times. First, out of clutter find simplicity. Second, from discord make harmony. Third, in the middle of difficulty lies opportunity.”

For now, enjoy this phase. Embrace the humans, the chaos, the learning. That’s what being an EM is all about.

It’s late, and the office lights are dimming around me. I’m supposed to be heading home, but I’m frozen in front of my monitor, thinking about how I got here the ups and downs. I’d been a leader in the past, high-level, strategic stuff, then took a detour, change the country, new world so I start at the begining, went down the latter into pure coding became a developer and tried to start building my way up again. after a while working there it happened, I became Tech Lead. I still remember my time as a Tech Lead at that company, with a team depending on me. The lessons I’m about to share weren’t handed to me in a proper manual; I learned them through messy, real-world experiences. At the time, I was just trying to survive and help others thrive.

These stories are the hidden chapters behind the advice I’d later put into that “Charting Your Path Beyond the Code” blog I suggest reading these two parallel works better like that.

Disclaimer: Names and Genders in these stories are changed in favor of hiding the real identities, and not all the stories are from one company, and they are a really, REALLY small part of the whole picture.

Act 1: New Challenger Enters the Ring

When I first stepped into the Tech Lead role, I still had that developer’s hunger for the latest frameworks and libraries. I remember one particular time when I introduced a slick new library, something I’d discovered over a weekend. I was excited, and I assumed the team would share my enthusiasm.well… Instead, I got blank stares and polite nods, “good enough” I said. A few weeks in, half the team struggled with the tool’s learning curve, and the other half silently reverted to the old way of doing things and skipping the library totally. We lost valuable time, and morale dipped, I was angry and frustrated.

That was my first big lesson: keeping pace with technology doesn’t mean hauling the entire team into a cutting-edge labyrinth. Our development speed suffered because I chased something shiny without measuring its impact. I learned that “staying updated” doesn’t mean “adopting every new trend.” It means understanding what truly benefits your team and product, not just what’s cool on Reddit.

Then there was my internal battle: I craved coding. Late at night, I’d sneak in and commit features myself. But one morning, Dave, one of our backend developers, pulled me aside. “Hey, I noticed you’ve been making a lot of PRs at odd hours. Are we missing something? We could help if you let us.” His words stuck in my head not because they were harsh, but because they exposed my fear of losing technical touch. I realized I was hogging the spotlight instead of enabling the team. From that point on, I let them take the lead on coding tasks, and I focused on what they needed to succeed and offered help when needed. I still coded occasionally to keep my skills sharp, but my main codebase became the team itself, their structure, their growth, their environment.

Act 2: Rules and Regulations of the Game

I soon learned that no two engineers are alike. Take Ryan, our junior front-end dev, who thrived on constant feedback and daily check-ins. Meanwhile, Priya, a senior backend engineer, hated frequent interruptions; she needed long stretches and quiet focus. Early on, I tried a one-size-fits-all approach, everyone got the same kind of feedback in the same style of meeting. The result? Ryan felt ignored when I gave too little direction, and Priya felt micromanaged when I checked in too often and in of the one-on-ones said she is thinking about what did she do that I am checking that much with her. It took time, lots of one-on-one chats, and a few missteps and failures before I learned how to calibrate my approach to each individual. Understanding their different work rhythms was like deciphering a puzzle: once I got it right, the team clicked and trust start to buildup.

I also had my lack of knowledge with the difference between telling and showing. Once, during a heated sprint review, some stakeholders were pushing for impossible deadlines. I felt the urge to just nod and accept, then later complain to the team (feels familiar, we all been there). Instead, I calmly explained why it wouldn’t work, pointing to data, past results, and the impact on code quality. By transparent communication, even when it was uncomfortable, I set an example. The team saw I wouldn’t throw them under the bus or silently accept poor conditions. Over time, that earned me their trust. They realized I wouldn’t just talk about good leadership, I would try to live it, even if it meant delivering tough news upward.

Well, Communication worked both ways, too. In one retro, I asked, “What did we mess up this sprint?” The silence was deafening. So I confessed, “I probably made a few assumptions that weren’t clear, I know them and we suffered, and I learned how to work with Bernard our PO, but Can someone point them out? Let’s see if you guys also felt them” That broke the ice. People felt safe to say, “I didn’t understand why we pivoted mid-sprint,” or “I was unsure about the requirements for feature X.” By consistently inviting and valuing their voices, we avoided a lot of confusion down the line. And no one ever left a meeting without clarity again, even if it meant scheduling a follow-up. Yes, more meetings can be tedious, but fewer misunderstandings saved us from countless headaches.

Perhaps the hardest pill to swallow was about micromanagement. I tried it briefly, thinking it would ensure quality. It did the opposite. By hovering over their shoulders, I smothered their creativity and signaled that I didn’t trust them, it almost cost losing team. When a critical feature got delayed because my interference slowed them down, I realized my mistake and also realized that my manager did the same to me at that time, you know? I gave it forward, you can name it the chain of micromanagers hahaha (crying inside). I learned that setting clear expectations and then stepping back let them work with confidence. I’d rather fix mistakes later than never let them develop their own problem-solving abilities.

Act 3: Don’t Forget to Breathe

As weeks turned into months, I saw patterns emerge. Every time we adapted to a new requirement or navigated a sudden shift in priorities, it felt we grow stronger. I had failures and successes, not all in one job, but you need to learn somehow. For example, when a client demanded a pivot that cut our timeline in half, I explained the situation honestly: “I don’t love this change either, but here’s why it’s happening.” Seeing the team’s frustration turn into proactive brainstorming because I was part of a team not a manager that cares about his paycheck (well I care, but I cared about theirs too, and honestly without them none of this were there soooo, anyway…), it proved that transparency and empathy could turn into teamwork.

I started investing in my own growth as a leader, reading books and talking to mentors and talking to monsters, you read it right!, maybe that dark side for later right? Right. When I encountered a tough personnel issue, like a senior dev who was brilliant but demotivated, I reached out to a people that I believed in or proven that they worth taking advice from. I tried to delegated tasks more wisely. Instead of fixing bugs myself, I’d say, “Hey, Diego, you’ve got a great eye for detail. Could you dig into this one?” I watched him light up at the trust. He solved the bug, learned from it(I hope).

Uncertainty…, I remember I was worried about this all the time about not having answers and A manager should have it right? Well in this situation you should not (each level of management begs some different level of being sure of some levels you need to answer base on some percentage of certainty, but that is a story for another time) Instead of pretending that I had all the answers, I’d say, “I’m not entirely sure, but let’s figure it out.” The team respected that honesty. Over time, we formed a culture of collective problem-solving. It was no longer about one hero coder or one leader, it was about all of us pulling together.

I remember noticing that Sasha, who was usually energetic and talkative, seemed withdrawn during a planning meeting and also some task were taking longer than usual. I asked in our one-on-one if everything was okay (IMPORTANT NOTE: keep in mind the line never pass the line it can go south really fast, been there done that, so if you are going to do this I expect you to have fair share of HR experience, if not really try to get some education about how to approach these problems if needed I can write about my experiences on another blog). Turns out, she’d been dealing with a tough personal situation we didn’t go deeper than that, but By giving her space and support rather than just demanding productivity, I earned her trust and I think her loyalty. She bounced back, and I learned that leading humans isn’t just about tasks; it’s about recognizing that life doesn’t stop at the office door.

Finale

In the end, these stories formed the backbone of the lessons I will eventually share in my blog. What you read here and will read later, about balancing hands-on work, understanding your team, leading by example, communicating clearly, avoiding micromanagement, embracing adaptability, investing in mentorship, and practicing empathy, didn’t come from theory at least not most of it. They were forged in late-night coding sessions, awkward silence in retrospectives, difficult conversations, and tough client calls that tested my limits.

When I finally wrote that blog “Charting Your Path Beyond the Code”, it felt like distilling a messy, living process into something coherent and helpful. But behind every bullet point was a real moment, my team staring at me, my pride challenged, my expectations realigned. This leadership journey taught me that guiding a team isn’t about perfection not even near that. It’s about learning from each messup, staying curious, staying humble, and building the trust that allows everyone to grow.

These stories are the untold chapters behind the these advices well not all of them I’ll not spill the beans NOW. They’re a reminder that every leadership principle comes with a backstory, a time when I failed, learned, and chose to do better the next time around.