Thanks Captain Obvious - Just Don't Be An A**hole

Leadership advice is everywhere, but.

Threads, books, courses, TED talks, frameworks, pyramids, quadrants, canvases, principles, checklists.

But after years of being a Developer / Tech Lead / Manager / everything in between, here's the uncomfortable punchline I keep coming back to:

Much of leadership starts from a brutally simple principle:

"Thanks Captain Obvious - just don't be an a**hole."

And sure, it sounds superficial... until you look closely and realize how many people fail at exactly this.

We read articles about psychological safety while publicly mocking colleagues' ideas.

We repost quotes about empowerment and then micromanage code reviews.

We celebrate team ownership while hoarding decisions.

The problem isn't knowledge.

It's interest.

It's empathy.

It's habit to dismantle.

It's the willingness to see the human being, both on the other side of the desk and especially behind your own.

And I'm not innocent either.

I'm writing this while replaying a highlight reel of all the times I failed people - the times I interrupted, dismissed, rushed to solutions, hid behind architecture, or simply didn't listen. I still regret some of those moments. And I know the next mistake is just around the corner, waiting to teach me something else about myself.

But maybe that's the point:

Leadership is not about perfection.

It's about noticing when you screwed up - and choosing to do better next time.

The Ridiculous Obviousness Behind Leadership Advice.

Let's take a tour of some universally celebrated principles and translate them into plain English.

Empower your team.

➡️ Let people do their job.

Stop solving everything for them. Stop being the human bottleneck.

I already wrote this in Authority and Accountability, where authority goes down but accountability goes up. A concept so simple it should be stapled above every manager's monitor.

Practice active listening.

➡️ Shut up. They're talking.

You don't need a workshop for this. You need self-awareness.

Create psychological safety.

➡️ Don't make people feel stupid.

If you roll your eyes at a question, congratulations - you just became the problem.

Lead by example.

➡️ Do the things you expect others to do.

I already wrote this clearly in Build a Rocket with LEGOs: great developers - and great leaders - make complexity disappear instead of showing off with it.

Avoid over-engineering / stay pragmatic.

➡️ Solve the real problem, not the one inside your head.

I already wrote this in What Sits and What Fits and expanded it in Stay in the Problem Space: clarity beats cleverness, always.

Help the team grow.

➡️ Care enough to invest in people.

If you don't genuinely want them to succeed, they will feel it. Immediately.

Leadership Isn't Learned - It's Revealed.

After years of reading, practicing, and messing up, here's the truth I can't unsee:

Leadership doesn't come from frameworks.

It mostly comes from how you see - and treat - people.

You can read 200 leadership books.

You can memorize every model.

You can preach every principle on LinkedIn.

But if you don't fundamentally care about:

what your teammates fear,

what they hope,

what drains them,

what motivates them,

what they need from you...

...then none of it matters.

Leadership is not a skillset you can copy-paste.

It's a lens.

A way of perceiving humans before processes.

A willingness to adapt yourself before asking others to adapt to you.

And most importantly:

You cannot lead people you are not willing to understand.

This is the foundation underneath all the "obvious" advice - the part books rarely emphasize, because you can't teach someone to care.

Some Real Examples (a Bit Too Real).

When someone delivers poor work

Bad leader:

Ugh, they're not good enough.

Actual leader:

Did I communicate poorly? Is the context unclear? Are they overwhelmed?

When a junior makes a mistake

Bad leader:

"We can't afford this."

Actual leader:

"Mistakes are tuition. Let's look at it together."

When the team is drowning

Bad leader:

"Push harder."

Actual leader:

"What can we remove? Who needs support? What am I missing?"

And yes - I've been both versions.
Sometimes in the same week.

P.S. These phrases are examples to make a point; each of the "bad leader" statements I indicated could be said constructively and coherently in the right context. What matters is the attitude and intention behind the words. Leadership is not an if-else statement.

Why Don't More People Do This Then?

Because it's far easier to talk about leadership than to actually live it.

Applying these principles requires two things most people avoid like Friday evening refactoring:

Self-awareness - looking your impulsive reactions, ego, and insecurities in the face.
Not everyone wants to discover that the real bottleneck isn't the team... it's them.

Vulnerability - admitting you might be wrong, that you don't have all the answers, that you need to learn when to stop.
It's much more comfortable to hide behind processes, metrics, architectures, and "best practices."

The truth is "just don't be an a**hole" sounds trivial until you realize it demands constant work on yourself.
And that work - the work on yourself - is the part of leadership you can't delegate, automate, or copy-paste from a book.

That's where most people stop.
Not because they don't know what to do - but because actually doing it takes more courage than it seems.

The Ironic Twist.

All the leadership lessons we admire - empathy, clarity, autonomy, pragmatism, communication - are the same things we celebrate in great developers.

If you read my previous articles, you'll notice a pattern:

• The Truth About Test Coverage -> clarity beats vanity metrics.
• Iterative Contract Testing -> simplicity beats complexity.
• Colleague-Based Testing -> your code must be understandable to others.
• Asynchronous Batching -> optimize for collective efficiency.

Replace "codebase" with "team", and they just became leadership mantras.

Turns out the line between a good architect and a good leader is thinner than we think.

Conclusion.

I've made enough mistakes to write a trilogy.

I'll make more.

You will too.

But if there's one thing I've learned - something no article, no podcast, no book ever taught me explicitly - it's this:

The quality of your leadership is measured by how people feel after interacting with you.

The truth is no framework can save you from yourself.

People don't remember your title, your decisions, your roadmaps.

They remember how you made them feel while all of that was happening.

Not being an a**hole isn't a leadership principle.

It's a principle of humanity applied to work.

Everything else - processes, metrics, models - is just maintenance.