Reader

Not long ago, one of my reports asked me a question I wasn't expecting: Why does the company suddenly care so much about cost? When I joined, I was told we just need to contribute to the group's profits. We're still doing that. So why does everything feel like a crisis?

It was a good question. And the honest answer required unpacking a word most of us use as if it means one thing, when it actually means several.

“Profitable” isn't a fixed definition

For a company that is directly owned by its founders or its workers, “profitable” is relatively straightforward: revenue exceeds costs, and the people who own the business decide what to do with the difference. Their success metric is theirs to define.

Most of us, however, don't work in that kind of company.

For subsidiaries – and most mid-to-large companies are subsidiaries of something – “profitable” means whatever the parent decides it means, in service of the parent's own goals. A subsidiary can be consistently profitable and still be restructured, deprioritized, or squeezed, if the parent's calculus changes. The subsidiary's standalone P&L is a data point, not a verdict.

This is what my report's original onboarding told them was true – and it was true, as far as it went. The subsidiary doesn't need to be profitable in isolation, it needs to be useful to the group. That's a real and defensible principle.

What it doesn't account for is what happens when the group's own success metric shifts.

Who owns the owners

For publicly traded companies, the “group” is itself accountable to someone. Specifically, to the funds and institutional investors that hold majority positions. And those entities are not in the business of holding profitable companies. They are in the business of delivering returns to their own investors – which means the relevant metric isn't whether the portfolio company is profitable. It's whether it is growing.

Stable profit, from a fund's perspective, is not a success state. It is a plateau, and plateaus invite questions about whether capital could be working harder somewhere else.

This is why profitable companies lay off employees. It's why earnings that beat expectations but miss growth projections still cause stock prices to fall. And it's why my report's company – still generating profit for the group, still meeting its original mandate – suddenly finds itself under cost pressure it didn't expect and can't quite explain by looking at its own numbers.

The explanation isn't in their numbers. It's in the numbers of whoever owns their parent.

So what do you tell people

When pressure arrives without an explanation that makes intuitive sense – when the obvious answer (“we're making money”) doesn't seem to satisfy anyone in leadership – it's usually worth asking one more level up than feels natural. Not because the answer will feel better. Often it won't. But because people handle ambiguity much better than they handle the feeling that something is being hidden from them, or that the rules changed without notice.

My report left that conversation with a clearer picture of why the pressure existed, where it came from, and why it wasn't – at least at their level – a signal that anything they were doing was wrong. That not spin, that's a better map.

And in my experience, people with a better map navigate better than people without one, even when the territory is difficult.

A few weeks ago, in a department-wide call, a leader I respect said something that's been sitting with me ever since.

We were talking, in passing, about how promotion decisions get made – about proximity, about who gets seen, about who happens to be in the room when the room matters. And this leader acknowledged, openly and without prompting, that proximity bias and recency bias are real. That people who are physically near decision-makers tend to fare better than people who aren't, regardless of the work itself.

I appreciated the honesty. Then came the second half of the sentence: because we're aware of it, it's already accounted for.

I want to sit with that claim for a moment, because I think it's more common than we realize, and more dangerous than it sounds.

The comfort of naming

Naming a bias feels like doing something about it. It has the shape of insight – the vocabulary of self-awareness, the tone of intellectual honesty. And there's a reason it feels that way: naming usually is the first step toward fixing something. We're taught that awareness precedes change, so it's natural to mistake the first step for the whole journey.

But awareness and correction are not the same act, and treating them as equivalent quietly does something else: it closes the conversation rather than opening it. Once a bias has been named out loud, by someone with authority, it becomes much harder to point to its effects later without sounding like you're relitigating something that was already “handled.” The naming becomes a kind of immunity – not from the bias itself, but from being challenged about it.

I don't think this is usually cynical. I think it's usually sincere. Most leaders who say something like this believe it. That's what makes it worth examining rather than dismissing.

What awareness doesn't do

Here's the part that systems thinking makes uncomfortable and useful at the same time: bias isn't a property of a person's intentions. It's a property of a structure, operating whether or not anyone in it means harm.

If the structure rewards proximity – more informal access, easier support, more face time with the people who decide who gets seen – then knowing that the structure rewards proximity doesn't change what the structure does. The reward keeps flowing to whoever is closest, exactly as before. Awareness changes what's in someone's head. It doesn't change what the system does with the people inside it.

I watched this play out in a smaller, almost domestic way. A “voluntary” in-office program was promoted around the same conversation – voluntary in name, but with a quiet asymmetry underneath it: people who happened to share an office with a particular decision-maker had a noticeably easier time getting support for almost anything, compared to people who didn't. Nobody designed that on purpose. It's just what proximity does, by default, when nothing structural counteracts it. The acknowledgment of bias and the unexamined program sat right next to each other, in the same conversation, and neither one moved the other.

What would actually count

If awareness were going to do real work, it would show up as a structural change, not a sentence. Something like: decisions reviewed by someone outside the immediate circle of proximity. A defined, visible process for how remote contributions get weighed against in-person ones. A named metric for what the “voluntary” program is actually meant to produce, checked against whether it produces it.

None of that happened here. What happened was a true statement about bias, followed by a false conclusion about what that statement accomplished.

What changed

I'm not writing this to call out one leader, or one decision, or one program. The honest version of this essay isn't about them – it's about how easy this trap is to fall into, for any of us, the moment we're the one with influence over who gets seen.

So here's the question I'd actually want a reader to sit with, slowly, rather than nod past: the next time you catch yourself naming a bias out loud – in a hiring decision, a promotion cycle, a performance review, a budget call – ask what changed structurally as a result of naming it. Not what you said. What you built, removed, or redesigned.

If the answer is nothing, the bias didn't go anywhere. It just got a more comfortable name.

Performance evaluation processes can be a great fuel for personal growth. However, some strategies become the obstacle or even sabotage any chance at growth.

Focusing on weaknesses

Working on one's weaknesses is great, if done for the right reasons. However, if the process forces people to work on skills they hardly use, just because they're a requirement on a checklist, it can kill all motivation to grow.

Forcing a great engineer to learn management skills, just to move to a senior position is one common example. Skill matrices are particularly prone to this.

Grading on a curve

Grading on a curve, or allowing for only a set number of promotions a year, or providing a set budget of points to distribute within a team towards promotion, all of those have one thing in common: They incentivize joining weak teams to get promoted quickly and leaving high-performing teams, because they slow down a personal growth trajectory.

Systems like this will lose self-motivated high-performers, that don't want to leave their teams hanging for their own gain. They're a great environment for the politically savvy, that don't mind a bit of back-stabbing to look better than their team mates.

Targeting averages

Similar to grading on a curve, targeting averages across teams, departments or a whole company incentivizes back-stabbing or even sabotage to look better by comparison.

They offer a second incentive too: Joining a low-performing team and taking it slow, joining the low average that then will be increased to stay inside the target band.

Hidden agendas

Nothing hurts trust and motivation more than a hidden agenda. Teams are fully dependent on what their managers and the company as a whole communicate. Great motivational speeches about career path systems are very common but it's just as common for those to not reflect the whole truth.

Some companies value looking good over transparency. They praise career opportunities and rewarding individual growth, but then, when the chips are down, apply methods like the ones above to 'equalize teams', 'harmonize growth' or 'avoid having too many leaders'.

Motivation from this is temporary. At some point the people will catch on, motivation will drop and churn will increase.

Recommendation

Design your career model with transparency and fairness in mind. Allow employees some freedom to develop the skills they are most interested in or motivated by. Evaluate them as objectively as possible, based on demonstrated behaviors and past performance. Reward success on team level and growth on personal level. Be open about your intentions.

Nice and handy term. Looks very german. Essentially, it means to build on your strengths (as opposed to mitigating weaknesses).

Time and again when people are struggling with their next career steps, trying to understand where their path leads, or who are unhappy with the options that present themselves, they turn to self-discovery. And in doing so, they invariably are confronted with their weaknesses. Our knee-jerk reaction is to tackle those head-on and mitigate them.

Don't do it.

Or, at the very least, be intentional about it.

I have a colleague who is in just such a situation right now. She's found some areas she calls “weaknesses” and that's where her development focus ended up.

When I suggested, she should not do that but focus on “Stärken stärken”, she was confused: Aren't people supposed to mitigate their weaknesses first?

I asked her a simple question and her eyes went wide:

Do you want to stand out or fit in?

This is really the key distinction. When mitigating your weaknesses you get to a “well-rounded” skill-set. Jack of all trades, very employable. Master of none, vanishing in the crowd.

When focusing on your strength, you build a skill-set that is much more specialized, but you get to operate on a much higher level. You're qualified for very different jobs.

When my team and I started working on our new project, it seemed like this daunting pile of work with no end in sight. Initial guesses put us at a time horizon of four months to get it all done. It was way later than everyone would have liked.

So we set out to see how we can speed things up. At first we started to negotiate the scope, but we were already looking at an MVP plan, there wasn’t much to trim. With a fixed scope – our backlog in hand – and a clear budget – 40 person hours in any given week (at best) – we turned to look into getting the most out of the time we have – and to figuring out where we were losing time.

Enter stage right: A tool called LinearB provided us insight into our current flow of change.

Coding time → time waiting for a review → time it takes to review → time waiting for a deployment → deployment

Looking at the data immediately made it clear that we were losing or wasting a lot of time, waiting for things to happen.

With LinearB as a canary, we made a number of changes to improve our flow of work. Every time, we kept tracking if indicators moved in the right direction. This post is just about the first and possibly most impactful step we took.

There’s very little reason to wait for reviews, and virtually no reason to wait for a deployment.

Just Leave it Out

The most straightforward way to eliminate these waits is to do just that: eliminate them.

Mob programming or ensemble programming are the best approach to this: The whole team works on the same problem together, in one large session with a shared screen. Once a problem is solved, everyone has seen, contributed to and reviewed the solution automatically, by virtue of being present. (There's a bit more to it, but bear with me for argument's sake.)

This is a highly effective step and yields surprising results. It's also very counter-intuitive to most people. Getting a dev team and wider organization on board with this technique is a whole endeavor in and of itself, in many cases.

So with this idea promoted to ultimate goal, I thought about what first step we could take to make small-but-significant improvements to our way of work. This is the first iteration, we came up with.

The Rule

We changed our workflow to focus on these waiting things first, with a very simple rule:

When picking your next activity, focus on the right-most column first.

1. Deploy what needs deploying – the right-most column (besides Done).

2. Then review what needs reviewing – second column from the right.

3. Then see if you can unblock blocked tickets (we placed the Blocked column after In Progress).

4. Next, try to help out with something already in progress.

5. Lastly, start a new item.

Our cycle time (DORA definition: the time between starting development and deploying the code to production), shortened quite a bit, just from eliminating the waste of waiting.

Why does this matter? Aren’t we working in sprints, delivering a package at the end?

It matters because focusing on delivering every task as soon as possible allows for the fastest feedback cycle. Every step after the initial coding time adds feedback and improves the work. Wait time delays this feedback, but without this feedback we can’t know if a given task is in fact done already. We run the risk of not finishing the story within the sprint. Earlier feedback mitigates that risk and increases the chance of delivering everything we committed to.

When focusing on the thing on the right, you’re focusing on the right thing.