Chris Lorig's Blog

Building Better Teams & Organizations

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.

By @cmw@dysfunctional.technology

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.

By @cmw@dysfunctional.technology

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.

By @cmw@dysfunctional.technology

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.

By @cmw@dysfunctional.technology

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.

By @cmw@dysfunctional.technology

As you grow your business and your team, keeping everyone on the same page can be challenging. To ensure that everyone is working in alignment, you’ll want to optimize the cognitive load in your organization. Cognitive load is the amount of mental effort needed to understand a task and complete it successfully. In other words, how much do you have to think about what you’re doing? In this blog post, we’ll walk you through three ways you can optimize cognitive load in your organization: identifying Cognitive Load Optimization strategies, using tools to track and monitor improvements, and implementing changes that reduce bad cognitive load as much as possible.

What does Cognitive Load mean?

Cognitive load is a term used in cognitive psychology to describe the amount of mental effort required to perform a task. It is the total amount of information and activities that a person's working memory can process at any given time. When the cognitive load is too high, it can lead to mental fatigue and decreased performance.

Identifying Cognitive Load

The first step in optimizing cognitive load is to identify the sources of the load. Common sources of cognitive load include:

  • Complexity of the task
  • Volume of information presented at once
  • Interference from irrelevant information
  • Lack of control over the task
  • Novelty of the task

Monitor Progress with Tools

Once the sources of cognitive load have been identified, it's important to monitor progress towards reducing the load. This can be done through a variety of tools, including:

  • Self-report questionnaires
  • Performance monitoring software
  • Eye-tracking technology

Optimizing Cognitive Load – Three Strategies

Minimize extraneous cognitive load

Extraneous cognitive load refers to the load that comes from information that is not directly relevant to the task at hand. To minimize extraneous cognitive load, you can:

  • Present information in small chunks
  • Highlight the most important information
  • Remove irrelevant information

Minimize intrinsic cognitive load

Intrinsic cognitive load refers to the inherent complexity of the task itself. To minimize intrinsic cognitive load, you can:

  • Simplify the task by breaking it down into smaller, more manageable steps
  • Provide clear instructions and feedback
  • Allow for customization of the task

Enhance germane cognitive load

Germane cognitive load refers to the load that is necessary to achieve a desired outcome. To enhance germane cognitive load, you can:

  • Provide meaningful, relevant context
  • Encourage exploration and experimentation
  • Use visualization and other aids to support understanding

Bottomline

Cognitive load is an important concept in optimizing performance. By understanding the sources of cognitive load, monitoring progress, and reducing extraneous and intrinsic load while enhancing germane load, you can ensure that you are able to perform at your best.

By @cmw@dysfunctional.technology

I'm impressed by what people accomplish with tools like Excel, Macros, and some no-code automation. Recently, my DevOps team and I had the opportunity to support a project that aimed to replace such an existing, purely hand-built logistics solution with a custom-built system.

The company hired experts with lots of prior experience in such projects. Those experts made project plans, designed interfaces, created road maps. Then everyone went to work. As projects are want to do, this one blew away early estimations and went quite a bit over the time budget. Pressure mounted and corners were cut.

It was a wild ride. The team tried to roll out the new system all at once, and it was a complete and utter disaster. They attempted and failed with several roll-outs and ultimately had to roll everything back. It was a humbling experience and a valuable lesson.

When we approach the implementation of such big projects, a phased roll-out is key.

First and foremost, it's essential to start with a thorough analysis of the current system. Understand its limitations and the pain points that the users are facing. Instead the experts fell victim to the law of the instrument: they approached the project with previous solutions already in mind.

The things we know that just ain't so.

(not) Mark Twain

Involve the users and stakeholders in defining the requirements for the new system. Ask them where their biggest needs and problems lie. This way, you'll have a clear understanding of what the new system needs.

Next, instead of trying to replace everything at once, start with a small set of functionalities. Then gradually expand as you gain confidence in the new system. This minimizes the risk of failure and allows you to stay agile.

Moreover, it's crucial to have a robust testing and validation process to catch and fix issues before they surface in production. And, a proper training and communication plan should be in place. It is key to helping the end users to be prepared and using the new system efficiently.

Salvaging the situation

In the wake of the rollback, I sat down with some stakeholders to really listen to what they need. We found that one capability was completely missing from the current system: Automated handling of returns. Gaps like this are the obvious first step for a phased roll-out. As there is no component to replace, the risk is minimal and even small improvements would pay off. It is also the last step in our workflow. For the phased approach, we could back-track, working our way us until we have everything covered.

In summary, when it comes to big projects implementation, a phased roll-out approach is key. Starting with a specific functionality that addresses a specific pain point minimizes the risk of disruption to existing business operations and allows for adjustments to be made as needed. Additionally, you need a robust testing and validation process, along with proper training and communication plan, to ensure the success of the new system.

By @cmw@dysfunctional.technology

Message queues, events streams, events sourcing, those fronts have almost become as entrenched as the language and editor debates. In the effort to win this religious war, engineers forget their actual use case and default to screaming into the void. But that's not the only way to go.

Screaming into the void is what happens when architecture ends at the choice of tools: You pick Kafka or Kinesis, set up a topic, add a couple subscribers and start publishing events. Nice and decoupled. The service sending the event does not have to pay attention to the consumers at all. Everyone can listen and decide what to do with the event they receive.

There is even a valid use case with this. Our old friend the Enterprise Service Bus often worked this way. Attached systems emit status events, like data modifications, inputs, deletions. Consumers on the bus would follow along and if there was something to do in reaction to a status change, they would do it. If this is your usecase, if you care about keeping other systems merely informed of the latest developments (like a news paper), you're all set. Keep going.

What else is there?

Of course we have to talk about everybody's favorite: CQRS, Command-Query-Responsibility-Separation. The quest to build this often enough leads to everyone screaming (their commands) into the void. But in this case you do care about your message getting received and you do care about what it effects. Screaming into the void is not good enough, in this case.

A command stream is more akin to a mail or telegraph system. You may not know which operator precisely will execute your command, but do know where to address your message to ensure it gets done. Architecturally, this means topic separation, at-least-once-processing, maybe dispatching.

Event sourcing is another audience favorite, that regularly gets mixed in when implementing the screaming-into-the-void pattern. Events get written into a queue and then are used as a basis to compute a current (or historic) state as needed.

For this application, screaming into the void is not only an anti-pattern, but actively opposing the use case. State change events (the source for event sourcing) get mixed with status updates (the consequence of a computed state change), commands (events that may or may not lead to state changes), commands, and anything else people see fit to send.

What do I choose?

Before making a choice, get clarity on what exactly you want to achieve.

Want to send commands to another system, have them processed in order, and generally care about the outcomes of your events? Try a message queue or at least ensure that the relevant constraints and processing guarantees apply.

Want to rely on your events as a data source that you can rearrange and modify and recompute to get to a state? Pick an actual event store or at least ensure that the topics are cleanly separated and events are guaranteed to be persisted to your expectations.

Want to keep your environment appraised of what's going on, but don't care about how they react what you do? Go ahead and buy Twitter scream into the void. Set up your favorite stream and publish your updates into it, for the world to consume or ignore.

By @cmw@dysfunctional.technology

I used to work with a team that struggled to give accurate estimations for their projects. Things were usually off to a factor 2-5x. I struggled to keep stakeholders at bay as delays accumulated and the whole quarterly plan grew later and later.

We tried various things to address this, from switching to a more flexible work flow to providing ongoing re-estimations as the project progressed. The results largely stayed the same: We were not able to even remotely predict when something was done and even rolling estimates helped as they only highlighted how much we had to correct our guesses in the course of a given project.

After several months of struggling, I eventually went back through the data and almost kicked myself when I realized what I saw. I tried to figure out why our initial estimations were so off, what it was in particular that we constantly missed, but I couldn't tell. It was just not clear from the data, because we didn't actually create all the necessary stories before starting the work: We just kept adding more stories as we progressed through the project. One project lead had it all in their head, but there was no actual plan upfront.

I almost kicked myself, because this lack of a formulated plan of action was something I had subliminally noticed several times. But I couldn't put my finger on it until it stared me right in the face.

But plans are useless, are they not?

Plans are worthless,

but planning is everything.

Dwight D. Eisenhower

No amount of planning will ever yield a set of steps that can be followed to a T. And such amounts of planning to even come close are a huge time sink, but don't really add value if you don't work on the scale of NASA.

Still, making a plan is essential, because it makes your thinking and expectation about a project transparent and provides an overview of the expected amount of work. That is an important basis for giving any kind of reasonable estimate at all. Furthermore it gives insight into the short-term road map which is important to some teams.

Most importantly, it allows you to improve.

To tell apart expected from unexpected work, find blind spots and systemic problems that will otherwise be hidden between all the other expected tickets, never to be found. It helps a team reflect on why these delays happen and be honest about things that don't work well.

Nobody actually expects to create plans that survive the contact with reality, but for this team there was definitely room to improve. Maybe for yours, too.

By @cmw@dysfunctional.technology

I've always been a startup guy, so especially early in my career, I never knew such a thing a career paths, plans or guides. I had to make up my own mind about what my next steps would be and how to get there.

A few years, I got into a heated discussion with a colleague who demanded (the audacity!) a career guide to tell them what their next steps would be. I tried reasoning with them, explaining how their career is – and should be – in their own hands, that nobody else would be better suited to determine their path, that nobody else would know what made them happy.

“But it's not about happiness! It's about my career!”

That stopped me in my tracks. For me the two were one and the same but for this colleague, they seemed to be fundamentally disconnected, to the point where they would abdicate control over one of them to a completely different person.

So I gave in, worked something out with my head of engineering and, lo and behold, even more people appreciated what we created and I learned that a lot of people around me were uncomfortable being left alone with such big decisions.

To make sure, this wouldn't happen again, I started learning a lot about different career models and how to find your way through them. It's completely reasonable to ask for guidance or people to tell you the next steps. However there are a few things that everybody needs to answer for themselves, if they want to pick a career that will make them lastingly happy.

Key questions

Why:

Motivation: What gets you out of bed and all excited to work in the morning?

Impact: What difference do you want to make in the lives of others by acting on this motivation?

Calling: What do you see as your “right” way to contribute to this impact?

How:

Passion: What skill or activity are you most passionate about when following your calling?

Practice: What practice do you plan to follow to improve your craft?

What:

Task decisions: How much freedom do you look for in how to execute your tasks?

Priority decisions: How much freedom do you look for in setting your priorities?

Strategy decisions: How much freedom do you look for in determining project/company strategy?

Learning decisions: How much freedom do you look for in defining your own learning path?

Project allocation decision: How much freedom do you look for in picking and choosing what projects to work on?

By @cmw@dysfunctional.technology