Overcommunicate. Focus on problems. Don’t work after hours.
Leadership Lessons Nobody Writes Down
I’ve climbed a few rungs of the leadership ladder — from individual contributor to Director of Engineering and Polish Site Leader.
Today, most of my work isn’t about pull requests. It’s about people — leading team leads, tech leads, and other managers.
Over the years, a few lessons keep coming up in my 1:1s with them. I wrote some them down.
They’re subjective, a bit random, and might not all fit your context — but maybe they’ll make you pause and think.
1. Prioritization — Exchange Urgent for Urgent
Every engineering leader eventually faces it: the “super-urgent” request that lands out of nowhere.
You push back:
“Sure, we’ll handle it first thing next sprint.”
They insist:
“No, this one’s top priority.”
And so you cave — skip lunch, stay late, keep your team safe by absorbing the chaos yourself.
Here’s a better play: run the urgency test.
“I’m working on a project that will generate 50k USD in new revenue.
Doing your request now delays it by a week.
I’m happy to make that trade — can you confirm we want to?”
Protect the value of your time.
If you exchange 'urgent' for 'urgent,' you hand prioritization back where it belongs — to management.
If you silently accept, you become the system’s overflow buffer.
And if your time is always the first to sacrifice — maybe it’s not as valuable as you think.
2. The Problem is a Solution Gap or Education Gap
Platform engineering sounds noble: enable product teams, multiply output.
Reality is messier.
“You’re blocking us.”
“Your standards slow us down.”
Or the classic: “It doesn’t work for me.”
Most platform engineers respond by bulletproofing — adding logs, edge-case handling, fallbacks. Admirable. Costly.
I once led a mobile team that spent months building a beautiful test-sharding system: multiple devices, custom CLIs, reboots, retries — engineering art.
But the real issue? Not infrastructure. Knowledge.
We misunderstood the testing hierarchy. Once we clarified that end-to-end tests sit on top of the pyramid — not at the base — the “months-long problem” disappeared in days.
Many technical problems are disguised as education gaps. Before you spend months bulletproofing, maybe you need to run an education session.
3. Always Overcommunicate
In platform work, your job isn’t done when the system works — it’s done when people know how to use it.
Same for product engineering: shipping to prod isn’t the end; adoption is.
I’m often involved in conflicts, where people ask for help in a problem that was long solved.
“I don’t know how to spin up a microservice. Help !!111oneone”.
“We solved this problem 7 months ago. You clearly haven’t read our slack message! 🤬”
(Fun fact from my own experience: a few of such messages were sent either on Friday afternoon, or as a 10th response in a chat’s thread)
Here’s the thing—many of us tend to think we're doing the most important thing in the company, and everyone is waiting for our announcements. But in reality, much of such messages are lost in the day-to-day noise.
If your work is really that critical, you must announce it in multiple places at different times. A Slack announcement, email comms, an all-hands presentation, or public demo sessions are the bare minimum here. Ideally, if you follow up with key stakeholders a few days after the announcement.
People must be bored and fed up with your information. Only then do you know it was delivered.
Side Note
I just released the workbook From Engineers to Operators – AI Strategy Workbook for Engineering Leaders.
It’s based on my experiences and helps engineering leader to adopt AI practices in their work.
4. Don’t Work After Hours
If you’re in a ten-person startup fighting for survival — fine, all hands on deck.
But 90% of us aren’t in such a place. We are regular employees, sometimes being granted a microscopic piece of shares or stock options. Yes, it’s still within our business to make the company successful—it pays our bills, brings us stability, and does good for society.
Doing great work doesn’t mean sacrificing your evenings.
If you’re constantly working nights and weekends, something’s broken — scope, process, prioritization, or trust.
Only when you limit your working hours and availability will you start thinking about what’s important, what’s not.
You automate. You delegate. You simplify.
You build systems that work without heroics.
Late nights aren’t proof of dedication.
They’re proof of poor design.
Companies don’t need heroes. They need boring predictability (read: You Need No Heroes).
5. Be Less Busy
We love to “lead by example.”
So we stay busy to look committed.
Wrong example.
Your job is not to be the hardest worker in the room.
It’s to make sure the room works.
If you’re always rushing, your team stops approaching you.
They don’t want to “bother the boss.”
You lose visibility. They lose guidance.
Instead, reward outcomes, not input.
Model calm, not chaos.
Show that deep work and availability beat constant motion.
It’s not just about sanity — it’s about thinking clearly.
Kahneman described two modes of thought:
System 1: fast, automatic, reactive.
System 2: slow, deliberate, strategic.
When you’re perpetually busy, you live in System 1 — firefighting, not leading.
The busier you are, the less you think.
The less you think, the faster you move in the wrong direction.
That’s not leadership.
That’s productivity theater.
(read more: Hard Work Is Overrated)
Final Thought
Leadership isn’t about doing more.
It’s about creating space — for clarity, for others, for thought.
So:
Swap urgent for urgent.
Overcommunicate. Educate.
Focus on real problems.
Don’t work after hours.
And for everyone’s sake, be less busy.