Observations of Leadership (Part Two)

Hey again! Welcome back to part two of me reflecting on the past few quarters and writing down my answers to John Cutler and Tom Kerwin’s questions on how leaders navigate uncertainty and ambiguity. If you’re lost, part one is here. I started writing my reflections to this a while ago (almost two years now!) and decided that I actually wanted to separate out every edition of this by a few years. That’s how long it takes for feedback cycles to truly hit at my level, anyway, and it’s a good excuse to practice self reflection. I’ve also grown to enjoy seeing how my thinking matures over the years, and this is a natural way to do that.

My life has also changed quite a bit since the last post. I left that company about six months after writing that post and joined a major financial firm as a software architect, specialising in architecting distributed systems and zero trust networks. After working on some very large scale architectural plans there, I immigrated to the Netherlands and joined a different financial firm as a software architect, with the goal of contributing towards resilience efforts across the entire firm. Consequently, I’ve gone through quite a lot of ego death in the last year; it’s humbling to be an immigrant. Additionally, no matter how you try to develop the skill of reasoning about large scale changes, there’s only so much experience you can get at startups; my last two companies being mature enterprises have given me the opportunity to add much needed depth to my perspectives. While I’m at it, you’ll notice that my examples get a bit more vague here; working in a regulated industry doesn’t make it easy to go concrete on details. Regardless, I’ll do my best to share what I’ve learned–luckily the lessons are, I think, largely conveyable without numbers or UUIDs or getting myself in trouble.

Without further ado, here we go!

Blend Diverse Perspectives

Can you tell me about a time you needed to make space for many diverse perspectives, including those that you found particularly challenging? How did that inform collective decisions and actions moving forward?

– https://cutlefish.substack.com/i/142017363/blend-diverse-perspectives

This has been a huge area of growth and maturity for me. In smaller companies, I have found that it’s often accurate (or at least a functional mental model) to think of things as “us vs. them”. In other words, you don’t really tend to run into situations where you need to make space for diverse perspectives. The strategy is often more around taking those diverse perspectives and winning them over to your way of thinking. There’s not a lot of room in a small company for multiple diverse perspectives to run simultaneously, so it makes sense that you primarily prioritise consensus rather than loose alignment.

However, at larger companies, you run into the inevitability of complex systems. One of the most unavoidable aspects of a complex system is that as you have multiple actors operating, you inevitably will find them operating at cross-odds with each other. These actors are not necessarily on opposite sides, and often are even on the same team. They could even be trying to work for the same purpose! But ultimately they’re going to operate at cross-odds and appear to undermine each other.

Not only is this unavoidable, not only is this inevitable, but it’s actually also–surprisingly–not undesirable. This was one of the more interesting things for me to learn. It turns out that operating at cross-odds creates friction, which is obvious. What’s not obvious is that this particular flavour of friction is incredibly valuable and deeply informative. When you know actors are working towards compatible goals and yet are operating at cross-odds, it forces you to consider the design space and the solution space in a more diverse and interesting way.

So now, when I’m thinking about working at cross-odds, I want to make sure that it happens. I don’t want to avoid it; after all, it’s unavoidable. Given that, I want to ensure that it happens in the right places, at the right time, and in the right amounts. Otherwise you have too much similarity going on and the organisation is not seeing enough of the solution space or problem space to understand where there are complexities. If everybody gets aligned immediately and is spontaneously cooperative, it’s either not an interesting problem or the solution is too simple to work in practice.

As an example, I was at a company and we were doing a proof of concept. The team had been rolled out, we were part of a new department, and we were focusing on trying to prove out a very large potential initiative. One of the problems that I ran into immediately was that I couldn’t quite understand why we were doing things the way that we were doing them; it felt pointless, like we were working at cross-odds with the rest of the firm. To illustrate: we had a few different subsections of the project, and the more I dug into them, the more I realized a few quirks. One subsection of the project could be entirely consumed by a separate and existing team in a different part of the organisation. Another subsection of the project could have been handled by yet another team who were already subject matter experts. A third subset from the project was actually something that was novel and interesting, but was ultimately unlikely to succeed for reasons outside of our control. Lastly, the scope, roadmap, and timeline were utterly impractical and inconsistent: It felt very much like something that was trying to boil the ocean, but with a set of resources that was only feasible for boiling a puddle.

As the project developed, it completed a proof of concept that was considered “wildly successful” and generated lots of positive attention. Naturally, shortly after, multiple staged re-orgs happened. During the re-orgs, the project got split up into multiple different teams, multiple different areas of the organisation, and modified its roadmap. Now, behind the scenes, what I came to understand was that this was how innovation actually happened at a company of this particular political structure; I hadn’t understood the success criteria initially, and once I did, it all made sense.

The reason why the initial design was setup was so that the reorganisations could inevitably happen. In addition, the project scope was overly ambitious for two reasons. One, so that when it was cut down, the critical pieces could be kept. Secondly was that as the project went over into multiple different parts of the organisation, each party had their own set of priorities and needed sufficient political leverage to demonstrate why they needed more funding to achieve the goals stated. In other words, a lot of the “wrongly” sized aspects of the project occurred as we absorbed various roadmap political agendas of stakeholder teams; when they “acquired” their part of “our” project, they needed to cut their roadmap some and adjust. However, if our roadmaps were secretly already partially pre-merged, then the “cuts” look extensive but are actually not that bad; in addition, there’s now ample leverage to demonstrate that extra funding is needed to accommodate disruptions from the multiple re-orgs (despite underlying teams staying almost entirely the same). When things inevitably got delayed or disrupted later, and when budget and scope creep occurred, leaders could reference the “original” plans and use them to provide a stronger argument for more resources. If they made the argument without validating anything, they’d look greedy as a leader, but if the initial proof of concept organisation made the argument and despite everyone’s best efforts to keep costs low… Well, that’s a different story. It further turns out that the executive(s) in charge of the organisation had a habit of making severe budget cuts and then adding back funding as needed, so this was a compensatory measure to prepare for that.

Ultimately, how this ended up changing collective decisions and actions moving forward once I understood this was that it became very critically important to understand your stakeholders. Not in the nebulous “stakeholder management” sense, but in a very concrete manner and with a specific strategy behind it. Your stakeholders need levers to do political maneuvering. They have resources, they have a budget, they have a timeline, and what you need to do is understand how to help them win at what they’re trying to do; it’s an entire unspoken language. Essentially, you need this notion of reciprocity, and you needed to be able to develop reciprocity with a multitude of teams in various organisations. Importantly, you also need reciprocity with leaders who also want that mutual reciprocity… But who also have no problem simultaneously playing this as a zero-sum game and stabbing you in the back if they think that it’ll give them an advantage.

The paradox of cooperation becomes that we need to simultaneously all buy in to the idea that there’s this reciprocity, and yet also simultaneously never truly believe it for a moment. Which felt like a bunch of stupid horseshit when I first encountered this type of thinking. It’s why a lot of people say “they don’t like politics in companies”. After all, this type of thinking feels extremely toxic at a small or even medium or even semi-large enterprise (and at almost any startup, it certainly is). But at a large enough size of company, the complexities of the interdependencies and subsequent politics involved become such that this is fairly inevitable. It also means that, surprisingly, there are ways to keep it healthy. Of course, it’s not going to be healthy if it’s “backstabbing” (and definitely not if we call it that), but friction is interesting and this evolves into an extremely high bandwidth way of exploring otherwise insurmountable solution spaces.

In other words, it’s an outcome of the nuances that emerge at that many layers of overlapping strategy. You begin having emergent behaviour and meta-cognition and game playing and meta-gaming; it’s just going to turn out that way. So, weirdly, learning how to scale your strategy isn’t necessarily about scaling it to more players, it can very much be about taking those collaborative decisions and enabling them to happen in an eventually consistent way, across different levels of gameplay and theorizing.

I found all of this fascinating to experience.

Patience and Self-Repair

Can you share an example of a time you chose not to intervene in a situation, allowing it to resolve on its own? What informed this decision, and how did it turn out?

– https://cutlefish.substack.com/i/142017363/patience-and-self-repair

When I think of this question, one of the things that comes to mind for me is understanding why I am not intervening. For me, that’s actually the real question. Am I trying to save my bandwidth? Am I trying to teach them a lesson? Am I helping them build the skills of autonomy? Or is it some other reason? What is actually going on here?

Rather than developing a bunch of ad-hoc explanations for all this, I tried to look for something grounded in a scientific theory, because the arbitrary nature of deciding for myself when or when not to intervene felt uncomfortable. Luckily, I am a massive nerd and find a lot of utility in reaching for psychology here, so I did end up finding something useful.

There is a concept in psychology called psychological affordances. I find it to be something that now guides me in these decisions and has the benefit of wrapping up all of the different factors and blending them together into something that I can reason about. Psychological affordances for me gave me a way to understand when the conditions are right for an intervention and what that intervention may look like. For example, one intervention is not doing anything, so it turns out that whether or not you intervene in a situation is the wrong way to think about it. You are always intervening because a “non-action” is just as impactful as any other action you are taking. It is, in fact, an option of equal weight. Not making a choice isn’t an option as an intentional leader.

One particular example that comes to mind here is when I was working on developer experience at a prior company. We had a particular item that was listed as a major driver for developer experience in the surveys that we pulled out. This particular driver was “tech debt.” For several quarters in a row, it was consistently in the top 5 priorities that the company needed to address. However, it never make sense to address tech debt, and the reason for that was because these psychological affordances weren’t there; the conditions were “never right.” For starters, nobody in leadership was wanted to hear about it. There was always something around the corner that they wanted to focus on, always another thing that was a higher priority, and there was this perpetual feeling amongst the leadership of “we’re almost at the finish line and then…” You can’t sell someone on an intervention that sounds like putting on the brakes when their entire world revolves around pushing towards the finish.

More importantly, the way that roadmapping and prioritisation was structured in the company meant that engineers didn’t have a lot of say over their roadmap but were told they did. In reality, it was the product managers that were most responsible for roadmapping. The Product organisation had two huge issues. The first was that very few of them believed in tech debt as a concept and felt that engineers should just deal with it invisibly. Some even told me to my face that it was just an excuse engineers gave when complaining too much! The second problem was that product managers had almost no visibility into how the engineering teams actually worked and none of the leadership teams talked to each-other at any level lower than the C-suite. From the product perspective, they just designed a roadmap, then the engineering leaders said okay, and then would invisibly fail to deliver. Product leadership couldn’t understand why, due to lack of communication, and even if they did understand they didn’t know how to help developers because they were not given the information about what was actually happening. Critically, product managers were not reliably told the consequences or the impact of certain choices that had been made, and so kept running the engineering teams into “expensive” choices such as re-architecting or database schema changes.

All of that is to say that “tech debt” was essentially a loaded term and in-actionable. It was, however, a very common language to describe symptoms, and people used it to describe a multitude of various different things which had nothing to do with each other. Which also meant that there was no suitable intervention; there’s nothing we could do from the leadership team to actually fix the problem, because the problem wasn’t the tech debt, it was all the other things.

To address this, what I would do is every quarter I would look at the tech debt driver, I would read through commentary, and then I would go find literally anything else to accomplish. When I found another initiative that had the right conditions to be executed on, I’d massage it so that, when executed, addressed “a thing” tech debt was being used as a proxy for.

For example, one intervention was giving all the product managers access to the developer experience tools. Once I showed them how to use everything, to see the developer feedback, and to see what concerns teams had had, they were able to go and have meaningful conversations with the engineering managers and help set timelines accordingly. Additionally, it turned out that while the engineering leaders were under the impression that they didn’t have any influence on the roadmap, the C-suite, had the impression that the engineering leaders did in fact have control over their roadmap. So, I worked with C-suite, engineering, and product leaders, to make sure that all the implicit assumptions were laid out and clarified. Once assumptions regarding what the actual bandwidth of an engineering team should be were made explicit, and once teams parted out time accordingly, the tech debt problem started to go away “magically” on its own.

It was never actually about tech debt, it was about communication. Naturally, had I called it a communication problem, nobody would’ve talked with me; what kind of self respecting leader has bad communication issues? They were swamped with meetings! Of course they’re communicating!

Well yes, but also.

Anticipate Effects

Can you tell me about a time you needed to try to anticipate the unintended side effects of a difficult decision? What did you watch out for?

– https://cutlefish.substack.com/i/142017363/anticipate-effects

Oh man, this is a tricky one. This is especially tricky because uh, yeah, okay, anyway. Rest assured that while this will be light on concrete details, it’ll hopefully be just as insightful.

A while back, I had to look through and compare a couple different architectural choices of a very large project. If we made the wrong choice, it could have negative downstream effects for multiple decades, and the project’s impact potentially involved an exorbitant amount of money. Consequently, when a company has a decision this large, they really want to make sure that you are anticipating side effects; more practically speaking, you should really be doing as much work you can to cover your ass.

I understood that many other people on the project were going to cover risk from multiple conventional angles. Thus, what I tried to do was discover and address dark swan events. This meant that, for a variety of reasons (of which I will be hand-waving over), I ended up having to look at the corporate capture potential and supply chain continuity of multiple open source projects. One motivation for doing this was in order to determine whether or not nation state actors could get involved, and how that might affect the threat model of the project. In addition, I also traced every dependency of the possible architectural choices in order to understand and ensure that the underlying projects could continue to be maintained indefinitely (by us, by vendors, or otherwise). If that wasn’t the case, assurances were needed that potential vendor(s) in question had mechanisms in place to deal with that. There were, of course, many regulatory questions and various functional concerns, but the supply chain question ended up being the trickiest one to anticipate.

Looking at how the political and economic climate of 2025 ended up shaking out… Whew. When you’re right, sometimes you’re really fucking right, huh? (Have I mentioned how I hate being right?)

Anyway, in addition to the supply chain question, there was another line of inquiry that had to do around understanding the true aims of the project I was working on. The reason for this was that the solution that we had did address the presented business case. But arguably, if you wanted to truly solve the underlying need that the business had, the way to do it was to rethink the approach to the domain entirely, rather than solve the problem with the same operating model. Essentially, I grew to believe that what needed to happen was a rethinking the vendor relationships, IT Service Management, and the operating model around open source consumption entirely. It appeared to be the case that our strategic rethinking needed to be a transition away from playing a mutually cooperative game towards playing a maximally adversarial game. Unfortunately, when you do that, the risk that you can tolerate is substantially lower; you also have to weigh your tradeoffs in a very different way.

Summarising the research, I ended up writing out all of these concerns as well as strategies for addressing them appropriately and de-risking them. I then put all these into a series of documents that I published internally. These documents were then read… And politely, for the most part, ignored.

It made sense that they were ignored because they ran counter to a lot of the political agenda of the project itself internally, but what I found fascinating was the series of events that would occur later. About ten or months after these documents were written by me, pretty much point for point, every concern that I had listed out stopped being hypothetical and started being very concrete and real possibilities. One by one, all of the dark swan events that I had looked for started occurring.

Fuck me, I hate being right.

Luckily, because I had written all these documents, people were then able to refer to them and start strategising accordingly. However, it’s a bit difficult for me to convey how I did that, because the advice that I’d give would sound vague, hand-wavy and wish-washy: The honest answer is that this was pure intuition for me, and I just listened to the vibes and trusted my gut.

I suppose the best way for me to try and explain it is that I seek to understand where are there inflection points that result in having to change the way that you think about something. If you approach an event or if you approach a strategy as an incremental refinement, that’s how the majority of human progress happens. That’s good! Incremental is awesome, lean into that. But if you get locked into that mode of thinking, to where you can no longer find these points of inflection that require rethinking the rules in the game, then you can get caught very unaware when those events start to happen.

Another thing I keep in mind is that these events never happen as a one-off thing, they happen as a chain of cascading failures in your approach to strategising; your future-sensing “intuition” as leaders starts failing everywhere at once.

Looking back, it was a good thing that people ended up ignoring all the things that I wrote. I was horribly annoyed about it (because nobody likes being a Cassandra), but the distance helps reflect here. Had my concerns been “taken seriously”, and had they been addressed at the time, it would have cost the project its success because we would have been solving problems that did not politically exist yet. Later, when we did run into the problems and encounter them, we were able to do the pivot correctly, in part because the architects in question had been talking to me and had factored in some contingencies where possible. Of course, we had a team of competent people, so naturally we were able to address the problem once everyone agreed that it existed.

Therein lies the rub; as it stood, now it looks like we could predict the future better than multiple executives; because that’s statistically infeasible (given that they have more information than us on average), it gave people the large enough upset needed to realise they needed to update their mental models. That, more than anything, is what allowed the pivot to happen correctly.

It was far more important to create a scenario where everyone had to update their mental model than it was to be right about something “early.” Rather than feeling almost a year late like I initially thought it was, the timing ended up being right around the time that it needed to be.

Curiosity and Light Touch

Describe a moment you caught yourself making a snap judgment and instead opted for curiosity. What prompted this change in approach?

– https://cutlefish.substack.com/i/142017363/curiosity-and-light-touch

Honestly, I am still pretty bad at this. I like to think of myself as someone that strives for curiosity, but I am honestly such a judgy bitch at times. My intuition is pretty good, so I’m usually not out of line with it, but it’s really hard to hold back and approach with curiosity at times. Especially when some of these choices just really make you question everything you’re reading.

Something that helps me is I try to ask myself, “What are the environmental conditions that make what someone’s doing the most reasonable and rational possible choice to make?” When I dig into those environmental conditions and contributing factors, then I can figure out how to ask questions that are genuinely curious. What I don’t want to do is end up asking leading questions in bad faith; “just how stupid do you think you are” feels mighty cathartic to ask at times, but it’s never helpful.

Now for a pet peeve of mine: Leading with curiosity does not work unless you are truly and genuinely curious.

I see a lot of people asking questions with their ears sewed shut and it pisses me off; it’s a surefire way to make sure someone doesn’t answer the questions you do want to know the answers to. Which means that I don’t lead with curiosity unless I can figure out how to make myself truly curious and willing to understand the answer that they give me. If I can’t find that spark of curiosity, the bitchy snap judgment is usually accurate (or, more likely, it’s a signal for me to delegate this to another person with the right type of curiosity). Either way, I’m not going to be a productive leader in that moment, so I either turn it into an opportunity for someone else, or I shut the initiative down with clear and candid feedback.

I had a really interesting experience where this happened when I was working on improving developer experience. One of the items that I had been looking at carefully over the last couple quarters was a driver called Focus Time. It turns out that this driver had been in the top 10 priorities, but slowly it had risen to become the top priority that everybody was clamoring about. The problem is that when I looked at this, while I saw very clear signs from the developers, when I talked to the engineering leaders and managers, they were entirely unaware or unsympathetic. Somehow the signal was getting entirely lost.

This made me curious, so I decided to dig in and looked at all of the calendars of the developers and pulled some statistics. We found out that the developers, on average, had about two hours of meetings a week. When I saw this number, my first initial thought was to laugh. My second thought was “you whiny little bitches, just get over it.”

Now honestly, that’s a fairly valid reaction; it’s a very easy thing to think as a leader when you have over 35 hours of meetings a week and a full load on your plate that you have to get done on top of that. Then to turn around and listen to developers complain about a mere two hours spread over a whole week? It’s honestly hilarious. It’s so hard to be empathetic and curious in that moment.

Consequently, I initially was convinced that either the data was wrong, or the developers were or little babies. (Honestly, my money was kind of on the latter. It was very hard to take that data seriously!)

Because we had other major drivers that were more actionable and immediately impactful, I sidelined this for a few quarters until the signal had persisted long enough that it was unarguably present. When it finally became clear that the signal from the developers didn’t match the data and was significant, and I had dealt with all the obvious road-blockers that it could’ve been… Well, time to get curious! Because I couldn’t trust the data or take it seriously, I started by directly talking to all the developers openly and curiously, just casually interviewing them to understand what was actually going on.

What I encountered was quite illuminating. It turned out that several different things were going on.

Once I was able to approach the problem with curiosity, the required interventions became quite simple.

After all these interventions happened, the average meeting time for developers “rose” to nearly 6 hours a week. Additionally, it took less than a quarter for Focus Time to become the lowest priority driver to improve. It’s funny, because I theoretically could’ve solved it several quarters earlier… But I couldn’t take the problem seriously enough (and neither could anyone else); once I was able to identify a way to approach it with curiosity, the solution fell out fairly naturally.

Both/And

Can you tell me about a time you faced something that looked like a simple trade-off on the surface—an either/or situation—but it turned out to be a both/and situation? How did you navigate the situation?

– https://cutlefish.substack.com/i/142017363/bothand

Can I? Can I? Pffh, I can hardly think of a decision that wasn’t more complex than it appeared at first glance. (I run into these a lot in architecture.)

What I find is that often people aren’t thinking of things as a trade-off space, and they’re approaching it as a binary choice. When you think of the trade-off as a trade-off space, then it actually becomes a lot easier to understand that you may be looking at the wrong axis and you need to reorient yourself towards a different way of thinking. While that tends to make the problem become more complex, it also makes the problem statement more honest. It’s in that new honesty of the problem statement that the choices have to evolve and get correspondingly more complex in order to match the true complexity of the domain.

I had a situation with one project where the aim of the project was to achieve two goals: deprecate an existing component, and expand the scope of the project to address more needs. The trade-off on the surface is one of prioritisation: Do you develop the new functionality first, or do you prove value immediately by replace the existing component? This one ended up being tricky because it was very easy to pick one or the other and the idea of a “both/and” situation was not at all obvious. Politically speaking, the option to replace the existing component fits a lot with how the company liked to show value first and then roll out enhancements after the fact. That’s a very natural progression. On the other hand, we didn’t really know with certainty what the new functionality would look like, and how it might be implemented. The downside was that we might get quite far into a solution before realizing that the (more important) new functionality isn’t even feasible in the way we thought it was.

When I’m faced with a trade-off like this, one of the first things that I do is I try and understand what the trade-off space actually is. These choices, after all, aren’t really about the binary choice of “do the new roadmap” vs “do the old roadmap.” This is really about developing an evolving set of capabilities for the business with a set of complex intersecting criteria. When I dug in, picked apart the overlapping criteria, and started mapping out all of the different capabilities, it quickly became obvious that the true choice to be made was not about what part of the functionality to develop next. The choice was more fundamentally about was about what types of foundational capabilities and technologies do we need to develop as company in order to be ready for what lies ahead in the next 3-5 years.

The answer to that, naturally, ended up being: “a bunch of things that aren’t on the roadmap at all anywhere.”

Nobody wants to hear that answer. Absolutely nobody wants to hear that answer. However, when you do run into that answer, getting leaders to believe it, and getting leaders to understand how they need to re-evaluate the situation becomes really critical. Luckily, when you get past that hurdle, then the both/and situation turns into something you can collaboratively problem solve together.

Intervene Safely

Can you tell me about a time when you and your team tried out a new way of working, interacting, or behaving? How did you decide what to try? How did you figure out whether to double down or change again?

– https://cutlefish.substack.com/i/142017363/intervene-safely

This is an interesting question for me because despite the fact that I have spent a large chunk of my career designing interventions, analyzing them, and understanding how to get teams to work differently… I feel like this question is the one that, so far, I have been the least able to answer well. Honestly, I don’t know if I have a good story for this!

One thing that comes to mind is there was a situation on a team that I was managing where I was noticing a few things. Engineers were silently getting stuck and doing individual problem solving for days at a time; that was slowing them down way too much. Institutional knowledge was also getting locked up inside individuals and it wasn’t spreading across the team effectively. The team also skewed very bimodal, having both very junior and very experienced engineers; it was important to ensure that everyone felt comfortable and safe speaking up when they didn’t know something.

We also had hundreds of tedious fucking tasks to do. Tasks with ETAs of anywhere from twenty minutes to three weeks. Just horrible shit to work with and figure out, honestly.

I had initially attempted addressing this in the very traditional way of splitting tasks out into tickets, writing up all the tickets individually, assigning them to people, and then asking for for daily updates. Super standard, and super ineffective. It wasn’t working! Information stayed siloed, people were invisibly delayed, and progress wasn’t being made. It was just horrific. In response, we changed our way of working to a combination of mob programming and pair programming.

Initially, we went with mob programming: I grabbed the entire team together and we spent two days triaging all the tickets together by going into the actual codebases assessing out-loud whether or not the ticket was going to be an easy, medium, or difficult. When everyone was sharing their internal thoughts on this, all of a sudden, all the weird tips and tricks that the experts knew started coming out; all of the institutional knowledge of what would be difficult started spilling out and getting documented as well.

After that, it became substantially easier to assign people to work on the easy problems first. First, we went through a few tickets together as a mob. Beginning to end, we did the whole ticket together as a team and basically ran it like a collaborative live Twitch streaming experience. When everybody was in the flow and rhythm of knowing how these tasks could be accomplished, they could then break it down into pair programming, which was initially to be done only via zoom and on camera. After an initial adjustment period, I stopped requiring cameras on and live pairing sessions for work, and let people do it organically as the task demanded.

The results were magical and throughput shot up like a rocket. I knew that this had worked to change the way of working for our team when, for other projects and problems down the road, people started doing the mobbing and then pairing dynamic naturally. The way people shared problems and learning with each other changed as well. Overall, the ability of the team to collaborate became a very, very tight mesh. This ended up serving us incredibly well later on and helped make this team one of the best performing teams I’ve ever had the pleasure of leading.

Conclusion

In the last article, I ended this with “I don’t even know how to conclude this.” I’m happy to report that one thing about me is consistent: I still don’t know how to conclude this. However, this time I’m going to spare you a ~1.500 word conclusion.

See you in a few years!