And Why I’m Not Chasing a CTO Role

Hey there!

I’ve been writing weekly issues of my newsletter every single week for two years now. (This article was originally posted there.)

While most of my pieces focus on the practicalities of engineering leadership, this one is slightly different.

If you’re looking for another piece of practical advice, feel free to skip it and save your time.

This is just my personal story.
With some facts from my life not directly related to software engineering.

I’m writing this mainly for myself.
To reflect on where I am, professionally and personally.
And to assess the direction I’ve been driving myself toward.

This Year Was a Blast for My Engineering Career

When I look back on the past months, it’s been a ride.

I learned multiple aspects of AI.
I wrote a few production apps in fully agentic mode.
I drove the adoption of these practices in the organization I’ve been leading.

I manage an engineering site in Poland.
The office. The people. The processes. Hiring. And more.

I also took the lead over full platform engineering
DevOps, Backend, and Frontend
serving Infrastructure and DevEx practices for over a hundred engineers across the company.

I did some open source work and, thanks to AI, came back to almost everyday coding after years of stagnation.

I wrote a book.
I create this newsletter.
And I had my talk at the Infoshare conference.

I genuinely love software engineering. I’m also very excited about connecting this world with product and business, and about building solutions people actually love.

I Could Have Been a CTO, But I’ve Chosen Not To

At some point in their career, almost every engineer thinks about becoming a CTO.

I did too.
Especially in my early days.

Looking only at my experiences from this year, I’m pretty sure I could already be one.

In fact, I’ve rejected a few such propositions.

Worldwide impact.
Stock options.
Raw power.

Plus the fact that I genuinely love what I do professionally.

Am I dumb to reject such a life
or the life that might come after an IPO?

Maybe.
Who knows.

But today, I’m choosing not to dedicate 100% of my life to my profession.

I don’t even work full-time at my job.

Instead of traveling the world, visiting the biggest tech conferences overseas, and being fully immersed in the tech bubble, I choose to be a 9–5 part-time worker.

And to play other personas for the rest of my time.

I Am a Runner

This year, I started a coached program with up to six trainings a week. For a few years now, I’ve been doing Obstacle Course Racing mixed with trail running. I love it and I’m curious how far I can go.

I won’t lie: the program was hard. My baseline in January was challenging, as I was coming back to sport after a foot fracture that had healed just a month earlier.

Over the year, I did almost 300 trainings: strength, endurance, obstacle/ninja, and a lot of running.

For the first time in my life, my training was so well structured. Intervals on flats and ascents, fartlek runs in terrain, and my first experiences on an athletic track. My favorite runs are 10–15 km in hilly terrain, ideally with moody conditions: early morning, fog, maybe a bit of rain.

I raced Spartan Race, Barbarian Race, and Runmageddon, as well as trail races like Tatra Trail. Distances ranged from 6 km to 25 km, on hills and flats, in forests, in 30-degree heat, and in -1°C frost. I also tried sprint-like races with 400 meters and 10+ obstacles.

At my peak, I was the 29th Elite Racer in Poland and 15th in my age group. I think I can do slightly better; there’s still some margin. But even this performance is extremely satisfying, especially for someone who does software engineering for a living.

But running wasn’t only about racing.

I ran through many magical places: city runs through Bern, uphill runs in the Alps above Innsbruck, trail runs through Swiss villages, and countless dawn runs through silent, empty, foggy forests near my home. And one bucket list item: uphill running on Copenhagen’s Copenhill.

I Am a Photographer

I love photography. I keep learning composition and light. I shoot with my phone, GoPro, my small Sony RX100, and a larger OMD EM-5. I enjoy shooting vibrant cities, landscapes, golden hour light, sunsets, and sunrises.

But my ultimate project is this: I take my camera, usually the RX100, sometimes a GoPro, and I shoot during my runs.

I shoot from a runner’s perspective.

The mood I love most comes from early morning fog in forests, but I also enjoy sleepy cities just after sunrise or colorful sunsets.

The rule is simple. I stop for a few seconds, don’t even pause my Garmin watch, point, shoot, and keep running.

This project is about showing how beautiful running can be. Literally.

This year, I printed my photos and framed them for the first time. Since then, I’ve known that one day I want my own gallery dedicated to photography through a runner’s eyes.

I Am a Ninja

I already do quite a lot of sport, yet there’s another derivative of my training: ninja.

If you’ve watched Ninja Warrior, that’s exactly it.

I’m too cautious to go all-in; the risk of injury in this discipline is already too high for me. But I’ve learned a lot: jumping between bars, salmon ladders, rope variations, and other ninja obstacles.

After each of my trainings, I spend another 15–20 minutes practicing ninja skills. This year, I felt confident enough to take part in local ninja competitions, which I did. And I absolutely loved it.

I Am a Present Dad

Running, photography, coding. That’s already a lot about me.
Yet there’s still plenty of space in my heart for family.

It doesn’t come naturally to me. I’m a lone wolf, a thinker, a dreamer. I was also raised in a classic family model, where women handled childcare and home, and men focused on work.

Still, I’m proud of being a present dad to my five-year-old daughter. From changing diapers, to doctor visits, to feeding, to simply growing up together, I put a lot of effort into splitting these responsibilities equally with my wife.

But it’s more than logistics.

My daughter and I train ninja together. We’ve done kids’ OCR races like Spartan Kids. We listen to vinyls from Linkin Park, Trolls, AC/DC, and Eminem. We have a bucket list of all science centers in Poland. When my wife is away for a weekend, we build Hot Wheels tracks across the entire apartment.

We laugh a lot. We argue a lot. We respect each other’s boundaries, moods, and emotions.

We also took our first solo trip together. No car, no mom. Just a backpack and hundreds of kilometers of travel.

Yes, my daughter still defaults to my wife. She shows her more emotions, prefers hugging her, and complains about me to her. But I know I have a place in my child’s heart too.

Being a present dad is hard.
But it’s also extremely rewarding.
Like nothing else.

I Love Science, Design, and Art

I was fortunate to travel a lot this year: Bern, Copenhagen, London, and multiple smaller cities and towns. When I look back, these are some of my core memories 👇

Reading Carlo Rovelli’s White Holes and Michio Kaku’s Hyperspace and Quantum Supremacy, and visiting Einstein’s home in Bern. That trip also reminded me of visiting CERN during its open days in 2019.

A few months later, I visited London and randomly stumbled upon IBM’s quantum computer. I wasn’t aware it was there; I literally noticed it while wandering the city.

London brought even more. Passing by Orwell’s home awakened memories of 1984, a book that deeply moved me a few years ago. Then the Wright brothers’ Flyer replica, the Greenwich Observatory, Da Vinci’s notes in the British Museum, Raphael’s paintings, and Michelangelo’s sculptures. All revisited after a few years away from London.

And the absolute cherry on top: Maman, Louise Bourgeois’ spider, returned to Tate Modern. Another bucket list item checked, after seeing her spiders in Tokyo, Amsterdam, and San Francisco.

I already mentioned Copenhagen’s Copenhill, but that trip was much more. I’m fascinated by Scandinavian design, so seeing the city and visiting the Danish Architecture Center were unforgettable experiences.

I Love Life

On one of my return trips, I took out my notebook and wrote random words and memories from this year. In this summary, I’ve probably covered only 20–30%.

My Nuuna notebook holds much more:

• Seeing a huge moose during a solo early-morning run in an empty forest
• Blausee, the blue lake in Switzerland
• Running at 5 a.m., before sunrise
• My first OCR race 21 km in sub-zero temperatures
• Personalizing my office with printed photos, plants (and first blooms!), and bookshelves full of inspiring books
• Swimming in a lake for the first time in my life
• Driving thousands of kilometers across the Alps
• Taking 4th place in a ninja competition
• Writing more code in the last months than in several previous years combined
• Returning to trail running after my foot fracture
• Chocolate factories in Poland (Wedel) and Switzerland (Läderach)
• Traveling across Poland for OCR races
• The sound of birds in an empty forest at 6 a.m. during a run
• Spending an entire weekend, from morning till night, with my daughter at the Ninja European Championships

And much, much more.

End Words

So what’s the point of this summary?

I’m someone who tends to fully immerse myself in things. I deeply buy into company missions and visions. I believe in changing the world. I always wanted to be better, more impactful.

But over time, a few things changed. The birth of my daughter. Then, moving to part-time work. These initial cracks slowly became doorways to new paths in my life.

I believe I’m still very impactful as an engineering leader and that I still do good for the world and the people around me. But today, I’m more than that.

I’m a runner.
A dad.
A photographer.
A husband.
A ninja.

I’m sensitive to art, science, and the world around me.

Titles and impact are no longer the only measures of my life. They’re just part of a much richer whole.

I’m leaving this here as a message to myself.
To my past self and my future self.

If you made it to the end, thank you for reading.
I hope you found a bit of inspiration for yourself.

All the best,
Mirek

How to build fast without breaking trust in the age of AI

Every engineering team I know faces the same dilemma:
We want to move faster — but we don’t want chaos.
We want prototypes in hours—but we also want safety, testing, and standards.

AI has made speed cheap.
Reversibility is what’s now scarce.

So how do we keep our creative rhythm without breaking our systems?
The answer lies in designing our work environment like a two-room building.

The Studio

The door is always open. Instruments are everywhere.
People hum, sketch, riff. Some ideas are wrong in the first five minutes — and that’s fine. You keep moving.

The Studio rewards exploration, not perfection.
The currency here is taste, not tests.

You want prototypes that are fast, disposable, and built entirely from the blocks your system already trusts. The rule: what happens in /prototyping stays in /prototyping — until we decide otherwise.

In the Studio, ideas start as prompts, not tickets.

When your PM walks in with a sentence — “I need a quick dashboard to track how many users completed onboarding last week” — you don’t ask for a PRD. You hand them rails:

Prompt to the Engineer Agent

“Inside /prototyping, mocked data only.
Build two variants of the onboarding dashboard.
One bold, one simple but efficient.”

By lunch, you’re curating variants, not debating frameworks.
By evening, you’ve learned which shape feels right — and you delete the rest.
No guilt. No debt.

The discipline of the Studio:
not permanence, but clarity.
not speed for its own sake, but cheap change until the right shape appears.

The Factory Floor

The Factory is different.
It’s bright, labeled, and quiet.
Everything has a home; everything has a test.

Work that enters here must be worthy — ready to survive scale, observability, and real users.

The Factory rewards patience and punishes drama.
If the Studio is jazz, the Factory is Bach: precision, structure, deliberate tempo.

Here you rebuild beside the prototype — not from it.
You freeze the shape, not the code.
You keep the design, not the shortcuts.

A PM produces a Delivery Plan — the bridge between worlds:

“This UI becomes these components;
these states become these tests;
these events become these metrics.”

Then an Engineer rebuilds it under the Factory’s rules:
existing components, proper schemas, passing CI, instrumented telemetry.

When it’s done, the prototype is deleted. The door shuts. The Studio is clean again.

Why This Matters

AI didn’t just give us new tools — it collapsed the distance between idea and artifact.

The bottleneck isn’t typing anymore; it’s clarity and containment.

Without rails, speed turns into entropy.
Without freedom, discipline turns into stagnation.

Every healthy team needs both rooms — and a sturdy door between them.

The Studio is where we learn.
The Factory is where we deliver.

And your job as a leader is to make that door work — 
to let ideas flow fast, but only truth flow out.

Learn More

This essay comes from my book,
From Engineers to Operators — AI Strategy Workbook for Engineering Leaders.
It’s a practical field guide to leading safely and effectively in the AI era.

You can get it from here: From Engineers to Operators — AI Strategy Workbook for Engineering Leaders

Looking for some practical hints? Check out my series:

• Prototyping with AI Agents (pt.1)
• Prototyping with AI Agents (pt.2)

The Studio and the Factory Floor was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Lessons From Teams That Actually Get Leverage

A year ago, a friend of mine — CTO of a mid-size product company — ran an experiment:

“I’ll buy GitHub Copilot for everyone. We’ll build code with AI. We’ll go faster.”

The result?
About 10–15% loved it. They used Copilot for tests, docs, mock data, and even challenged their own assumptions. The rest barely touched it. Some were openly skeptical.

When asked why, the answers were blunt:

• AI-generated code felt low-quality.
• Debugging or extending it often took longer than writing from scratch.
• The only “safe” use cases were boilerplate.

Adoption flatlined.

Meanwhile, somewhere else…

In the background, a handful of engineers weren’t waiting for permission. They were:

• Covering large projects with hundreds of automated tests and delivering in weeks what used to take months.
• Prototyping features in hours inside the company’s own stack — not slide decks or vibe-coding apps, but working previews in staging or production envs.
• Navigating legacy code and fixing issues in minutes, with AI agents committing for them.

While the average team stalled, these outliers moved 10× faster.

The Invisible Work Behind the Scenes

Here’s the truth: the magic wasn’t in their prompts.
It was in everything before the prompt.
The team had invested months in “boring” infrastructure — documentation, standards, automated tests, and small deployable services.

When AI arrived, it seamlessly integrated into their workflow.

What these engineers understood is something most leaders forget: AI doesn’t replace engineering discipline; it rewards it.

The hidden cost of “AI everywhere”

Across the industry, CEOs and CTOs feel the same pressure:
They see Base44, Lovable, and n8n demos — products built in hours — and ask, “Why can’t our engineers do that?”

They respond by buying tools, spinning up AI guilds, and launching Slack channels full of prompt tips.

But tools without foundations create hype, not leverage.
Instead of compounding value, you accumulate fragile experiments.

From hype to leverage

If you’re an engineering leader, your real job isn’t to make everyone adopt AI overnight.
It’s to identify and strengthen the foundations that turn AI from gimmick to force multiplier:

• Automated tests so AI can iterate safely.
• Documentation and standards so it doesn’t hallucinate.
• Feedback loops under ten minutes so you can grant autonomy without drowning in reviews.

Get those right, and adoption stops being a gamble. It becomes inevitable.

The Seven Foundations of AI Leverage

Think of these as your readiness checklist — the invisible scaffolding that makes AI worth it:

A Personal Lesson — and Five Things I Learned

I ran my own experiment: I built a full-stack app where 99% of the +100k LoC were generated by AI (by the way, you can see it live on leadersmetrics.com).

Here are five lessons you can apply right now:

1. Operators, Not Coders
   Your role shifts from typing lines of code to orchestrating context, constraints, and feedback loops. The better you define those, the better AI performs (read my full coverage here).
2. Guardrails First, Speed Second
   Every time we tightened tests, documentation, and non-functional requirements, the quality of AI output jumped. Guardrails aren’t bureaucracy; they’re acceleration lanes.
3. Break Work into Micro-Tasks
   Large, vague asks produced nonsense. Small, crisp asks produced near-perfect code. AI thrives on micro-scopes with explicit success criteria.
4. Feedback Loops Are Your New “IDE”
   We stopped thinking in terms of commits and started thinking in terms of feedback cycles. The faster we could run a test, lint, or deploy check, the faster AI learned what “good” looked like.
5. Culture Eats Tools for Breakfast
   The teams and leaders who saw AI as “draft mode” and reviewed output with curiosity improved exponentially faster than teams who saw AI as a one-click solution or a threat.

These lessons aren’t about AI coding tricks; they’re about leadership habits. The more I acted like an Operator instead of a coder, the more AI felt like leverage instead of overhead.

The Bigger Shift

When you stop seeing AI as a shiny tool and start treating it as a force multiplier for engineering quality, everything changes:

• You stop blaming the tool for hallucinations.
• You start improving the environment it runs in.
• You move from “experimenting” to “operating.”

That’s the real leap: from engineers to operators.

Closing Thoughts

AI won’t turn a messy codebase into a masterpiece.
But it can turn a disciplined team into a force of nature.
Start with one foundation, run one experiment, and watch how fast the flywheel spins.

Want the Full Playbook?

This article is inspired by the free preview of my new workbook, From Engineers to Operators — AI Strategy Workbook for Engineering Leaders.

Inside you’ll find:

• Foundations for AI success — why it works for some teams but fails for others.
• The Operator shift — how engineering roles are evolving in Software 3.0.
• Actionable frameworks — Context × Constraint Matrix, Operator Loop, Adoption Scorecard.
• Workshop kits & templates — run sessions that embed practices into your team.
• Proven artifacts — the Spec, Eval, and Context setup used to build Leaders Metrics.

If you’re serious about leading your team through the AI era — beyond hype, toward leverage — check out the book here and start turning experiments into impact.

Why AI Works for Them but Not for You was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to Be a More Successful Software Engineering Leader

Becoming a leader is a journey, not an event. Once you’re promoted from an individual contributor role, you’ll quickly realize that your technical knowledge is just a fraction of the skills you need as a manager.

Your daily challenges will pull you between three worlds — technology, product, and people management. The good news is that this journey can be incredibly rewarding. It’s not just about scheduling tasks related to code development; it’s about building connections between business, real-life solutions impacting hundreds, thousands, or even millions of people, and solving hard technical problems.

The bad news is that this profession is so vast in its demands that you could spend the rest of your life learning it. That’s where I want to help. Today, I’m giving you a 30-day course that walks you through the nuances of engineering leadership.

The content is designed to make your work more fulfilling while increasing your impact and success as an engineering manager, tech leader, engineering director, and beyond.

By the end of 2024, the course will remain free of charge for all readers.

Practical Engineering Management

Almost two years ago, I launched Practical Engineering Management to help first-level engineering leaders be more impactful in their roles. Since then, I’ve written nearly 200 articles.

Even though I regularly refine or remove articles that no longer meet my quality standards, the volume of public content can still feel overwhelming.

As an engineering leader, I know you don’t have the time to read it all. You must act fast, be hands-on, manage people, collaborate with product teams, write and review code. The last thing you want is to dig through multiple pages of archives from an engineering leadership newsletter.

That’s why, one day, I sat down, wrote all my content on Post-its, and tried to organize it.

Seeing themes emerge — like Engineering Strategy, Leading Change, Leadership Styles, and DevOps Culture — was satisfying. It also helped me identify gaps, such as missing insights on career progression, expectations management, and remote work environments, which I’ve covered in recent posts.

While this clarified my roadmap for future content, it still didn’t solve the problem of accessibility.

One solution was to distill my content for those just beginning their journey as engineering leaders. I’ve been running this Medium publication, where the content is less detailed than my regular newsletter but serves as a perfect introduction to leadership topics.

If this sounds like a good starting point for you, check out my blog content overview: New to Engineering Leadership? Let Me Help.

Better Engineering Leader Course

However, if you’ve been leading software engineers for a while, the articles on this blog might feel too general.

That’s why I created Better Engineering Leader. It’s a series of 30 daily lessons covering the core pillars of leadership: people, technology, and product. This course is tailored for leaders eager to delve deeper into the nuances of their work.

The original idea was to structure the most important content from Practical Engineering Management into a chronological course that touches on each of these pillars.

Each lesson includes a brief introduction to the topic, practical exercises, and links to extended content in my newsletter. Each exercise takes about an hour to complete.

Because every engineering leader is at a different stage in their journey, I recommend exploring these lessons in the order that resonates with you most. Focus on the areas where you’d like to improve your skills.

Here’s the complete list of lessons (you can find them all in my newsletter subpage: Better Engineering Leader):

People

• Day 1: Building Trust with Your First 1:1 Meetings
• Day 4: Mastering Feedback for Effective Leadership
• Day 7: Managing Expectations: Focusing on Skills, Impact, and Attitude
• Day 10: Setting Principles for Effective Team Leadership
• Day 13: Top Ten Factors of Productivity
• Day 16: Managing Teammates’ Growth and Expectations
• Day 19: Tackling Resistance to Change Using the Problem Solving Framework
• Day 22: Crossing the Chasm — Leading Effective Change in Engineering Teams
• Day 25: Mastering Cognitive Biases as an Engineering Leader
• Day 28: Building Safety Leadership Through Neuroception

Technology

• Day 2: Assessing and Building a Strong DevOps Culture
• Day 5: Managing Technical Debt with Clarity and Strategy
• Day 8: Introducing SLA, SLO, and SLI for Engineering Leaders
• Day 11: Non-Functional Requirements (NFRs)
• Day 14: Identify and Eliminate Engineering Waste
• Day 17: Practical Solutions to Track Your Goals as an Engineering Leader
• Day 20: Mastering the Signals of Information for Engineering Leaders
• Day 23: Building Your Engineering Strategy
• Day 26: Defining Strategic Blocks for Your Engineering Strategy
• Day 29: Transforming Organization through Simplification, Slowification, Amplification

Product

• Day 3: Four Factors Essential to Your Company’s Success
• Day 6: Product Analytics for Engineering Leaders
• Day 9: Role of Engineering in Product Organization
• Day 12: Mastering Product Challenges with a Problem Solving Framework
• Day 15: Changing the Way Problems Are Solved
• Day 18: Using PR/FAQ to Translate Tech Work into Product Value
• Day 21: Deciding Which Problems We Should Solve
• Day 24: Maximize Your “20% Time” for Tech Debt and Technical Initiatives
• Day 27: Shifting from Top-Down to Center-Out Leadership

Wrap-up

• Day 30: Becoming a Better Engineering Leader: The Next Steps

End Words

As 2025 approaches, the demands of technology leadership are evolving. Engineering leaders are expected to bridge the gap between people, technology, and product while driving impact and innovation in a fast-paced, ever-changing environment.

I hope this 30-day journey will help you be more successful. Each lesson is a stepping stone to becoming a leader who inspires trust, builds high-performing teams, and delivers meaningful results.

Whether focusing on strengthening relationships, optimizing your technical strategy, or aligning your team with product goals, the key is to keep learning and adapting.

Better Engineering Leader Ahead of 2025 was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Gen-Z, Remote vs Office, QA Shift-Left, and Fewer Engineering Managers

The last few years have been a rollercoaster for the engineering industry. The shift to remote work caused by the COVID pandemic, mass hiring, VC funding enthusiasm, and later, mass layoffs, budget cuts, and overall tech market shock. Oh, and the rise of (Gen)AI 🤖.

These are just a few hot topics that most of us have recently lived on. However, the software engineering industry has transformed much more over the past decade, with new trends reshaping how teams are structured, how quality is maintained, and how leadership roles evolve.

It’s impossible to cover everything that has changed in recent years, so I’ve picked five main topics that are particularly relevant to the group I most often target in my writings — low and mid-level engineering leaders.

Let’s explore some of the key trends that define our work today:

• Gen-Z becoming a significant part of the global workforce
• The Office vs. Remote debate
• The shift-left approach in QA and the decline of dedicated testers
• The reduction of engineering leader roles in favor of individual contributors
• The shift from software engineering to product engineering

If you manage one or multiple engineering teams, understanding these trends will help you make better decisions and build a more sustainable culture.

Gen-Z in the Workforce

Disloyal, lazy, entitled, and overly sensitive — these are some stereotypes describing Generation Z, a demographic that will soon become a significant group of employees.

By 2025, Generation Z will comprise 27% of the global workforce, bringing new expectations around work-life balance, growth opportunities, and a desire for authenticity in leadership.

As engineering leaders, this shift presents both challenges and opportunities. Gen-Z employees often display lower loyalty to employers, expect growth and training to occur within working hours, and place higher value on transparent compensation. For engineering teams, this means adapting leadership styles to align with these new values.

If you are an older-generation manager (like me — a millennial), some of these attitudes and values may seem very different from ours. However, we must understand that Gen-Z entered the workforce during significant economic instability, including the 2008 financial crisis and the COVID-19 pandemic. These experiences have influenced their approach to employment. They prefer financial security over status games. The gig economy (e.g., Uber) and the platform economy (e.g., Upwork) made them comfortable with having multiple jobs rather than relying on a single income source.

Gen-Z is proficient in technology, often automating tasks more efficiently than older generations. They also prefer digital communication and immediate feedback, valuing real-time discussions over long, formal reviews. To manage this new workforce effectively, engineering leaders must focus on creating environments that support flexibility, clear communication, and opportunities for professional development — all while fostering a sense of mission and purpose within the team.

One key insight here is that Gen-Z’s expectations for work-life balance are more pronounced than previous generations. They value clear boundaries between work and personal time and prioritize mental health. This suggests that leaders who foster a supportive, balanced, and inclusive work culture will likely attract and retain top talent from this generation.

Do you want more? For some insights and hints, you can read my article: How to Manage Gen-Z

The Return-to-Office Debate

When the pandemic locked us in our homes, many thought that 2020 would begin a truly remote-first world. Today, almost five years later, with companies like Amazon mandating a return to in-person work in 2025, the debate over remote versus office work has resurfaced.

The COVID-19 pandemic accelerated globalization and remote work. Coding languages and software design patterns are universal globally, meaning engineers can write the same code for an overseas employer and earn twice as much.

On the other hand, companies can hire less expensive specialists from less developed countries. For example, shifting a dev team from the Bay Area to Poland reduced costs by 40% while maintaining performance.

But it’s not always about money. Amazon’s stance is that in-office collaboration fosters better innovation, culture, and learning. However, the question remains whether this decision represents a step backward, especially for tech workers who thrived in remote-first environments during the pandemic.

The pandemic showed us how teams can function effectively remotely, but it also highlighted the limitations of remote work, such as the lack of nonverbal communication cues and the blurring of work-life boundaries. In many ways, engineering teams are naturally suited to remote work—most of our tools and processes have long been remote-friendly. However, office environments can still play a key role in fostering collaboration and cultural alignment, which are harder to achieve in fully remote settings.

Studies show that remote workers can be more productive than their office counterparts. For example, Stanford University research found that remote workers were 9% more productive than office workers, according to Psychology Today.

Another study reveals that out of an 8-hour day, the average worker is productive for only 3 hours. For the remaining time, they read the news, browse social media, search for new jobs, or discuss non-work-related topics with co-workers.

Here’s the dilemma: As a leader, do you want your people onsite, available for 8 hours but only working effectively for half that time and slacking for the rest? Or do you want them to be slightly more productive but out of your direct control?

As an engineering leader, the focus should be on outcomes, not just hours spent. Hybrid models, where teams come together for strategic meetings but remain remote for focused work, seem to balance individual flexibility and collective creativity.

Ultimately, organizations must assess whether their teams’ productivity and culture benefit more from in-person presence or if remote work can continue to support their goals.

If you want to explore more in the debate on Office vs. Remote, check my latest newsletter issue: Why Do Companies Drag Us Back to the Office?.

I’ve also shared some tips on How to Build Remote-First Culture.

The Decline of Dedicated Testers

Quality Assurance practices in software engineering have shifted significantly in recent years, with many organizations moving away from hiring dedicated testers to a QA shift-left approach. This means integrating testing responsibilities into the role of software engineers.

Companies like Microsoft retired their Software Development Engineer in Test roles nearly a decade ago, opting to merge testing and development functions.

Main reasons for doing so were challenges many of us know:

• Who should write unit tests — engineers or testers?
• “Us vs. them” dynamics, with differing goals, schedules, QA gatekeeping, and “ticket ping-pong.”
• Complex testing systems that still required senior engineering help.
• Inverted testing pyramid with the majority of heavy E2E tests.

The rise of DevOps and continuous delivery models lead to faster and more automated testing processes. Manual testing simply cannot keep up with the pace of modern software delivery, where top-performing teams deploy code multiple times a day with low failure rates.

In this environment, quality is no longer something that gets “checked” after development; it is embedded throughout the entire software delivery process.

One critical insight here is that this trend is part of a broader movement toward DevOps culture, where the lines between development and operations blur.

According to the DORA 2023 Research, the highest-performing organizations deploy code 46 times more frequently and have 2,555 times faster lead times than low performers. Automated tests and rapid feedback loops are key drivers behind this success, which is why engineering teams must embrace testing as part of their development responsibilities.

Engineering leaders must now ensure that their teams are equipped with the tools and knowledge to own the quality of their code. Automated testing, CI/CD pipelines, and real-time feedback loops are critical in achieving faster, more reliable releases.

So, what happens to testers who may become redundant? Such transformations don’t occur overnight and often take months or years to phase out the QA team, providing ample time to rethink the role’s future.

Manual testers often transition to QA engineers, automating work that takes hours into scripts executed in minutes. Their role may then evolve into that of an evangelist or agent of change, creating solutions (templates, infrastructure) that all engineers can use. They ensure every developer knows how to run tests and can do so in minutes.

Over time, it may become infrastructure engineering work. For example, optimizing CI/CD pipelines to cut testing execution time by sharding and parallelizing tests. (A few years ago, one of my teams reduced execution time from a few hours to less than 30 minutes by moving testing infrastructure to cloud solutions).

Wait… does this mean a QA Engineer becomes a Software Engineer?

In short, yes. Many QA engineers already do engineering work: writing scripts, setting up testing infrastructure, building automated pipelines — it’s code development. Yet many organizations keep dedicated QA Engineer roles, often paying them 50% to 70% of an engineer’s salary and expecting less from them than from regular engineers (you are good at writing automations but not so good at writing production code).

To explore more, check my newsletter issue: Do You Need More Testers or Better Tests?

Fewer Engineering Managers, More Hands-on Leaders

Another notable trend is the reduced demand for engineering managers. With tech companies facing budget cuts and flattening hierarchies, there has been a shift toward hiring individual contributors over managers.

For example, in his letter, Amazon CEO Andy Jassy noted,

“we’re asking each S-team organization to increase the ratio of individual contributors to managers by at least 15% by the end of Q1 2025. Having fewer managers will remove layers and flatten organizations more than they are today.”

Does this mean that management is obsolete? I think it’s rather a focus on having better engineering managers, not necessarily more of them.

Here are the top sins of engineering leaders:

• Micromanaging — merely assigning tasks, not allowing collective decision-making, and not building overall awareness of why their engineers do what they do (reminder: the role of technology in a product company is to solve customers’ problems).
• Not contributing to product discovery — the role of engineering is not only about delivering features. It’s also about discovering the best way to solve customer problems.
• Not being hands-on — it’s not just about contributing to code development. Being hands-on also means stepping into an engineer’s shoes — understanding their real struggles, developer experience, etc.
• Not managing expectations — a semi-annual performance review is not enough. Engineering leaders must constantly work on course correction, growing teams’ skillsets, and finding the most impactful initiatives for their people.
• Being gatekeepers, not enablers — rather than finding a solution or trying to better understand the problem, they “protect” the team until they get 100% of the requirements for the work to be done.

Today’s engineering managers are expected to be more hands-on, contributing directly to the team’s output while also handling leadership responsibilities. According to DORA research, organizations with transformational leadership — where leaders are both visionaries and hands-on — are more likely to achieve high performance.

Leaders who can effectively manage talent, set clear goals, and align technology with business strategy will be indispensable, even in leaner organizational structures. The focus is now on outcomes — helping teams deliver value to customers, rather than just completing tasks.

For a deeper analysis, check my blog post:

How to Be a Better Software Engineering Leader

Product Engineering

The role of technology in a product company is to solve customers’ problems. Engineering is not a cost center but a profit center. Software engineers don’t work for the Product team; they are part of the Product team.

All of these statements emphasize that our focus should be shifted from building code to building products. It shouldn’t be a surprise — with high-level programming languages, no-code solutions, generative AI, and mature frameworks, it’s easier than ever before to build fully working solutions.

Transforming engineering teams to operate within a product-centric model is not just a shift in processes — it’s a change in mindset. As engineering leaders, our role is to ensure that we are not just building more efficiently but also solving the right problems and making strategic decisions that align with the overall product vision.

There are a few key principles that help with that, focusing on:

• Changing the way things are built through frequent, small releases, product instrumentation, monitoring, staged rollout & early validation.
• Changing the way problems are solved through being aware that the “requirements” are hypotheses; being a partner to the Product organization who helps with finding solutions, not just points out gaps in their reasoning; translating “technical” problems into true business value and prioritizing them along with other product tasks; taking part in the discovery process where ideas are validated much quicker.
• Changing the way decisions are made about which problems to solve through building awareness that an engineering leader is a product leader too, so we contribute to product roadmaps; ensuring that engineering teams know and understand the product vision; focusing engineering teams on outcomes, not features to build; building engineers’ awareness of customers and users and collecting qualitative feedback.

For specific actions and an overview of the book where the concept of the Product Operating Model was introduced, I invite you to my previous blog post:

The Role of Engineering in Product Transformation

Final Thoughts

The software engineering landscape is shifting, and as leaders, it’s crucial to stay ahead of these trends. Whether it’s adapting to a new generation of workers, navigating the remote vs. in-office debate, evolving QA practices, or refining management styles, engineering leaders must embrace change while maintaining focus on the key goal: delivering products that solve real customer problems.

Those who can adapt and guide their teams through these transitions will thrive in the decade to come.

As we move forward, the role of engineering leadership will continue to evolve, but one thing remains clear: leaders who prioritize outcomes over processes, foster a collaborative team culture, and embrace technological and generational shifts will be best equipped to navigate the challenges ahead.

Do You Want to Be a Better Engineering Leader?

I have a quick announcement.

On October 21st, I’m launching “Better Engineering Leader,” a free-of-charge email daily course that distills two years of writing from Practical Engineering Management into a focused, six-week journey.

If you want to join, check details about the course here: Be Better Engineering Leader Ahead of 2025

You can also explore more content for engineering managers on practicalengineering.management. You will find practical strategies for effective engineering leadership.

Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

The Changing Engineering Landscape and How to Stay Ahead of It was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

The role of technology in a product company is to solve customers’ problems. Engineering is not a cost center but a profit center. Software engineers don’t work for the Product team; they are part of the Product team.

With these statements in mind, there is no better way to build successful engineering teams than to understand how the product organization should work.

To help with that, I always recommend following Marty Cagan, a founding partner at Silicon Valley Product Group and author of great books like “Inspired,” “Empowered,” and recently “Transformed.” Personally, I give these books as welcome gifts to every new engineering manager working with me.

In his materials, M. Cagan introduces “The Product Operating Model” — a framework that outlines the essential components and practices for building successful product-first, customer-centric organizations. This model emphasizes the importance of aligning the company around the goal of consistently delivering valuable products to customers.

To transform the organization into a Product Operating Model, there are three core aspects we should go through:

• Changing the way things are built,
• Changing the way problems are solved,
• Changing the way decisions are made about which problems to solve.

In today’s article I want to explore our role as engineering teams in each of them.

Changing the Way Things Are Built

Transformation to truly product model organization starts with how things are built there. We cannot consistently deliver valuable products to customers with a waterfall-like approach, releasing only a few times per year. We must push things quickly and be even faster in learning about what we’ve delivered.

In his book, M. Cagan highlights four key aspects of a successful product organization:

• Frequent, small releases
• Product instrumentation
• Monitoring
• Staged rollout & early validation

Frequent Releases

One of the key factors of successful product organizations is the ability to deliver new value to customers as often as possible. DORA research says that “Elite Performers” can deploy on demand, multiple times a day if needed. Their change lead time (from committed to deployed) is less than one day.

Cagan’s guidance is this — If you cannot do continuous delivery, you should be able to release things at least once every two weeks. It’s nearly impossible to build a product which people love and need while iterating on it only a few times a year.

Tech & Product Instrumentation

When your SDLC processes enable the company to push changes to customers frequently enough, you must also build a capability of understanding what value you are delivering to them. It often happens that the brilliant idea the Product Team had is something customers either don’t need or don’t know how to use.

That’s why each functionality in your product should have at least basic analytics. Yes, it is the Product team’s responsibility to define them. But reality isn’t always like this. In such situations, I encourage you, as an engineering leader, to build a culture where your teammates understand how their product is being used.

Monitoring & Observability

Frequent releases raise stability and overall quality risks. This is common feedback from engineering teams who are expected by management to push to production more often. Even if they could technically release on demand, they are reluctant to doing so. They fear losing control over stability and taking responsibility for possible incidents.

The common answer to that is to bring more tests. Implement full testing pyramid, invest in Shift-Left practices, introduce some smoke testing, chaos testing, etc. Indeed, this can be a good strategy, especially if the organization relies too heavily on manual testers and does a lot of back-and-forth between software engineers and QA engineers (I wrote more about it here: Do You Need More Testers or Better Tests?).

But the truth is that you cannot cover everything with tests. Sooner or later, you will reach the plateau, and more tests will only bring bigger mess rather than peace of mind (growing execution time, the number of tests that must be maintained, or increased test flakiness).

That’s why, next to good testing automation practices, we also must build monitoring capabilities to detect problems before our customers do.

Staged Rollout & Early Validation

When you have good test automation as well as observability in place, there is one more practice to complete this picture. You need to find a way to throttle your release noise and reduce the risk of “global” disruption of your product. Absorbing everyday changes to the product your customers use is way too big a cognitive load for them. And here is where release throttling comes to light.

When the product is used by a big customer base, organizations introduce different ways for a controlled rollout process (percentage rollout, early access beta channels, blue/green deployment, etc.). All of these, mixed with good observability practices as well as product analytics, will give the company full control over released features and insight about the value it generates for customers.\

Read more

If you want to explore these ideas in depth, I invite you to read my newsletter issue: The Role of Engineering in Product Model Transformation — Part 1: Changing the Way Product Is Built. You will find there more examples and references to the content that can help you with this step of Product organization transformation.

The Role of Engineering in Product Model Transformation - Part 1

Changing the Way Problems Are Solved

Improving the efficiency of our SDLC processes is a critical part that opens endless possibilities. But it’s not a goal on its own. If we stop our transformation here, the engineering organization becomes just a more efficient feature factory. We will push more code to production, build more features, and have automated, optimized CI/CD pipelines, but it won’t necessarily generate corresponding value for customers.

Not Requirements, but Hypotheses

In a classic “feature factory” setup, there is a chain: a stakeholder requests a feature, which is then designed by a designer. UI mockups are then translated to requirements (or, in the worst case, they are requirements), which engineers have to meet.

But here’s the trap. We live in an extremely complex and dynamic system. As the company grows, there are countless challenges, opportunities, and customer requests. The product is getting more complicated, often with independent features, domains, or entire product lines.

Neither the CEO nor other business leaders are oracles. They may have high-level ideas and needs, but it’s nearly impossible to keep up with what’s latest in UI/UX or technology. If you still use the word “requirements” in your work, these are most likely “hypotheses.” Each time you get a requirement to build something non-trivial, it’s no more than just a belief that this feature will bring customers value. We see its true value only after we push it to production and start collecting some data.

Don’t Build Features, Solve Problems

Empowered product teams shouldn’t get a list of features to build but problems to solve with desired outcomes. This is a way of building a sense of ownership, where the company incentivizes not the input — how hard people work — nor the output — how much they produce — but the outcome — what value they deliver. It requires giving teams enough autonomy and context to solve problems independently (it’s an example of Center-Out Leadership, which I described some time ago).

Whenever possible, be a partner to the product, not an adversary. When discussing work that has to be done, your job is not about looking for gaps in the PM’s reasoning but finding the solution for a given problem together. Rather than asking “what are exact requirements for case X,” you can suggest how you would solve that case with your know-how and toolset.
I wrote more about it on: Focus on solutions, not problems.

Bring Your Problems to the Table

Too often, engineering and product exist like separate worlds. The product provides a list of features to be delivered, and the tech team takes responsibility for the tech stack — ideally in their spare 20% of time dedicated to maintenance work.

Some tech debt can be addressed within that time — updating dependencies, refactoring, bug fixes, improving automations, etc. But not everything. Some of these things are too big or too strategic to develop without product or business involvement. They are too important to address only when we have time, i.e., when all product tasks are closed.

Your job is adding technical problems to the company’s pool of challenges. You build tech stack telemetry not only to diagnose errors but also to highlight problems before they grow big and bite your customers. You build an alerting system to get feedback faster than customer support agents. Your dashboards should also drive business decisions, not just look fancy on a big TV screen in the DevOps room.

Delivery and Discovery

If a company uses its engineering workforce only to build and deliver things, it loses one of the critical ingredients. In empowered product organizations, engineers also participate in identifying the right solution to build. These people work with technology all the time, so they often know best what’s now possible. Rather than telling them what to do, engineers should be given problems to solve with enough context so they can find the best solution available.

There are two sides to quick iterations and prototyping practices. On the one hand, your engineering team must be familiar with concepts like MVP or PoC and their objectives. They need to understand that when building these, they are in the “discovery” phase, where some tradeoffs are necessary (e.g., time over quality to some extent). However, drawing the line between the discovery and delivery phases is also important. It’s no secret that many MVPs or even PoCs are released to production and stay there in their current form for a long time.

Read more

To explore these ideas in depth, I invite you to read the 2nd newsletter issue: The Role of Engineering in Product Model Transformation — Part 2: Changing the Way Problems Are Solved. You will find there are more use cases and references to the content, which will help you change the way you solve problems.

The Role of Engineering in Product Model Transformation - Part 2

Changing the Way Decisions Are Made About Which Problems to Solve

Out of the three transformations: 1 — building products, 2 — solving real problems, and 3 — deciding which problems to solve — the last one seems to depend the least on us, engineering leaders.

In some organizations, this can be true. If the tech team is seen purely as a cost center, not a profit center, engineers are at the end of the command chain. They are just given tasks to accomplish, seen as resources to allocate and utilize. In such transactional relationships, there is little space to influence product decisions (I wrote more about Transactional Leadership).

But even in such situation it doesn’t mean you cannot influence on which problems should be solved first. Let’s explore that.

You Are a Product Leader Too

As a technology leader, you don’t work for product leaders; you are part of the product leadership. Your team is not a cost center but a profit center. This means it’s the product (customers’ needs) that drives technology, but the technology that enables the product (its growth and/or expansion).

Okay, so what?

If technology enables the product, it means that engineers often know the latest possible solutions to the company’s challenges or customer problems. This is why you should find a way to influence the company’s product strategy.

Product Vision and Engineering

The reason your company exists is that it pursues a product vision that somehow improves customers’ lives. Your job as an engineering leader is to ensure that your company’s vision is well understood by your teammates. The vision should unite tens, hundreds, or thousands of engineers with a single goal: make the vision happen.

Product Strategy and Engineering

As per M. Cagan’s “Transformed,” while the product vision focuses on the future, the product strategy is about identifying the most important problems to solve now.

There are always too many things to focus on at once, and addressing all of them simultaneously is unproductive, distracting, and dilutes our efforts.

As an engineering leader, you will also have plenty of things requiring attention: refactoring, replatforming, rearchitecting, performance issues, bugs, and more. Very often, you (the low — or mid-level engineering leader) know what needs to be done in technology and why. But you should not be given carte blanche to do what you want. First, you must do your homework and structure your tech tasks.

I wrote plenty of articles that can help you with that:

• Ten Types of Technical Debt — use this for classification and prioritization of things you need to address in technology.
• Ten Types of Software Engineering Waste — a good classification focused on IT value streams, very much aligned with DevOps culture.
• Engineering Strategy Framework — this framework will help you identify and classify tech initiatives from a long-term perspective. Strategic blocks used for classification (I wrote a separate article about that) will help you not only with levers in technology but can also be used successfully for the entire product and business.
• Practical solutions to track your goals — use this as inspiration for building dashboards and data insights for your technical goals.

Outcome, Not Output

“In most feature-team companies, the product strategy is literally to try to deliver as many features as possible for the different stakeholders. Which is to say, there really isn’t a product strategy at all.”

— “Transformed” by Marty Cagan

Even if the product strategy says, “We will deliver X features,” in reality, those are X bets that stakeholders hope will bring the organization the expected outcomes (cash, growth, customer satisfaction, etc.). In addition to delivering these features, we must also apply telemetry to understand if the expected outcomes were delivered.

Know Your User

Outcomes and product initiatives — although they should focus on bringing value to customers — don’t have to come from upper management. Some of these ideas can come directly from engineering teams. But to do that, you must ensure your team is customer-centric (I mentioned this in the DORA research summary).

One way of doing this is ensuring some level of fluency in product analytics, which I believe each engineer should possess. However, alongside quantitative insights, engineering teams should also have some qualitative data.

There are many ways to achieve this. The company can collect reviews via platforms like Trustpilot, Apple/Google store, or surveys directly integrated with the product. This data should then be available to engineering teams so they understand what customers think about the product and what the biggest problems are.

In my past experience, I also participated (as an engineering representative) in shadowing sessions and interviews with customers.

Read more

To explore these ideas in depth, I’m inviting you to read the 3rd newsletter issue: The Role of Engineering in Product Model Transformation — Part 3: Changing the Way Decisions Are Made About Which Problems To Solve. You will find there are more use cases and references to the content, which will help you influence which problems should be solved first.

The Role of Engineering in Product Model Transformation - Part 3

End Words

Transforming engineering teams to operate within a product-centric model is not just a shift in processes — it’s a change in mindset. As engineering leaders, our role is to ensure that we are not just building more efficiently, but also solving the right problems and making strategic decisions that align with the overall product vision.

By embracing a culture of frequent releases, continuous learning, and customer-centric problem solving, we elevate our teams from mere executors of tasks to critical drivers of product success.

Remember, engineering is not a cost center; it’s the engine that propels the entire organization forward.

You can also explore more content for engineering managers on practicalengineering.management. You will find practical strategies for effective engineering leadership.

Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

The Role of Engineering in Product Transformation was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

As engineering leaders, we should build a strategy that maximizes our team’s impact on the organization’s success. Simply ensuring that your team’s tasks are executed is not enough; you must develop a comprehensive plan that drives cumulative outcomes.

I covered the role of engineering leaders in such challenges in two recent articles:

• How to Be a Better Software Engineering Leader
• How to Build Engineering Strategy

In both materials, I reviewed ways of improving our work, including building a good strategy, changing our leadership style, reframing problems ahead of us, and making data-driven decisions.

While these initiatives require creativity, time, and effort, not everything has to be built entirely from scratch. One of the practices worth following is DevOps culture, which I would like to explore in today’s article.

DevOps Culture

Despite being ever-evolving, the tech industry has decades of accumulated experience and best practices from thousands of successful organizations worldwide. Although most tech organizations consider themselves unique, they often tackle well-known software engineering problems. This means that many proven practices can also work in your organization — rather than reinventing the wheel, we can adapt existing industry standards to meet our needs.

You can use the DevOps Culture, a mindset that fosters collaboration and shared responsibility to deliver high-quality software quickly and reliably.

DevOps culture promotes a high-trust environment where continuous feedback and learning are valued, leading to improved software quality, quicker releases, and increased resilience. It prioritizes automation and process efficiency, allowing teams to deliver customer value more rapidly and reliably. Ultimately, DevOps culture encourages experimentation and continuous improvement, fostering organizational agility and success.

DevOps Culture Checklist

For a comprehensive resource on building a DevOps culture, I highly recommend reading The DevOps Handbook. Yet, if you need something quickly, here’s a DevOps culture checklist you can use to self-assess your company’s approach to building products:

• High-Trust Culture: Is there a collaborative atmosphere where people are encouraged to take risks? Can team members talk about problems without fear of repercussions?
• Blameless Post-Mortems: Do you conduct post-mortems to learn and improve, not to assign blame?
• Collaborative Learning: Is there a hypothesis-driven culture that promotes experimentation and data-driven decisions?
• Continuous Integration/Continuous Deployment (CI/CD): Is the deployment process quick, routine, and stress-free?
• Automated Testing: Do you have automated tests that run in production-like environments?
• Production Telemetry: Do you have systems to monitor code and production environments?
• Team Independence: Can teams work independently and deliver value quickly and frequently?
• Long-Term Teams: Are teams kept intact after each release to continue iterating and improving?
• Self-Service Platforms: Do teams have access to self-service platforms for deployment and other tasks?
• Predictable Deployments: Are deployments routine, occurring without disrupting business or customers?
• Dark Launch Techniques: Before public release, do you use dark launch techniques to test features with internal teams and small cohorts?
• Fault Injection and Chaos Engineering: Do you conduct planned exercises to test resilience in production environments?
• Risk Mitigation and Security: Are automated tests and peer reviews built into daily work?
• Everyone Owns Quality: Are engineers confident enough to push their changes straight to production?
• Productivity & Stress Levels: Does the organization achieve its goals with minimal rework and late-night firefighting?
• Customer Impact: Do customers notice new features and bug fixes that delight them?
• Outcome and Data-Driven: Are all things developed with clear measurement and success metrics?

For more materials, including a complete checklist and templates in Notion and FigJam, please visit the DevOps Culture Checklist on Practical Engineering Management.

Software Engineering Waste

DevOps culture operates under the assumption that we engage with value streams — processes required to convert an idea into a technology-backed service that delivers value to the customer. The term “value stream” is borrowed from manufacturing and describes the sequence of processes needed to convert raw materials into a finished product. This includes designing, producing, and delivering goods.

Much like how the Toyota Production System transformed manufacturing value streams in the 20th century, DevOps culture and agile practices are transforming software delivery. In 1945, Toyota optimized production by arranging machines close to each other, syncing their speeds to maintain a consistent pace, and producing materials only as needed, transitioning from batch-and-queue to just-in-time manufacturing.

Today, tech organizations are making a similar shift from waterfall development to lean approaches, delivering in small iterations as frequently as possible.

Why does this matter? Just as Toyota’s TPS transformed its manufacturing into a “pull system” (production responding to actual customer orders instead of preemptive production), we aim to do the same with software engineering—building technology in response to customer needs rather than assumptions.

The essence of “pull systems” and Toyota’s TPS is eliminating waste from the value stream. Waste is any unnecessary activity or cost that does not add value to the customer (as opposed to activities that directly create value or are necessary for value creation).

Ten Types of Software Engineering Waste

IT value streams, like manufacturing, contain waste. Despite similarities, manufacturing and software engineering differ significantly.

Manufacturing produces physical goods, while software is something virtual. In manufacturing, we usually produce batches of similar things; software is usually a unique, singular thing available to countless users via infinite cloning. Software evolves much faster than manufactured products.

Here are ten types of software engineering waste that I found helpful when classifying my teams’ work:

1. Partially Done Work and Backlog Mismanagement
2. Extra / Wrong Features
3. Defects / Rework
4. Unnecessarily Complex Solutions
5. Task Switching and Cognitive Load
6. Handoffs and Knowledge Loss
7. Heroics and Rush Mode
8. Non-utilized Talent
9. Waiting
10. Extra, Nonstandard, or Manual Work

For a more comprehensive overview, look at my newsletter’s article: Ten Types of Software Engineering Waste.

The Three Ways — DevOps Culture Origins

The term “Three Ways”, coined more than a decade ago by Gene Kim, underpins the DevOps methodology.

The core principles of Flow, Feedback, Continuous Learning, and Experimentation are foundational to creating efficient and innovative tech organizations. The Three Ways focus on fundamental aspects of the SDLC, ensuring smooth workflow, rapid feedback, and continuous improvement.

Flow — The First Way

The First Way focuses on improving the flow through the technology value streams — the processes required to convert an idea into a technology-backed service that delivers value to the customer.

The core DORA metrics are exactly about that — according to research, the highest-performing engineering teams achieve a change lead time (from commit to deploy) of less than one day, have on-demand deployment frequency, and a failure rate of <5%.

Translating this to the First Way/Flow principle means that such a value stream setup makes it possible to deliver almost bug-free changes within a day whenever we want to do it. It’s almost an instant response to customers’ needs.

Feedback — The Second Way

While the First Way focuses on one-directional flow from engineering to customers, the Second Way is about creating a feedback loop for this process. Here, you build a Control System, as described in Signals of Information For Engineering Leaders, where you use different sources of information to catch and prevent issues quickly.

The ultimate goal here is to build a system in which problems are swarmed, i.e., fixed immediately after they occur, rather than being passed down the value stream or pushed to the customers in the worst-case scenario.

The cost of fixing bugs grows exponentially the longer they remain undetected. It also causes context switching, extra cognitive load (fixing vs. developing new things), and more hand-offs (between engineers and customers/support teams/testers).

Continuous Learning and Experimentation — The Third Way

Once you have optimal flow through the value stream (The First Way) and mechanisms to catch issues as early as possible (The Second Way), you can focus on continuous improvements through experimentation and learning.

The assumption here is that experimentation and failures lead to improvements. Even if we break things and take a step back (lower quality, building a product feature no one needs), our system is optimized to recover quickly. Once we recover, we gain precious lessons that make us better.

One concept describing this is Antifragility. Coined by Nassim Nicholas Taleb, “Antifragility is a property of systems in which they increase in capability to thrive as a result of stressors, shocks, volatility, noise, mistakes, faults, attacks, or failures” (Wikipedia). It isn’t just an ability to recover from incidents or resistance to failure. It’s a concept that draws from these incidents and makes our system even stronger.

If you want to explore Three Ways in detail and get some actionable hints for each way, check out the Practical Engineering Management newsletter issue: The Three Ways: Flow, Feedback, and Continuous Learning.

Practical Hints for DevOps Culture

Contrary to popular belief, DevOps culture is not only about software delivery. With the focus on continuous learning and experimentation, this approach is also great for discovery practices.

Here are some reference materials and hints that can help you with implementing DevOps Culture in practice:

• MVP, PoC, Prototype — quick iterations, reducing waste like: (2) Extra / Wrong Features or (4) Unnecessarily Complex Solutions, data-driven decisions — these parts of DevOps culture are closely tied to the product’s Continuous Discovery practices. Understanding the role and scope of MVPs, PoCs, and Prototypes will be complementary here and help you validate product ideas quickly, so your organization builds products customers need.
• Intro to SLI/SLO/SLA — introducing observability is part of DevOps transformation. Additionally, it’s a good practice to see reliability as a regular product feature. I recommend reading this introductory article to understand it better and set your first service-level objectives.
• Product Analytics for Engineering Leaders — next to observability practices, it’s good to understand how our customers use the product we build. Having such context will help you make the right decisions during implementation. Read this article for hints and good practices for working effectively with product analytics solutions.

How to Address Resistance to DevOps Culture Transformation

Change is not always easy. We often consider changes in tech companies to be purely technological. At first glance, the DevOps culture seems to be about CI/CD, rollout solutions, testing automation, or observability. But in reality, every transformation begins with changing the people involved. This can be challenging because change doesn’t come naturally to humans.

We resist altering familiar routines and fear the unknown. Cognitive biases, company legacy, and culture all contribute to organizational inertia and the tendency to keep things as they are. That’s why we often use crisis as the catalyst for change.

Many engineering leaders face resistance from their teammates in different forms. Here are example symptoms from an excellent document: “Individual Contributors — From Holdouts to Holdups” (link):

• Poor Performer Hiding in the Crowd
• Active/Passive Sabotage
• Aggressive Behavior
• “That’s Not My Job”
• Married to a Tool
• Lone Wolf

How do we deal with each of them?

My approach is to use a structured framework, which I mainly utilize to reframe technical problems. I call it the Problem Solving Framework, built on top of the great book “Are Your Lights On”.

The framework consists of eight steps:

1. Recognizing the problem (What’s the problem?)
2. Defining the problem (What are the facts behind the problem?)
3. Exploring the problem’s depths (What are the root causes of the problem?)
4. Identifying stakeholders (Who has the problem?)
5. Assessing the willingness to solve (Is it worth solving the problem? Is it aligned with broader goals and strategy?)
6. Developing solution strategies (What are options for solving problems? Which are the optimal ones?)
7. Implementing the solution
8. Monitoring and reviewing (Are success metrics defined and achieved through the solution?)

Here’s an example board where I analyze how to tackle the challenge of individuals resistant to change:

For a detailed description of how the Problem Solving Framework can be used when working with people, I invite you to read my latest newsletter issue: How to Work with Teammates Resistant to Change.

Conclusion

In this article, I wanted to summarize some background on DevOps culture and share practical hints that can help you build one in your team or organization.

The content of this article does not exhaust the topic, but I hope it’s a good starter. For a comprehensive resource, I highly recommend reading The DevOps Handbook.

You can also explore more content for engineering managers on practicalengineering.management. You will find practical strategies for effective engineering leadership.

Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

DevOps Culture for Engineering Leaders was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

A Guide for Engineering Leaders at All Levels

If you read the theory behind frameworks for setting goals (e.g., OKRs), you will usually find that strategy and objectives should be cascaded down. This approach starts with the company’s mission and key metrics (KPIs), moves to the company’s objectives, and then translates into product strategy. The strategy then breaks down into granular objectives for teams or divisions.

Yet, the reality differs from the theory. Product strategy is often just a list of product features to implement. It doesn’t include things like tech debt or maintenance, SDLC processes and automations, or ways of working. In some organizations, as an engineering leader, you are the only person who knows what needs to be done to improve overall product quality, time to market, and underlying software architecture. You know when the support ends for your framework version or that your datastore solution doesn’t scale well and needs migration.

In my personal experience, as a Tech Leader (the first-level manager in a company), I owned mobile app platforms. Even though the company’s management knew what product they wanted to deliver, only my team and I knew how to take care of the platforms we built upon (maintenance, architecture, automation etc.).

Being an engineering leader means that you don’t just ensure the execution of product tasks handed to your team. It’s also about building a plan that compounds the outcomes of your team’s work. And for that, you need to have a good plan.

In this article, I will explore tools and techniques to help you build a long-term engineering strategy. Some work best at the organizational level, where Product and Technology collaborate on their challenges. Some can also be successfully applied at the team level and can inspire the rest of the organization from the bottom up.

The Greatest Leaders Have a Plan

Bad leaders execute, good leaders improve, and great leaders compound.

Compounding is not about improvisation but a coherent set of actions in response to strategic challenges ahead. If you aim to build such a plan, there’s no better source of inspiration than Richard Rumelt’s “Good Strategy/Bad Strategy”.

While Rumelt’s work primarily focuses on strategies for entire organizations, it is still relevant to lower-level engineering managers.

Even as a first-level leader (Tech Leader), I have applied Rumelt’s insights to create 12–18-month plans for my team and tech stack. This approach has enabled teams to rearchitect solutions, migrate tech stacks, reduce distractions, focus narrowly, improve quality, and more.

As an Engineering Manager or Tech Leader, you already oversee a portion of the tech stack, your domain, or possibly the entire product. You should have enough context to diagnose issues, establish policies, and choose concrete actions to move forward.

What Is Strategy?

A strategy is a designed response to the challenges ahead.

Good design, according to Richard Rumelt, incorporates three core aspects:

• Anticipation: Observing and learning from the situation.
• Premeditation: Preparing guiding policies so we don’t just improvise.
• Design of Coordinated Actions: Preparing a plan orchestrated in space and time.

The strategy framework, built on these aspects, focuses on three things critical to our long-term plans (Richard Rumelt calls them the “Strategy Kernel”):

• The Diagnosis: Understanding the current situation and identifying the organization’s key challenges.
• The Guiding Policy: Setting out the overall approach the organization or team will take to address its challenges.
• The Coherent Action: Involves a series of coordinated actions designed to implement the guiding policy.

How to Build a Strategy

Here’s the short version — the process involves four steps:

1. Collecting Input: Gathering information about strengths, challenges, opportunities, bottlenecks, current initiatives, and distractions. This information could relate to your team, the tech stack you manage, or problems presented by the organization (stakeholders, management, etc.).
2. Strategic Blocks Grouping: Classifying all the input from the previous step, considering the components of strategy from Rumelt’s book, such as leverage, proximate objectives, using advantages, among others.
3. Build Strategy Kernel: Based on the collected and classified information, formulate the Strategy Kernel — Diagnosis, Guiding Policy, and Coherent Actions.
4. Iterate and Refine: The process of collecting inputs, grouping them, and describing the strategy kernel can take weeks, during which you should modify these boards and share them with the team and other stakeholders until everyone agrees that the strategy makes sense.

For a more comprehensive guide, I recommend checking the content on Practical Engineering Management, where I explore this process in detail: Engineering Strategy Framework.

PEM’s subscribers also get access to a FigJam whiteboard that can help you build an engineering strategy:

Input for Our Strategy

If you seek inspiration and examples of strategic blocks, I also recommend using Richard Rumelt’s wisdom, which lists these points:

• Leverage Objective: A pivotal objective that focuses on what is most critical.
• Proximate Objective: An objective close enough to be feasible despite ambiguity and complexity.
• Weakest Link in Chain: The limiting factor that needs to be addressed first.
• Power of Design: Deciding whether to couple or decouple resources and efforts.
• Using Advantage: Leveraging your strengths and opportunities.
• Riding the Wave of Change: Identifying and assessing early signs of significant shifts in the industry and environment.
• Understanding Inertia and Entropy: Building awareness of:
  - Inertia — the resistance within organizations to making change.
  - Entropy — the tendency for systems and organizations to move towards disorder.

Examples of Strategic Blocks

Here are a few examples from software engineering practices:

Leverage Objective / Fixing Distractors
Removing obstacles that prevent engineers from entering a flow state. This can include noise-canceling headphones in open-space environments or reducing noise in alerting systems so that people aren’t notified by dozens of false alerts per day. It might also involve rescheduling the team’s calendar so every engineer has at least a 4-hour block each day for focused work, or limiting work in progress — “stop starting, start finishing.”

Side note: Flow state is a critical factor in Developer Experience.
Read more about it in Abi Noda’s DevEx framework.

Proximate Objective / Transforming SDLC Processes
The ultimate goal — true continuous delivery or deployment — is often too ambitious to tackle at once. First, you must decompose it into achievable steps, such as good testing practices, rollout and rollback solutions, good monitoring and alerting, software stability, etc. Each of these could be a proximate objective on its own.

In the past, I have described two stories that were decomposed into such proximate objectives:

• Quality Assurance and Software Delivery Processes in Frontend Engineering
• The Evolution of Apps Quality Assurance at Azimo

Weak Link in a Chain / Technical Debt
Classifying technical debt is a true weak-link-in-chain game. There is always something to work on — system decomposition, library updates, refactoring. Your primary job here is identifying the pieces that slow you down the most. For such classification, you can use Ten types of technical debt.

For more examples from the industry and software engineering practices, as well as antipatterns of Leverage Objectives, Proximate Objectives, or Weak Links in the Chain, I recommend checking my article: Example Strategic Blocks for Engineering Strategy.

Your Sources of Information

You can use countless sources of information when building your strategy: 1:1s, people’s feedback, product strategy context, classified technical debt, and more. For inspiration, I recommend checking these articles from Practical Engineering Management:

Signals of Information for Engineering Leaders — sources of knowledge can be classified into three categories: possessed knowledge (what you already know), external sources (what you can observe outside the company), and internal signals (your company’s data, insights, dashboards). Your job as an engineering leader is to a) build a solid base for capturing internal signals and b) use this data to drive your decisions and long-term strategies.

Mastering the Feedback — feedback is a special source of knowledge. It’s not always empirical facts but often just opinions, beliefs, and individual’ perceptions. Even though this information isn’t always quantitative, it is often as insightful as data from your telemetry and product dashboards. It doesn’t mean there’s nothing to change if you're not receiving feedback. It means there is no space to share it with you. As an engineering leader, you must be comfortable with both, giving and receiving feedback.

Structured Sources of Information

DevOps Culture
The tech industry, despite being ever-evolving, has decades of accumulated experience and best practices from thousands of successful organizations worldwide. Although most tech organizations consider themselves unique, they often tackle classic and well-known software engineering problems. This implies that many proven practices can work in your organization as well — rather than reinventing the wheel, we can adapt existing industry standards to meet our needs.

To build your long-term plan, you can use the DevOps Culture, a mindset that fosters collaboration and shared responsibility among engineering and other teams to deliver high-quality software quickly and reliably.

Here are a few factors of the DevOps culture worth assessing in your team:

• An environment focused on a high-trust culture and collaborative learning.
• Development practices with automation, CI/CD, and telemetry.
• Team structure & processes focused on independence and long-term goals.
• Predictable deployment & release management.
• Organizational resilience with everyone owning the quality.
• Orientation on outcomes, rather than tasks.

If you want to do a full self-assessment of the DevOps culture so it’s easier to build your engineering strategy, I recommend checking these materials and templates on Practical Engineering Management: DevOps Culture Checklist.

Tech Debt Classification
Some companies, like Google or Thoughtworks, have developed their classification of technical debt. Using their frameworks should help you find the right blocks for your software engineering strategy.

Here are ten types identified by Google:

• Migration is needed or in progress
• Documentation on projects and application programming interfaces (APIs)
• Testing
• Code quality
• Dead and/or abandoned code
• Code degradation
• The team lacks necessary expertise
• Dependencies
• Poorly executed or abandoned migrations
• Release process

Subscribers of Practical Engineering Management have access to a detailed classification and tools for investigating tech debt. You can get them from here: Ten Types of Technical Debt.

End Words

Building a good engineering strategy for your team and technology is one of the most challenging and time-consuming efforts. Yet, having such a plan allows you to become a truly impactful leader who can make a significant difference.

In my career as an Engineering Director, Head of Engineering, and Engineering Manager/Tech Leader, I developed multiple strategies. The most successful ones took full advantage of the lessons learned from the book “Good Strategy/Bad Strategy” by Richard Rumelt, which I highly recommend as the most comprehensive guide for building strategies of any kind.

I hope the materials shared here inspire you to build your long-term plan and become a leader who compounds their impact.

You can also explore more content for engineering managers on practicalengineering.management. You will find there practical strategies for effective engineering leadership.

Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

How to Build Engineering Strategy was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Micromanagement, Center-out Leadership, Psychological Safety Leadership, and others

The beauty of software engineering comes from the many different ways of solving challenges ahead of us. Our work can be like receiving an unlimited set of LEGO bricks without instructions, just an end goal to achieve. We can be builders, architects, designers, or inventors.

And then we become managers. We set expectations, make decisions, motivate people, and ensure execution—classic, boring managerial work. But that’s not entirely true. As engineering leaders, we can also bring some creativity to our work, e.g., through mixing different styles of managing people.

In today’s article, we will explore some of them, i.e.:

• Micromanagement
• Center-out Leadership
• Top-down Leadership
• Transactional Leadership
• Developmental Leadership
• Transformational Leadership
• Psychological Safety Leadership (based on physiopsychological research and the Polyvagal Theory)

I hope these insights will help you build your unique style for engineering leadership!

Micromanagement

Okay, firstly, let’s face this one since micromanagement is also a style. It exists because not all organizations provide the necessary support to their fresh leaders. Because of that, micromanagement is quite common - also in companies that are seen as successful.

Here are a few characteristics of it:

• Constant Supervision: monitoring every aspect of a teammate’s work and requiring frequent status updates.
• Lack of Delegation: not delegating tasks or responsibilities, preferring to do things themselves.
• Excessive Control: dictating exactly how tasks should be done, even when the employee has the skills to handle them independently.
• Frequent Corrections: lack of trust in the employee’s abilities and constant correction of the employee’s work.

Sometimes it’s hard to blame micromanagers — esp. the ones who were the most senior engineers in a team (or the organization’s old guards). They already “saw things”, have deep domain knowledge, and remember every single hack they implemented during their journey. However, we must remember that this style of leadership reduces the autonomy of others and lowers the sense of ownership, which can be destructive for engineering teams.

Center-out Leadership

Last year, significant news emerged about the rebound of Barnes & Noble, a bookstore chain previously on a straight path to liquidation. 2023 marked the first year in recent memory when this company expanded rather than contracted.

This success was primarily attributed to their CEO, James Daunt, who implemented a strategy that involved:

• Granting autonomy to local managers to make more decisions about their stores (such as which books to stock, ensuring the selection is relevant to their customers),
• Reducing the non-book offerings in stores, which also decreased the cognitive load on managers.

James Daunt’s actions were a classic example of a transformation from top-down leadership to center-out leadership.

In a center-out leadership, decision rights are distributed within some set of boundaries. This means teams and individuals have the autonomy to make decisions within their areas of expertise, but a framework is still in place to ensure alignment with overall goals and ways of working.

As an engineering leader, you set expectations (such as technical standards, non-functional requirements, product acceptance criteria, hypotheses, principles and guidelines). But then you invite the team to provide their input and collaboratively work on the problems ahead — you set WHAT, and they decide on HOW.

For you, as an engineering leader, the center-out approach opens new ways of working with your team and product stakeholders. By reducing your cognitive load required to always be on top of everything, you can shift your attention to:

• Building your understanding of the product context,
• Growing and empowering your people,
• Managing the strategic direction of the technology you oversee.

The center-out approach is not without its costs and risks. The biggest challenges include:

• Complex Decision-Making: Without effective facilitation, discussions may drag on for months without reaching a consensus.
• Potential for Chaos and Misalignment: Center-out leadership requires clear boundaries and effective collaboration.
• Need for Strong Leadership Skills: In addition to technical expertise, leaders must also develop skills in coaching, facilitating, and empowering their teams effectively.

Top-down Leadership

Sometimes, the environment doesn’t allow us to go immediately into a center-out approach. These scenarios include:

• Bootstrapping the team, ways of working, and common standards,
• Taking the lead during a crisis,
• Minimizing variance when we expect exact results (e.g., financial reports).

In such cases, a more classic, top-down approach to leadership can be a better fit.

In a top-down approach, management retains data and decision-making authority. The leader develops or selects the best solutions, and their direct reports are expected to execute these directives. This approach can often be observed at the organizational level, where senior management makes strategic decisions without lower-level consultation and expects teams to implement the decisions made.

Though often viewed as micromanagement, the top-down approach has its strengths. It brings:

• Efficiency: Decisions can be made swiftly without needing consensus from multiple stakeholders.
• Clarity: Clear directives and expectations can simplify roles and responsibilities.
• Control: Managers can enforce policies and standards effectively.

But the main costs and risks are:

• Lack of employee engagement,
• Risk of misalignment,
• Leader’s cognitive overload

To read more about the differences between Center-out and Top-down Leadership styles, check the Practical Engineering Management article: Top-down Leadership vs. Center-out Leadership.

Transactional Leadership

Transactional leadership is a traditional top-down approach focused on rewards and punishments, which are supposed to optimize job performance. In this style, leaders pay attention to constraints, mostly around limited resources (time and workforce).

A transactional leader constantly analyzes cost-benefits and weighs competing needs. They continuously “allocate resources,” trying to find the most optimal configuration of the team, its priorities while minimizing waste and idle time.

For transactional leaders usually, there are too few people and too many initiatives to handle. In that case, the best a transactional leader can do is to:

• Recruit more people or better people,
• Improve the current team’s allocation based on perceived outcomes (better productivity, profitability, returns, etc.).

But the reality is much more complex. In the dynamic systems we operate, we cannot accurately forecast the time needed to complete the work as a whole, nor can we get precise information from each of our teammates about the time they need to finish their piece.

It has been proven that finding the most optimal scheduling solution for complex systems is impossible — “job-shop scheduling” is an NP-hard problem, meaning that for some scheduling problems, we won’t find a solution in finite time.

Also, hiring more people isn’t always a good solution. As Price’s Law states, the square root of the total number of people in a domain does half of the work. For example, if you have an engineering team with 100 people, Price’s Law suggests that 10 people (the square root of 100) will produce 50% of the results. Hiring more also brings more complexity and challenges — even more scheduling, more priorities to handle, and more relationships to maintain.

Each of us occasionally plays transactional leader—we optimize allocation, hire more people, and try to improve productivity. But it’s worth remembering that we can do more than just play “optimization chess “with “available resources.”

Developmental Leadership

While transactional leadership focuses on acquiring more resources, developmental leadership, before asking for more hires, considers how to grow the current team’s creativity and problem-solving capabilities so potential new team members won’t operate in the same fashion.

To be a developmental leader, you can’t just be inspirational and motivational. Your job is to constantly improve the environment so your team can do great work.

It’s not only about investing in people’s growth, as the word “developmental” might suggest. Apart from that, you must also focus on improving the conditions under which work is executed.

An extensive source of knowledge here can be the book “Wiring Winning Organizations”, which introduces three core aspects of transforming an organization:

• Slowification — making the problem-solving process easier.
• Simplification — making the problems themselves easier.
• Amplification — calling out occurring problems loud and clear.

Developmental leadership is about looking beyond the day-to-day and investing in your team’s future. This style encourages us to create an environment where everyone feels empowered to solve problems and innovate.

For more, you can read my article on Practical Engineering Management, where I explore the differences between transactional and developmental leadership and provide some practical examples for implementing them in our work.

Read it here: Developmental Leadership vs. Transactional Leadership

Transformational Leadership

Actually, transformational leadership isn’t a different style but rather a synonym for developmental leadership, as described earlier. Yet I put it here because of certain management style aspects connected to this particular term.

Transformational leaders focus on improving software delivery performance by enhancing the team’s technical and product management capabilities rather than driving outcomes directly (top-down or transactional leadership).

DORA studied the role of Transformational Leadership and proved that it is highly correlated with SDLC and Organizational performance. According to the research, there are five specific characteristics of this approach:

• Visionary,
• inspirational communication,
• intellectual stimulation,
• supportive leadership,
• personal recognition.

The leaders of the most high-performing companies usually presented strong behaviors across each of them.

To read more, check DORA’s explanation of Transformational Leadership: https://dora.dev/devops-capabilities/cultural/transformational-leadership/

DORA | DevOps Capabilities: Transformational Leadership

If you want to be an influential and successful leader, I recommend self-assessing these five transformational leadership characteristics each week. If you are looking for a more structured framework that can help you with that, check the Practical Engineering Management’s Leader’s Week.

Psychological Safety Leadership

The list of leadership styles wouldn’t be complete without some materials that come directly from the study of human behavior — psychology.

Many of us have heard about Google’s research, which says that psychological safety is a critical factor in high-performing teams.

“In a team with high psychological safety, teammates feel safe to take risks around their team members. They feel confident that no one on the team will embarrass or punish anyone else for admitting a mistake, asking a question, or offering a new idea.”

To explore the subject deeper, we shared some insights on Practical Engineering Management, from the latest physiopsychological research and the Polyvagal Theory.

Polyvagal Theory (PVT), developed by American psychologist and neuroscientist Stephen Porges, suggests that our autonomic state acts as a mediator, guiding us from vulnerability in threatening situations to accessibility in supportive environments, aided by safety cues and appropriate social support.

In simpler terms, neuroception engages the resources of the Autonomous Nervous System (ANS) and regulatory systems based on the presence or absence of safety. It serves as our internal “safety radar,” operating subconsciously to continually assess our environment through:

• Internal Check (Inside): Am I safe? Do I have what I need?
• Interpersonal Check (Between): Am I safe? Am I seen, liked, understood, supported?
• Environmental Check (Outside): Am I safe here? Do I belong here?

Safety is not just a concept but an embodied state, fundamental to regulation. Based on PVT, there are six basic strategies to make you and your team feel well, safe, and productive:

• Clarity: Clear communication about job responsibilities, salary, benefits, and promotion criteria.
• Predictability: A leader should be predictable in their demeanor — consistent, stable, and attentive — making it clear what others can expect from them.
• Belonging: Nurturing a sense of belonging within the team enhances work atmosphere and effectiveness.
• Flexibility and Sensitivity: Support employees through personal hardships, reinforcing safety and stability rather than conditional support.
• Co-regulation: Effective teams are characterized by ongoing relationships based on mutual regulation and trust.
• A Sensory-Friendly Environment: Reducing sensory overload helps facilitate deep work. Leaders should strive to minimize unnecessary distractions in the work environment.

Check the latest article on Practical Engineering Management: Safety Leadership and Neuroception — How the Polyvagal Theory Enhance Workplace Safety, Engagement, and Performance.

End words

Effective engineering leadership embraces a variety of styles, each with its own set of advantages and challenges. The best leaders blend these styles, continuously evaluating and adapting their approach to foster a culture of growth, collaboration, and high performance.

As you navigate your leadership journey, remain flexible and responsive to the evolving dynamics of your team.

You can also explore more content for engineering managers on practicalengineering.management. You will find there practical strategies for effective engineering leadership.

Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

Different Styles of Engineering Leadership was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.

Example Templates and Tools for Software Engineering Leaders

There are two ways of leading engineering teams in a tech company. You can go with command and control, where you make all decisions and expect team members to follow orders, implementing the specified tasks.

Or you can take a more empowered approach, where you push decisions down to your team and expect them to solve problems rather than follow explicit instructions. In this approach, your job is less about scheduling and coordinating (data, decisions, people) and more about building alignment, enabling communication, and sharing knowledge.

I covered these approaches in depth in one of the newsletter issues — Top-down Leadership vs Center-out Leadership.

In truth, it’s way harder to lead through empowerment rather than command and control. Delegating problems means no less work for you but the opposite. As a leader, you must constantly provide all needed context, mentor your people, facilitate, set boundaries, and share knowledge.

In this post, I’m exploring examples of tools and approaches to building collective intelligence and aligning the team so you can lead your team through empowerment rather than control.

RFCs and ADRs

Good knowledge-sharing practices are critical for tech companies, especially in the growth phase, to avoid slowing down development and minimizing the number of external dependencies.

Companies constantly evolve, teams change, and people come and go. With that in mind, there will always be someone new to the project, tech stack, or infrastructure. Our job is to ensure that these individuals have enough context to be effective in their work.

There are two practices/documents that can assist us in this:

• RFC — Request For Comment, which aids in collaborative and asynchronous decision-making. This document is typically initiated by engineers or engineering leaders who propose a change in design, architecture, or processes with a unified direction.
• ADR — Architectural Decision Record, the document created to capture significant architectural decisions, their context, and consequences. It helps maintain the project’s history and provides context for future development. The rule of thumb for ADRs is that once the decision is challenging to make or difficult to reverse/change, it should be documented in an architectural decision record.

Both RFCs and ADRs are seen as good practices for software engineering organizations. You can read more about their rationale on Thoughtworks Technology Radar (RFCs, ADRs). However, it’s essential to approach them in a lightweight manner, with a narrow scope, to keep them short and easy to consume, thus ensuring they bring value to the organization.

If you want to introduce ADRs or RFCs to your organization, on Practical Engineering Management you can find some ideas on how to do this and templates (Notion, Markdown) which you can use in your work.

For more, visit:

• Lightweight ADR — How to Implement Architectural Decision Records in Your Organization
• Lightweight RFC — How to Implement Request For Comment in Your Organization

Non-Functional Requirements

It’s a slightly different angle than RFCs and ADRs. But to give freedom in solving problems, you must also set some boundaries and alignment between engineers or engineering teams and products. Non-Functional Requirements can help you with that.

Product Managers are usually responsible for setting product requirements, hypotheses, or acceptance criteria for the product we build. As an engineering team, we can complete this picture by bringing non-functional requirements.

NFRs are crucial for ensuring your software not only meets its functional goals but also adheres to standards for performance, usability, reliability, and other quality attributes.

The best NFRs to start with depend on your product’s nature and the industry you’re operating in. Different NFRs apply if your product aims to serve millions of users in a B2C business versus hundreds of customers in a B2B context. Likewise, building a mobile app designed for small screens with limited battery life and computing power has different limitations than developing a desktop/web app with always stable access to corporate WiFi designed for full HD screens.

When you check Wikipedia’s definition, you will find an overwhelming list of 60+ NFRs. That’s why Practical Engineering Management brings some ideas for introducing NFRs in a lightweight way, examples of these, and templates you can use as a framework in your organization.

Read more on Non-Functional Requirements — Setting Quality Standards for Your Tech Stack.

Access to data

If you want to push down as many decisions as possible to your teams, you also must ensure they have direct access to data so they know the context of the problems they are supposed to solve.

These can be observability dashboards, logs, and alerts, which your team should maintain to ensure that your services and apps work. They can also be crash analytics tools like Firebase Crashlytics and Bugsnag, dashboards like Grafana, or full observability platforms like New Relic or DataDog.
As an engineering leader, you must ensure the team owns its tech stack post-launch and has enough information about its performance, reliability, issues, and incidents.

Apart from technicalities, your team should also understand how the product is being used and what are some core metrics from the feature or service you manage, e.g.:

• The volume of users and events,
• Seasonality (like peak hours or days),
• User flow through your feature,
• Critical events (often referred to as conversions),
• Errors (not just technical, but also those from a UX perspective),
• A/B test success metrics.

If you want to delegate problems to solve, not tasks to accomplish, you cannot rely on a Product Manager or Analyst to inform you about these data points. Access to this information should be public for all of your teammates, and the team should be willing to check these on a daily basis.

To explore this subject further, read the Practical Engineering Management article Product Analytics for Engineering Leaders.

Product Analytics for Engineering Leaders

In some cases, you will need to build data dashboards yourself to better inform your team's decisions. Fortunately, there are many off-the-shelf solutions you can use to bootstrap something quickly: Google Looker Studio for data visualization, Google Sheets for data collection, Google Colab for Python scripts and data processing, and cloud functions.

To build your first dashboards in less than one day, check out the blog post: Simple data tracking solutions for engineering leaders.

Simple data tracking solutions for engineering leaders

You can also explore a premium article on Practical Engineering Management, which walks you through the steps of building these dashboards — Looker Studio, Colab, Big Cloud Functions integrations, and more.

Read it here: Practical solutions to track your goals.

The Problem Solving Framework

This high-level understanding of your tech stack and product is also critical for framing the problems you aim to solve. Effective problem-solving isn’t about jumping quickly into solutions; it’s about solving the right problems in the right way.

In our complex world, the initial solution is rarely the optimal one. Problems may have multiple definitions, none of which is ultimately the right one. A problem may have numerous stakeholders, each with their own solution, and these stakeholders may have different power to articulate their preferences (e.g., the loudest one in the room, the most senior on the org chart, or those who prefer to remain silent).

Inspired by “Are Your Lights On”, here is an 8-step framework to help find optimal solutions for problems faced by software engineering (or, more generally, product engineering) teams:

1. Recognizing the problem (What’s a problem?)
2. Defining the problem (What are the facts behind the problem?)
3. Exploring the problem’s depths (What are root causes of the problem?)
4. Identifying stakeholders (Who have the problem?)
5. Assessing the willingness to solve (Is it worth solving the problem? Is it aligned with broader goals and strategy?)
6. Developing solution strategies (What are options for solving problems? Which are the optimal ones?)
7. Implementing the solution
8. Monitoring and reviewing (Are success metrics defined and achieved through the solution?)

Bringing this framework to your team should help both groups:

• For teams that tend to jump into instant solutions, this framework provides perspective and support in problem framing.
• For teams that overthink their problems, it helps narrow the focus to “just enough” information to start iterations.

For more, check these materials: The Problem Solving Framework.

1:1s

Good one-on-one meetings have already been mentioned multiple times here. But there is a reason for that. In my opinion, this is the most important tool and activity for engineering leaders. To empower your teammates, share feedback, provide context, mentor, and coach them, you need to build solid relationships and a space to share all those things.

In 1:1 meetings, you work not only on your teammates’ growth but also translate strategic things—mission, product objectives, long-term plans—into day-to-day action. By doing so, you build people’s understanding of their role in the organization’s success.

Starting your 1:1s isn’t easy, so you can use PEM’s workbook First Ten 1:1s for Engineering Leaders. The first two chapters are already available for free for everyone, so I invite you to check them and see if they can help you with your challenges. You will also find there example templates in Google Docs and Notion for your 1:1 meeting notes.

First Ten 1:1s for Engineering Leaders

End words

Empowering an engineering team requires a multifaceted approach that extends beyond task delegation. It involves cultivating an environment of collective intelligence, where knowledge sharing, decision-making autonomy, and alignment with organizational goals are paramount.

Leaders can foster a culture of empowerment and innovation by integrating effective practices such as RFCs and ADRs, managing non-functional requirements, ensuring access to data, utilizing a problem-solving framework, and conducting meaningful 1:1 meetings.

Explore more content on practicalengineering.management. You will find there practical strategies for effective engineering leadership. Join the community of impactful leaders to bridge the gap between inspiration and implementation with actionable steps that empower your team, boost trust, and drive real-world results.

If you would like to discuss any of your challenges, don’t hesitate to reach out to me at mirek@practicalengineering.management.

How to Build Collective Intelligence and Empower Decision-Making was originally published in Practical Engineering Management on Medium, where people are continuing the conversation by highlighting and responding to this story.