The assumption is usually that I have some secret productivity hack or that I’m just working all the time. But working harder is a trap.

Some time ago, I successfully negotiated a transition to a four-day workweek. My team’s output didn’t drop. The expectations placed on me didn’t shrink. I didn’t step back from leadership—I simply stepped away from the noise.

I made it because I am fundamentally a maker, a creator, and a designer. I needed the autonomy to build things on my own terms.

Pulling this off required proving to the business that my value wasn’t tied to the number of days I sat at my desk, but to the tangible, high-leverage outcomes I delivered.

The idea behind my system - the Leader’s Week is simple: focus on a single week, plan those days ruthlessly at the beginning, and objectively sum up the impact at the end.

This framework isn’t just another productivity hack. It is how you shift from being a reactive implementer to a proactive problem-solver. It is the ultimate tool for earning the trust and autonomy required to take control of your schedule.

The Philosophy

Your job is to focus on the right things (and build a product, not just code)

First-level managers—Tech Leaders, Engineering Managers, or Team Leaders—are the linchpins of any tech organization. Your difficult job is to mix hands-on technical reality with strategic business thinking.

But here is where many leaders get it wrong: they treat their teams as simple implementers. A backlog of tickets comes in, and code goes out.

To truly maximize your impact, you need to cultivate a “product sense” within your team. Engineers must be treated as partners in product discovery, not just a delivery mechanism. First and foremost, you need to ensure the team is solving actual business problems, not just writing code for the sake of interesting architecture.

What if you lead a backend, DevOps, or platform team that doesn’t build customer-facing features? The mindset doesn’t change. You are still building a product; your customers are simply internal developers, and your metrics are reliability, developer experience, and deployment speed.

If the “why” behind your projects isn’t clear, you need to anchor your team to the four factors essential to the success of any business.

Every problem you solve should map to one of these:

• Growth: Reaching new customers and expanding market share. (e.g., Optimizing an onboarding flow, or ensuring the backend scales to handle a 5x traffic spike).

• Expansion: Offering new products and services to existing customers. (e.g., Shipping a highly requested feature, or abstracting a service so it can be reused in a new market).

• Profitability: Ensuring you have the resources to continue operating. (e.g., Slashing AWS costs, migrating from expensive enterprise software to an open-source alternative, or automating manual QA).

• Customer Satisfaction: Ensuring customers keep coming back. (e.g., Fixing critical bugs, reducing latency by 200ms, or achieving 99.99% uptime).

When planning key initiatives for a week, start with this assessment:

Ask yourself: Are we just writing code, or are we driving Growth, Expansion, Profitability, or Customer Satisfaction?

Outcomes, not inputs (Actionable reality over theoretical hype)

Once you know which of the four business factors you are targeting, you have to measure your success correctly.

In product-minded engineering, the effort you put in is just a cost. The code you write is a liability. The only thing that actually matters is the outcome you achieve.

You can build the most theoretically perfect, hype-driven microservice architecture in the world, but if it doesn’t solve a user problem or move a business metric, it was a waste of a week.

So, what does an actionable outcome look like?

• Increased conversion by X% (e.g., The drop-out rate of the sign-up flow went down by 10% after rewriting the validation logic).

• Increased revenue by Y% (e.g., Enabled Stripe integration for 3 new European markets, unlocking new MRR).

• Reduced infrastructure cost by Z% (e.g., Optimized database queries and adjusted auto-scaling, dropping monthly cloud spend by 20%).

• Increased iteration speed (e.g., Cut CI/CD pipeline build times from 45 minutes to 8 minutes, allowing developers to ship 5x faster).

Notice there are almost no technicalities in the primary objectives. You must always know the tangible good you are bringing to your customers or the company.

When you sit down to plan your Leader’s Week, write these outcomes at the very top. Then, list the specific engineering initiatives that will get you there.

Example:
If the outcome is “Reduce infrastructure costs by 15%,” your key initiatives for the week might be:

1. Identify and shut down orphaned staging environments.

2. Refactor the 3 most expensive database queries identified in Datadog.

3. Migrate image storage to a cheaper bucket tier.

At the end of the week, you don’t judge yourself on how many hours you spent looking at AWS dashboards.

You judge yourself by the outcome: Did the daily spend drop?

The Setup

The First Thing on Monday (Design Before You Execute)

When you step into the office on Monday morning, the easiest thing to do is open Slack, check your email, or look at the latest alerts.

Do not do this.

The moment you open those channels, your week is no longer yours. You become reactive, immediately pulled into other people’s priorities, urgent-but-unimportant fires, and administrative noise.

Think of this like building a physical product. A maker does not start cutting material or firing up the 3D printer without a finished CAD model. As a leader, your week is the material. You cannot start executing without a blueprint.

Planning the week must be the absolute first thing you do. Block the first 30 to 45 minutes of Monday morning in your calendar. During this time, you are unreachable. You sit down with your long-term objectives, your strategic context, and your Leader’s Week template. You define the value of the next tens of hours before a single line of code is written or a single 1:1 is held.

If figuring out your plan takes longer than an hour—for instance, because priorities are muddy or you lack strategic clarity—then getting that clarity becomes your first actionable goal.

The “One Priority” Rule (Protecting Deep Work)

There is only one, single, non-negotiable priority for the week.

This is the hardest rule for leaders to accept, but it is the most vital lesson of this framework. When you operate with severe time constraints—like a four-day work week—you cannot afford the illusion of multitasking. If you have five priorities, you have none. You will end Friday having moved five things 10% of the way to completion, generating zero actual value.

Your One Priority is the initiative that, if absolutely nothing else gets done by the end of the week, still makes the week a success.

Because it is the most important thing, it requires the most protected resource you have: uninterrupted deep work.

You must carve out at least 8 hours in your week dedicated solely to this subject. Do not sprinkle this across 30-minute gaps between meetings. Block out massive chunks of time—like two 4-hour sessions—to immerse yourself entirely. Whether that is drafting a critical architectural document, untangling a complex scaling issue, or mapping out the next quarter’s product expansion, this time is sacred.

Timeboxing the Rest

Once the One Priority is locked in, the rest of the week falls into place through aggressive timeboxing:

• Two Secondary Targets: Pick exactly two other important things that require your attention (e.g., unblocking a specific team, resolving a structural tech-debt issue). Box 2 hours of total focus for each.

• The Radar: Pick three or four essential things to simply monitor. These are KPIs, deployment health checks, or team status updates. You are building awareness, not doing deep work here.

• Timebox Everything: Put these blocks directly into your calendar. A task without a calendar block is just a wish.

Systems Need Slack (Do Not Plan 100% of Your Time)

It is incredibly tempting to fill your available working hours entirely with planned blocks. This is a recipe for catastrophic failure.

In engineering, systems running at 100% utilization queue up requests and eventually crash. Your calendar works the exact same way. If your week is fully booked, a single production incident or urgent stakeholder request will cascade, destroying your entire plan.

If you follow the Leader’s Week framework, your planned priorities will consume about 15 to 20 hours.

That is intentional.

The remaining time is your slack. It absorbs the shocks of firefighting, allows for unstructured learning, and most importantly, guarantees you are actually available for your people when they need you. A leader with no slack is a bottleneck.

The Review

The End-of-Week Assessment (Debugging Your Schedule)

Many leaders skip the weekly assessment. They are so exhausted by the week’s sprint that they simply slam their laptops shut the moment the weekend begins.

But skipping the review turns this entire framework into a chore rather than a high-value feedback loop. Unreflected work leads to burnout and repeated mistakes.

The end-of-week assessment is not a report card for your boss; it is a mirror for you. It is the exact mechanism that gives you the peace of mind to completely disconnect. When you know exactly what you accomplished, what went wrong, and what you are leaving for next week, you can step away and recharge.

The Leadership Mirror (Assess Your Performance)

When assessing yourself, look beyond the code, the pull requests, and the Jira boards. High-performing teams are built by leaders who exhibit specific, observable behaviors.

I use the five characteristics of transformational leadership (from the DORA research and the book Accelerate) to run a quick system check on my own behavior:

• Visionary: Did I connect our current, messy technical slog to the 6-month product vision?

• Inspirational Communication: Did I frame a recent failure as a system flaw to learn from, rather than a human error?

• Intellectual Stimulation: Did I challenge my team to rethink an old architectural problem, or did I just hand them the answer?

• Supportive Leadership: Did I actively clear a blocker for a struggling engineer?

• Personal Recognition: Who did I explicitly and publicly praise this week?

Measure the Reality (KPIs and Outcomes)

Return to the outcomes you defined on Monday morning. Did the needle actually move?

You don’t need a complex dashboard for this. Mark your key initiatives simply:

• 🟢 On track

• 🟠 At risk

• 🔴 Off track

If your “One Priority” is constantly glowing red week after week, you don’t have a time management problem—you have a strategic alignment or resourcing problem. This reality check makes that structural issue visible before it becomes a crisis.

Document the Builds (Celebrate Small Wins)

As makers, creators, and problem-solvers, we have a terrible habit of constantly moving the goalposts. The moment a complex feature ships, a migration finishes, or a nasty bug is squashed, we immediately look at the next mountain.

“It was just a small refactor.”
“It was expected of us anyway.”

Stop rejecting your accomplishments.

The things that feel like “business as usual” today were likely complex, out-of-reach challenges just a few months ago.

Documenting these wins—no matter how small—is the ultimate antidote to imposter syndrome. It builds a historical ledger of your team’s momentum.

Identify the Noise (Review Distractors)

Distractions are bugs in the operating system of your week.

Sometimes they are loud, like a Sev-1 production incident. More often, they are silent killers: recurring status meetings with no agenda, slow CI/CD pipelines, or fragmented communication across too many Slack channels.

Naming these distractors is the first step to eliminating them. If you notice that “ad-hoc requests from stakeholders” derailed your deep-work block three weeks in a row, you now have the actionable data needed to build a new intake process. You transition from complaining about the noise to engineering it out of your system.

The Artifacts (Your Downloadable Interface)

The Leader’s Week is a simple framework, but it requires a tangible artifact to work. You cannot hold this all in your head.

Although we live in a digital-first world, I highly recommend printing the Leader’s Week template. Using a physical pen takes away browser-based distractions and gives you a permanent, physical record of your progress to reflect back on.

• Leader’s Week PDF

• Leader’s Week Notion

• Leader’s Week - Example1

• Leader’s Week - Example2

• Leader’s Week overview

The Final Word: Design Your Time, Protect Your Craft

Leadership can be incredibly loud.

If you aren’t careful, the organization will consume every hour you are willing to give it. You will reach the end of Friday exhausted, looking at a calendar full of meetings, wondering what you actually built.

But you are not just a manager. You are a maker. A creator. A designer of systems.

And makers need space.

Implementing the Leader’s Week wasn’t just about becoming a more effective leader. It was the exact mechanism that allowed me to compress my corporate responsibilities into four days. It gave me the leverage to step back, protect my creative energy, and spend my Fridays building my own projects and being fully present for my family.

You don’t have to negotiate a four-day workweek to find value in this framework. But you do need to stop letting the week happen to you.

Next Monday morning, before you open Slack. Before you check your email. Sit down with a blank piece of paper.

Pick your one priority. Draw the boundary. And take your time back.

Supplemental reads

• More on Human Jira Router based on Anthropic’s announcements

• Developmental Leadership

• Leader-Follower model based on David Marquet’s book

• Your job is to focus on the right things and why the Hard Work is Overrated

For the last decade, the tech industry has popularized a very specific archetype of leadership: the detached people manager.

As organizations scaled, a clear divide emerged. Engineers built the product. Managers built spreadsheets, facilitated 1-on-1s, and acted as organizational therapists. The conventional wisdom was that as you climbed the leadership ladder, you had to step back, delegate, and leave the craft behind.

In the interview, Chesky introduced what he calls “AI Founder Mode,” and his core argument is a wake-up call for the industry:

In a future accelerated by AI, leaders who only manage people—without direct contact with the reality of the work—will not survive.

The leaders who thrive will be makers, creators, and engineers who manage through the work itself.

Why Now? The Return of the Maker

For years, stepping away from the codebase made logistical sense. An Engineering Director couldn’t realistically code a feature because scaffolding the boilerplate, setting up the environment, and debugging took 40 hours. We had to delegate.

Stepping away from coding for long months was also my experience. Even though it felt bad to me, the only thing I was capable of doing during a work week was fetching the latest version of the app and launching/debugging it. In more complex projects, I wasn’t able to do even that - local env setup was so complex, I couldn’t spin it up for hours.

AI destroys that bottleneck. Tools like Copilot or Claude Code drastically lower the cost of creation. What used to take a week of engineering time can now be prototyped in 15 minutes. AI gives leaders their maker tools back.

There is no longer an excuse to be out of the details. The future belongs to those who embrace the full identity of a maker, creator, designer, and engineer.

The Engineering Leader as an Industrial Designer

Chesky didn’t compare this new leadership style to traditional software architecture. He compared it to Industrial Design.

Industrial design is a deeply technical, empathy-driven field. You don’t just design a machine; you design how a human interacts with it in the physical messy world.

Chesky shared a story about designing a child’s ventilator. The technical requirement was simple: pump oxygen. But the design requirement was intensely human: the machine couldn’t look terrifying to a six-year-old, it couldn’t induce panic in the parents, and it had to be perfectly usable by hospital staff.

In industrial design, there is no assembly line where “Product” hands over a spec and “Engineering” blindly implements it. The creator is the problem solver.

When mapping the physical-to-digital journey for RunArt’s 3D-printed topographies, or architecting the core flows for the ScoreLabs platform, I hit this exact reality. A clean database schema and green CI/CD pipelines weren’t enough. Absolutely no single customer cares about that.

You have to think like an industrial designer making a physical product. You have to look at the entire ecosystem and ask: How does this actually feel in the user’s hands?

We Are Already Doing This (We Just Need the Language)

When I listened to Chesky’s thoughts, I realized this is exactly what the Product Engineering philosophy advocates for.

Some time ago, I also codified this into The User-Friendly Engineering Framework. Engineers are taught to think in systems, inputs, and edge cases. We often view design as subjective or emotional. But good design isn’t about taste—it’s about reducing human confusion. And reducing confusion is a highly technical discipline.

Here is how the industrial design mindset maps directly to the realities of software engineering:

1. Wear the User’s Skin (The Empathy Gap) In software, engineers carry invisible context—we know the architecture, the naming conventions, and the latency expectations. Users don’t. When a user stares at a “Processing...” screen and refreshes the page, they aren’t using the system wrong. We failed to provide the right feedback. You have to strip away your insider knowledge to see the design bugs.

The Monday Morning Litmus Test: Tomorrow morning, block 30 minutes. Use your product end-to-end. No debugger. No admin access. No shortcuts. Write down every single moment you hesitate. Those aren’t user errors; those are your design bugs.

2. Design Across Time, Not Screens (The User Journey) Industrial design is taught through continuous user journeys, not isolated touchpoints. In software, we often obsess over a single flow—a working “Export to CSV” button. But UX outages almost always occur in the gaps between steps, sessions, and teams. A feature can work perfectly in isolation, but if the overarching journey is broken, the product fails.

3. Engineering Doesn’t Ship Code. It Ships Behavior. You can design a perfectly working backend system, but if it teaches the user the wrong mental model, you have broken the contract. If your UI looks like a timeline, users expect a history. If it looks like a checklist, they expect an undo function. The new era of engineering leaders must own the “why” and the “what” just as much as the “how.”

The Best Engineering Disappears

Chesky noted that the magic of great design is distillation—stripping a system down to its absolute, fundamental essence.

When a product feels simple, it is never because the system itself is simple. It feels simple because someone did the hard thinking upfront, making the complexity invisible.

But you cannot distill what you cannot see. Industrial designers use physical prototypes to find friction; Product Engineers use telemetry. Distilling a product to its essence requires leaning heavily on modern observability—leveraging OpenTelemetry and DORA metrics to see exactly where users get stuck and where the system drags. Telemetry is the software equivalent of watching a human struggle with a physical prototype.

That is the true job of an engineering leader in the AI era. You cannot lead the builders if you have forgotten how to build. You must be a product engineer. You must be a designer of systems.

Ready to dive deeper?

The concepts above are just the surface. If you want the operational manual for building like an industrial designer, I have codified all 8 pillars of this mindset into The User-Friendly Engineering Framework.

​While it contained tips on lighting fires and breaking machinery, its most devastating section focused on “bureauc…

Read more

Your job is no longer about whether we adopt AI, but about how we actually get a return on our investment without destabilizing our systems. Especially when C-level has been pushing you hard on this transf…

Read more

Spotify unveils Honk, an agentic platform that effortlessly updates hundreds of repositories in the background. “Spotify's top developers haven't manually written code since December 2025”.

Rippling announces Rippling AI, …

Read more

We shifted away from low-leverage interventions (like tweaking Jira story points) to high-leverage moves like shifting cultural paradigms.

But there is a middle layer that deserves an article entirely of its own: Feedback Loops and Information Flows.

As an engineering leader, we actively manage feedback loops every single day. We bounce between two extremes: offering vague, unhelpful praise or delivering relentless “constructive” criticism that grinds our teams down.

To build an autonomous, high-performing engineering culture, you have to understand the difference between Reinforcing Loops, Balancing Loops, and the critical process of Amplification.

The Two Loops of Leadership

In systems thinking, there are two types of feedback loops that govern how a system behaves.

1. Reinforcing Loops (The Accelerators)

Reinforcing loops compound. They amplify a behavior or result. In software, it’s tech debt (bad code makes it harder to write good code). In leadership, it’s how you scale culture. When you praise an engineer for writing excellent documentation, they write more of it, others see it, and a culture of documentation grows.

The Trap: Vague Reinforcement. Saying, “Hey, good job on that release” is empty calories. The engineer feels a momentary ego boost, but the system doesn’t learn what specific behavior to repeat.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

I have to admit, the chart of theoretical vs observed AI coverage stayed with me for longer. Math, computer science, admin & office, legal - I get these.

But management? Huh, that feels l…

Read more

A few months later, that cycle arrived. My reward? Nothing.

It was disappointing. Turbulent times and budget cuts, s…

Read more

When we were individual contributors, our code produced rapid, tangible outcomes. But as leaders, the effects of our decisions—or our passivity—often take months to surface.

Behind the scenes of our daily management, we are constantly fighting two invisible, relentle…

Read more

We spend months recruiting principal engineers, hoping that bringing top-tier talent into the same room will automatically translate into outlier results.

But there is a trap here that many engineering leaders fall into: we confuse a group of brilliant individuals with an actual, functioning team.

If you have a strong gro…

Read more

It resonated a lot. I remember my early times in the leadership, reading how Google, Spotify, and Amazon are managed - always frustrated about why we cannot do the same in our company.

Until I realized it’s not the company that is supposed to change. It is we, leaders, who drive this change, very often bottom-up.

You Manage System

As an engineering leader, you are essentially a system designer. You manage a complex socio-technical system—a web of people, processes, codebases, and infrastructure.

Early in our careers, we intuitively focus on technicalities: code, libs, APIs, UI components. But over time, we realize our work is on different levels too: tools and instruments (how these things are tied together) and finally, the social circuitry that includes the processes, standards, and communication patterns that guide how people work together.

The concept of three layers:

• Layer 1: Technical Objects

• Layer 2: Tools and Instrumentation

• Layer 3: Social Circuitry

It was perfectly explained in Gene Kim’s book "Wiring Winning Organizations," which I covered in a cycle of articles that starts here: Slowification: The First Step to Transforming Your Engineering Organization.

Leverage Points

Recently, I’ve read one of the most foundational texts in systems thinking: Donella Meadows’ essay “Leverage Points: Places to Intervene in a System”.

It explains that every complex system (organizations, companies, teams, economies) has places where a small change can produce a disproportionate effect.

Meadows’ core thesis is that people intuitively know systems have “leverage points” (where a small shift produces a big change), but for engineering leaders, the key insight is slightly uncomfortable:

Most leaders intervene in the least effective places.

They change metrics, budgets, or org charts while the real leverage sits deeper in information flows, incentives, and beliefs.

The original leverage points, as described in the article:

Here is how you can translate Meadows’ 12 leverage points into actionable insights for engineering leadership, moving from the least to the most transformative interventions.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

The real leverage sits in operations.

Over the last few weeks, I used AI to build a governance and observability dashboard on top of our no-code platform (Superblocks). Not to create apps faster. To control the chaos around them.

Surprise, no surprise: this wasn’t a hackathon toy anymore.
It became a working operational control system.

I’ve been building with AI for quite a long time, but this time my perception shifted to something new: code-as-a-service.

In this article, I will share my journey with building something in just a few weeks, which before took almost half a year for ops teams to capture.

We’ll walk through my real use cases, some dashboard previews and the solution I came up with to simplify management of our infra at a company scale.

The entire article is available only for paid subscribers. You can use the training budget (here’s a slide for your HR). Thanks for supporting Practical Engineering Management!

Read more

One of your strongest engineers walks in with an offer that looks like it escaped from another financial universe. Bigger salary. Better title. Sometimes both. Occasionally double or triple what you can reasonably propose.

For first-time engineering leaders, this hits like cold water.
It feels personal.
Like failure.
Like you “lo…

Read more

The reply became legend:

“Mr. President, I’m helping put a man on the moon.”

That story is my North Star in my daily job as an Engineering Site Leader at Papaya Global in Poland.

I want every engineer to have that level of clarity. To know exactly how…

Read more

This article is inspired by what I took from this year’s talk. Sadly, his last keynote.

Read more

Engineering teams burn cycles debating how to integrate OpenAI or Claude, wire agents into CI/CD, build custom IDE plugins, or wrap raw LLM APIs.

This is a solved problem.

GitHub, JetBrains, Microsoft, and others already built these pipes. Integration is no longer the challenge. It’s a commodity.

The real bottleneck, and the real competitive advantage, lies elsewhere:

What you feed the model.

To move from playing with AI to creating durable enterprise value, we must shift our attention:

1. from integration to data

2. from increasing cognitive load to deliberately reducing it

Full article and supporting materials are available to paid subscribers, including:

• Practical solutions and standards

• Case studies and examples

• Exercise for you

You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

Most of them are just adding noise.

With AI:
Slack is louder.
Docs are longer.
Budgets are higher.
Bud roadmaps are somehow… slower 🤷

The uncomfortable truth is this:

AI rarely fails because of models. It fails because of engineers.

After watching multiple teams “adopt AI,” the same personalities keep showing up.
Recogniz…

Read more

Will it replace humans?
Will it take jobs?
Will engineers still be needed?

Those questions are loud.
And mostly irrelevant.

The real question for engineering leaders is quieter and more uncomfortable:

How do we make sure our teams don’t lose the ability to think, judge, and decide once AI starts doing most of the visible work?

Because AI doesn’t fail by being weak.
It fails by being good enough.

The Lens That Changed the Question

Some time ago, while reading User Friendly by Cliff Kuang, one example stayed with me longer than the others.

The book explores how automation and design don’t just make systems easier to use — they quietly reshape human capability.

In one case, automation made pilots safer and more efficient in normal conditions, while slowly eroding the very skills they needed when something went wrong. Not because they were careless, but because the system no longer required them to practice those skills daily.

Once you start looking at AI through that lens, the question stops being whether it replaces humans — and becomes whether it slowly trains them out of the profession they’re supposed to master.

This Isn’t Just a Feeling

Studies on the out-of-the-loop problem show that when people shift from doing the work to monitoring automated systems, their situational awareness degrades and their responses become slower and less reliable when something goes wrong.

Researchers Parasuraman and Riley captured this dynamic precisely in their “use, misuse, disuse, and abuse” model of automation, showing how overreliance on systems that usually work leads to complacency and judgment errors even among trained professionals.

The FAA has repeatedly warned about skill degradation in highly automated cockpits and explicitly requires ongoing manual-flight training to keep pilots capable when automation fails.

Automation Is Not the Problem. Atrophy Is.

We’ve automated before.

Compilers replaced assembly.
Frameworks replaced boilerplate.
Cloud platforms replaced data centers.

Each wave removed effort.
Each wave raised the abstraction.

But AI is different in one crucial way.

It doesn’t just automate execution. It automates reasoning-shaped outputs. Code, architectures, plans, analysis, documentation.

Things that used to train our professional judgment.

And that’s where the danger lies.

Not in replacement.
But in skill atrophy hidden behind productivity gains.

Full article and supporting materials are available to paid subscribers

You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

This article zooms in on just one element of that framework.

The most practical one.
The one you can run with your team next week.

The Friction Board.

Where This Comes From

The Friction Board is inspired by the book User Friendly by Cliff Kuang and Robert Fabricant — and especially by Fabricant’s afterword:

“The World Seen Through the Prism of User-Friendly Design.”

That afterword reframes design not as aesthetics or usability tweaks, but as a way of shaping how people understand and act in the world.

This framework is my attempt to translate that idea into engineering language:

• not taste

• not opinion

• but observable behavior and mental models

Most teams don’t struggle because they lack ideas.

They struggle because they solve the wrong problem, extremely well.

An engineer sees confusion and thinks:
We need clearer logic.

A product manager sees confusion and thinks:
We need a better flow.

A designer sees confusion and thinks:
We need better copy.

The Friction Board exists to find the common language.

What the Friction Board Is (And Is Not)

The Friction Board is not:

• a feature ideation workshop

• a UX critique

• a backlog grooming session

It is an observation tool.

A way to surface one sentence:

“This feels hard because…”

Before anyone proposes how to fix it.

The entire article with The User-Friendly Engineering Framework materials is available only for paid subscribers. You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more

CI is green.
Latency is fine.
No errors in logs.

And yet customers still hesitate.

They click, pause, go back.
They open tickets that start with:
“I thought this would…”

So we respond like engineers.

We add a tooltip.
Write documentation.
Record a Loom.

But the real problem isn’t the missing explanation.

The system behaves correctly — but it teaches the wrong mental model.

And that’s the uncomfortable truth behind user-friendly products:

Engineering doesn’t ship code.
It ships behavior.

I ran into this problem years ago, before I had language for it.

While leading a mobile engineering team, we implemented a feature that let users reuse a card for recurring payments.

There was a constraint:
we couldn’t store full card details, so the card could only be reused in that specific recurring flow, not everywhere.

From an engineering perspective, it was a neat solution. So we explained it like this:

“We’ll save your card for this recurring payment.”

Technically true. But users understood something else entirely.

They assumed their card was saved in general.
They expected it to work in all future payments.
And when it didn’t, they experienced it as data loss.

Nothing was broken in the moment.
The failure appeared later, in a different flow, at a different time.

Eventually, we stopped talking about “saving the card” at all.
We framed it purely as recurring payments.

That’s when it clicked for me:

You can design a perfectly working screen —
and still break the user journey.

The Missing Lens for Engineering Leaders

Good engineering is about building systems.
Great engineering is about making them feel obvious

And that’s the lens most engineering leaders were never taught to use.

Some time ago, I picked up “User Friendly” by Cliff Kuang.

It’s a book about how products quietly shape human behavior — how small design decisions change what people do, what they trust, and how much mental effort they have to spend just to get through their day.

That, to me, is exactly the territory engineering leaders should operate in.

Most engineers were trained to think in systems:

inputs and outputs
contracts and guarantees
happy paths and edge cases

Design, on the other hand, often sounds vague.
Emotional.
Subjective.

But User Friendly makes one thing very clear:

Good design is not about taste.
It’s about reducing human confusion.

I tried to translate that idea into engineering language.

Below is the User-Friendly Engineering Framework, rewritten specifically for software engineers who don’t think of themselves as designers —
but already are.

The User-Friendly Engineering Framework

Each pillar answers one question:

“Why does this system feel harder than it needs to be?”

The entire article with The User-Friendly Engineering Framework materials are available only for paid subscribers. You can use the training budget (here’s a slide for your HR).
Thanks for supporting Practical Engineering Management!

Read more