"No, no, the real problem is that the frontend team keeps changing requirements without consulting us—"

"That's not fair! We only change things when the designs—"

"Can we please focus on what actually matters here? The database performance is killing us and—"

You glance around the room. Three people are trying to speak at once, voices getting louder. The junior developer has stopped taking notes and is staring at their laptop. The tester in the corner hasn't said a word in twenty minutes.

Sound familiar? You're witnessing the third anti-pattern in our retrospective anti-patterns series: the shouting match. We've already covered the group therapy session and the blame game, and today we're tackling what happens when the loudest voices drown out everyone else: the shouting match.

You'll know you're dealing with a shouting match when one or two team members dominate through volume, persistence, or strong opinions, effectively shutting out others.

Your retrospective ends with apparent agreement, but several team members haven't bought in—they've simply been overpowered. Thoughtful and introverted members quietly check out, feeling unheard.

If this resonates, you're not alone. What makes this particularly challenging is that teams solve the wrong problems whilst real issues remain hidden, wasting time and tanking morale.

But when you get input from your entire team, you uncover insights no single perspective could provide. Picture a retrospective where the quiet backend developer shares an insight about technical debt, and a junior developer chimes in to point out a communication pattern senior members missed. Instead of the loudest voice winning, the best ideas rise through genuine collaboration.

That's the kaupapa we're working towards, and here are some ways that you can make it happen:

Structure the session for inclusion

Use techniques that give everyone opportunities to contribute. Try silent brainstorming or "sticky storming"—everyone writes thoughts on sticky notes and adds them to the board without talking. No one can challenge or remove others' ideas, preventing early ideas from anchoring discussion.

Similarly, use "dot voting" to prioritise topics for discussion. Each participant gets fixed votes to allocate to the sticky notes on the board however they want, then discuss from most to least votes. Again, no talking during voting, and no challenging others' choices.

Create a rotating facilitator role

Domineering team members rarely shut out others intentionally—usually a friendly nudge is all it takes to get them to share the spotlight.

Start by taking the facilitator role yourself to model the behaviour. Your job is to notice participation patterns and invite quieter voices. Picture your team’s DevOps engineer talking for five minutes about deployment issues while backend developers sit quietly. You step in: "We haven't heard from the backend folks yet—any thoughts on this deployment issue?" Suddenly you learn about a database connection issue that explains everything.

Or when your opinionated senior developer keeps dominating: "Thanks Mark. Jane, what's your perspective?"

For members uncomfortable sharing publicly, they can send their contributions to the facilitator via a private channel (such as Slack DMs), and the facilitator will present them anonymously to the group.

Once the team gets comfortable with this dynamic, rotate the facilitator role among team members. This prevents any single person from wielding too much influence over discussions and ensures everyone develops the skill of creating inclusive conversations.

Let the retro get (a little bit) meta

If seniority or role differences regularly affect participation, try acknowledging it during the retrospective. Sometimes calling out the dynamic will level the playing field and encourage participants to self-correct.

If the team do want to discuss how to better run retrospectives, just remember: there are no people problems, only process problems—gently redirect from naming names to improving process.

Making it stick

The key is consistency—these techniques only work if used regularly and adapted based on your team's dynamics.

Pay attention to who's speaking and who isn't. Notice which topics generate heated discussion and whether you're getting balanced input. **The goal isn't silencing strong voices, but amplifying quiet ones.**

Your next step

During your team's next retrospective, try this: look around the room (or video call) and identify who typically speaks up and who stays quiet. Then pick just one technique from this post—silent brainstorming, dot voting, rotating facilitator, or naming the group dynamic—and commit to using it consistently for the next three retrospectives. Notice what changes.

We're making good progress through retrospective anti-patterns! I'll be back in a few weeks to talk about Fear of Commitment and how to help teams that struggle to implement process improvements.

Let me tell you a story about how I broke the cycle, and why the solution worked better than I could have possibly expected.

The Problem: Cross-Team Deliverables Without Clear Ownership

Last year, while leading a major architectural overhaul project, I was watching three critical deliverables languish despite having capable teams and adequate resources: go-live planning, performance testing, and data migration. These all cut across team boundaries with no clear ownership—and if there's one thing I know about project leadership1, it's this: when you don't have a singular person accountable for making sure something gets done, it doesn't get done.

I knew I couldn't just arbitrarily assign these deliverables to existing teams—they'd have too many dependencies on other teams and would inevitably get stuck again. But I also couldn't take on planning and executing these myself; I'd become the ultimate bottleneck.

The solution hit me when I started thinking about matching communication structures to the work itself. If the work cut across team boundaries, why not create structures that did the same? So I decided to try something different: task forces.2

The Experiment: Cross-Functional Task Forces

For each stalled deliverable, I approached a capable team lead and asked them to assemble a dedicated cross-functional team. The conversation was easier than I'd expected—these team leads were already aware of and concerned about the deliverables that weren't progressing. They were keen to try a different approach, and frankly, they were excited about the additional responsibility.

Here's how I structured it—and this is where things got interesting. Each task force lead got their mandate—deliver X by Y date—and the freedom to negotiate for their own team members. They couldn't just conscript engineers; they had to kōrero with the other team leads to take some of each team's capacity, with the understanding they'd have to give it back if they weren't utilising it effectively.

That negotiation requirement turned out to be more of a feature than a bug. It created natural tension that put a check on task force size and ensured teams would grow or shrink as needed. But more importantly, it got the team leads talking and coordinating with each other constantly, which became the real game-changer.

How Task Forces Actually Operated

The task forces operated as lightweight teams, running regular standups, planning, and refinement meetings, but at a lower cadence than regular teams. Engineers often weren't 100% allocated, so they'd split time between their regular team mahi and task force mahi. Each task force lead represented both their team and their task force during project status meetings, and that way during my weekly check-ins with them, I could focus on providing guidance and coaching rather than directing activities.

What surprised me most was how little active leadership these task forces needed from me. Because the team leads had to negotiate regularly for resources, they were also planning together and learning from each other constantly. There was far less reliance on me to get into the details with them. Similarly, because engineers from multiple teams were also working together on technical challenges, information was flowing freely, and silos that had existed for months started breaking down naturally.

Why It Worked: Systems-Level Change

Now, I need to confess something: at the time this was absolutely one big experiment. I had a hunch it would work, but I didn't fully understand why until I started reading about systems thinking later. It turns out that what we'd stumbled onto was something systems thinker Donella Meadows calls high-leverage intervention points. Instead of trying low-impact changes like adding more people or tightening deadlines, we'd fundamentally altered how the system operated.

The task forces changed the purpose of work units from maintaining departmental boundaries to achieving specific outcomes. They increased the power of self-organisation by letting teams develop their own rhythms and decision-making patterns. And they altered authority structures by empowering task force leads to negotiate for resources across traditional hierarchies. Looking back, it's no wonder the approach felt so different from typical project management interventions—we were working at a completely different level!

The results bore this out. All three deliverables were completed on time and to high quality standards...but the real transformation went deeper:

• The constant negotiation between team leads created new information flows across the entire project.

• Developers who'd never worked together began collaborating regularly.

• Technical decisions that previously required lengthy approval chains happened in real-time.

• Knowledge gaps that would have surfaced during testing were identified and addressed weeks earlier.

• Task force leads developed new leadership skills that served them well beyond this project—they learned to navigate competing priorities, build consensus across departments, and drive results without formal authority.

The broader project reflected these improvements too: we went live on schedule, doubled the performance of the previous system, and completed the data migration well ahead of the deadline.

When to Use Task Forces

So when should you try this approach? Task forces are particularly powerful when your project's challenges are structural rather than operational. Look for situations where multiple teams or departments need to coordinate closely, traditional reporting lines create bottlenecks, or success requires both deep technical expertise and broad organisational knowledge.

Rather than fighting against organisational constraints, task forces work with systems thinking principles to create new structures purpose-built for complex, cross-functional challenges. Sometimes the most effective intervention isn't working harder within existing constraints—it's changing the system itself.

It's an understandable move. Glue work feels productive, leverages existing strengths, and provides immediate validation when coding feels impossible. Over time, a junior dev who consistently engages in this type of work may even become the "documentation person" or "unofficial project manager" on the team, with these tasks being directly assigned.

Be warned: this is a trap! It can be valuable for junior developers to learn how the business works and build relationships across the organisation, but if you're doing this at the expense of learning technical skills, you're stymieing your dev career.

Partly this is because technical competence is what employers evaluate in performance reviews and interviews, but more importantly you need a solid technical foundation to be effective at glue work itself.

Software is a sociotechnical system. Without deep technical understanding, you'll consistently misdiagnose problems — treating technical issues as communication failures1, or proposing process solutions for architectural problems. If you focus on glue work as a distraction from your coding tasks, your impact will actually become less valuable over time — and you will be in for the shock of your life during your next performance review!

If you're caught in this trap, here's how to break out:

Build habits for managing cognitive load

Junior developers are excellent problem-solvers. When a junior developer gets stuck, it's almost never because they lack the capability to learn their way through the problem, but rather because they've exhausted their mental capacity trying to keep track of too many details.

This is why having reliable techniques to prevent the build-up of cognitive load is absolutely crucial. When you're deep into a coding task, you need habits you can rely on automatically to wrangle the mental overhead — freeing up your headspace to focus on learning and problem-solving.

The good news is these habits are entirely learnable. Start by practising attacking problems methodologically, avoiding cross-contamination, and managing distractions. Work on building these habits during solo work and in pair programming sessions, and ask developers in your network how they manage their cognitive load. You'll discover surprisingly simple techniques that make a massive difference!

Experiment with "page out" techniques

Even with excellent cognitive load management habits, there will be times when a problem genuinely requires you to hold more information than your brain can comfortably handle. When you find yourself in this situation – feeling mentally overwhelmed and starting to lose track of important details – you need techniques to quickly offload information.

Just as a computer "pages out" extra data to the hard drive when RAM is full, you can use external tools to temporarily store information your brain doesn't need to track moment-to-moment. This frees up mental space to focus on the core problem without losing important context.

Effective techniques that I've observed in the wild include:

• drawing diagrams of components and connections

• taking detailed notes and reviewing regularly

• leaving breadcrumb comments throughout the code

• physically modelling the system with cards on your desk

Experiment with different approaches to find the ones that work for you, and practise reaching for them early — before you feel overwhelmed, not after.

Ask for the right kind of help

If you've been stuck in the glue trap for a while, breaking out requires more than just personal habit changes — you need your teammates to support you differently, too. Even highly skilled developers often struggle with mentoring effectively. They might think they're being helpful by taking over when you're stuck or giving you "easier" coordination tasks, but this actually reinforces the trap.

Here are some ways you can gently nudge them towards giving the right kind of help:

During pair programming sessions

• Ask to be the driver: "Could I take the keyboard? I learn better when I'm typing."

• Resist accepting direct answers and instead ask for leading questions: "Rather than telling me the solution, could you help me think through what might be causing this?"

• When senior devs offer to "just fix it quickly," push back gently: "I'd really value watching you work through the debugging process — could you talk me through your thinking?"

During your next one-to-one with your manager

• Explain that you're refocusing on technical development and discuss what support you'll need from the team.

• Be specific about the types of tasks you want to take on and the mentoring style that helps you learn best.

When glue tasks come your way in standups or sprint planning

• Deflect diplomatically: "I'm keen to focus on building my technical skills right now — could someone else take this on?"

• Suggest pairing glue work with technical components: "I could write that process doc if I can also build the automation script to go with it."

Remember: a job is a relationship. Your manager and teammates want you to succeed, even if they don't always know how best to support you. By clearly communicating your goals and demonstrating your commitment to growth, you're making it easy for them to help you escape the glue trap and build the technical career you want.

I think this is because of two fundamental misunderstandings that we have about estimates:

1. That the most important information in an estimate is the number of hours it will take to build something.

2. That estimates are an artefact that we toss over the wall to stakeholders so they can approve project budgets.

If you want to turn estimation into a practice that will create value not just for your stakeholders but also for your development team, you'll need to confront these ideas and turn them on their heads.

1. Estimates quantify risk, not effort

Stakeholders aren't naïve. They understand just as well as developers that every number in an estimate is held up by a rickety scaffolding of unknowns, assumptions, and contingencies.

Where we run into trouble is we hide away those unknowns, assumptions, and contingencies and try to pretend as though they don't exist — and then stakeholders take us at our word.1

It's time to break the chain. When you're estimating, take all of those assumptions and risks that could potentially cause that number to change, and write them down along with the estimate.

• Are there any requirements that are unclear or likely to change? Note them down.

• Any dependencies or integrations that might not be compatible? List them.

• Will you need to touch the legacy codebase that falls over every time someone so much as gives it a quizzical look? Don't keep it to yourself.

• And so on.

Once you start doing this, you'll notice two things:

1. It will become obvious just by looking which are the riskiest parts of the project. The deliverables with the most (or scariest) assumptions backing them will stand out as the most risky.

2. You'll start spotting opportunities where the organisation could potentially invest in reducing some of that risk. Many unknowns can be explored, assumptions validated, and risks avoided simply by spending a few hours on additional discovery work.

On their own, these are two extremely important insights that your estimates can create for you. But if you want to unlock the true value of an estimate, you need to understand that...

2. Estimates are the start of a conversation, not the end of one

Developers often make the mistake of thinking of an estimate as a deliverable: stakeholders are asking us a question, and we give them an answer. Job done.

Then we go off and do the real (i.e. development) work, and no-one ever speaks of that estimate again...that is, until towards the end of the project when the stakeholders pull it up again and demand to know why we're so far off.

We need to squash the mode of thinking that estimates are something that developers create for stakeholders. An estimate isn't a deliverable — it's a framework for having constructive conversations about risk.

When you bring forward your perspective of where the most risk exists in the project, and stakeholders bring their perspective of where the most value can be created2, it facilitates making key decisions such as:

• Valuable but risky deliverables where it makes sense to invest in some additional discovery to de-risk them

• Risky and not-valuable deliverables that we should drop from the project entirely

• Estimates with low certainty/confidence where it's worth spending additional discovery hours to map out some of the unknowns3

• And so on.

Once you start having these conversations and making strategic decisions with stakeholders, you'll notice that you're more reliably avoiding major issues and changes that used to cause your projects to completely blow out their estimates. You'll stop getting pulled into obnoxious "please explain" meetings...and who knows, you may even find that your estimates start getting more accurate.

Times have very much changed, but one thing that has remained resolute is the fact that many software developers – myself included – chose that line of work because we enjoy talking to computers rather more than talking to humans.

Unfortunately for us, talking to humans is still the best way to advance your career2, and that leaves us introverts in a bit of a pickle.

The good news is, introvert networking is a thing. You can absolutely be a successful networker even if you don’t like crowds, despise small talk, or hate the taste of coffee.

You just have to stop playing by the extroverts’ rules.

In this post, we’re going to explore three ways that you can build and maintain your network as an introvert:

• Focus on what you can learn, not what you can get.

• Mentors? Hard to find. People who know stuff? Those are everywhere.

• More frequent contact is better than more contacts.

Networking gets you access to perspectives, not opportunities

We’re used to thinking of networking as a tricksy way to bypass gatekeepers: build strategic relationships, so that one day when you need a job, they’ll sneak your CV onto the top of the pile.

And if this makes networking feel transactional, insincere, and manipulative to you…that’s a good thing. Hold onto that feeling — it means you’re human.

But if that’s all that you think networking is good for…well then, you my friend are missing out, big time:

• How do I keep up with the latest trends and tech in my industry?3 Easy: I chat to the people in my network.

• How do I learn new approaches to solve technical and leadership challenges? I talk to my network.

• What do I do when I’m stuck on a problem and need a sounding board to bounce ideas off of? Network.

• What if I need advice or recommendations? Say it with me now…

Sure, from time to time my network might toss an opportunity or two my way, but that’s just the cherry on top of an alpaca-sized cupcake of insights and learnings that I’ve leveraged to advance my career on my own terms.

This changes the game completely because if there’s one thing we introverts absolutely love to do, it’s having deep conversations with people about stuff that actually matters.

With this in mind, let’s look at how you can optimise your network to get access to all the perspectives.

Focus on what you can learn, not what you can get.

During your first few months in a new job, you are a bit of a superstar because you bring a wealth of ideas and solutions that you learned about in previous roles. But after awhile that stockpile runs out, and your productivity begins its painful reversion to the mean.

Except…what if you could keep replenishing that supply without having to change jobs every few months?

This is why it’s so valuable to network with people who will introduce you to a diversity of ideas. When thinking about whom to reach out to, focus on what you can learn, not what you can get.

Don't worry about their role, or whether they might be able to hire you, or even whether they know someone who could hire you. In fact, try networking with some people in entirely different fields and industries than you. You will be surprised at how many unique insights you can glean from their experiences that you can apply in your own work!4

Mentors? Hard to find. People who know stuff? Those are everywhere.

The best and worst advice I ever received about career development is: get a mentor.

It’s amazing advice because if you can find someone at the top of their field who’s willing to take you under their wing, teach you all the secrets, and help you avoid all the pitfalls…that’s like winning the career lottery.

And it’s terrible advice because you’re about as likely to find someone like that as you are to win the actual lottery. People are really busy, and unless you already have an amazing relationship with a potential mentor, it's unlikely that they’ll be willing to commit to a long-term investment of time and effort. Nothing personal.

But you know what's really easy to find? People who know stuff about specific topics and love to talk about them. By approaching the interaction as a one-off chat about something that you’re both interested in, rather than the beginning of a long-term relationship, you’ll find that most people are actually quite enthusiastic to connect.

More frequent contact is better than more contacts.

Winning at networking doesn’t mean getting to Dunbar’s Number as quickly as possible. If you have 150 people in your network5 but only talk to each of them once a year, you're not going to be able to build meaningful relationships. And anyway, it’s exhausting to keep up with so many people! No wonder we introverts hate networking so much!

But what if we stopped treating networking like a numbers game? “More is better” only works for fungible things like Bitcoins, pokémon, and romantic comedies6. When it comes to people, more frequent contact is way better than more contacts.

Focus on quality, and the quantity will take care of itself. Just find people you enjoy talking to so much that after each chat, you feel like you literally can’t wait until the next one. Do that, and you’ll never be short of interesting perspectives!

Above all, be kind to yourself.

Every person is different, and so every relationship is different…and that means that the best way to network will be different for each person.

Don’t worry about whether you’re “doing it right” — if what you’re doing is working and you enjoy doing it, then that is the right way to do it. Sustainable networking is successful networking.

I have a lot more to say on the subject of introvert networking, so there will definitely be more posts about this in the future. In the meantime, if you have thoughts about this or want to chat, get in touch! Just don’t take it personally if it takes me awhile to reply — I’m pretty introverted.

There is a kernel of truth to it: the digital tech industry is crowded at the bottom, and landing that first role is so important that it’s usually worth it to take an “accept first, ask questions later” approach to job offers.

However….

I mentor many software engineers throughout their careers, and when I talk to junior and intermediate developers who are thinking of moving on from their first employer, far and away the two most common reasons they cite are:

• Their learning has plateaued.

• Their career progression is unclear or stalled.

In third place, we have values misalignment and culture conflicts – i.e., they had to take what they could get for their first role – but it’s almost always accompanied by one of the above two points.

This is good news because it means that if your junior developers aren’t sticking around, it is absolutely within your power to fix this problem.

In this post, we’re going to tackle this problem from three angles:

• Start with a learning plan for each developer that balances their interests, your goals for them, and the organisation’s needs.

• Take notes and look for trends, so that you can provide strategic guidance, not just tactical feedback.

• Continually adapt as reality asserts itself, so that the developer always has high-level goals to work toward.

Mentoring junior developers means creating structure

Junior developers are every bit as good at (and as hungry for) learning and growth as their more senior teammates. However, because they are so new to their discipline, they don’t yet have sufficient context to plan out their learning over the medium-to-long-term. Without guidance, they will soon run out of low-hanging fruit…and that’s when they start looking around for juicier opportunities at other organisations.

This is where you come in. You can provide that structure and direction for their learning, so that they are continually growing, they are aware of the progress they are making, and most importantly, they can see even more challenges and opportunities waiting in their future.

Start with a learning plan

To kick things off, during your next one-to-one with each of your junior developers, design the first iteration of their learning plan by discussing and balancing these three factors:

• What do they want to learn? Even if they might not initially have a strong understanding of what they want to learn, it will help you get a general idea of where their interests lie, and it will plant the seed that managing their professional development is a shared responsibility.

• What do you want them to learn? This will be based on how you want their career progression to go. It could involve mapping a path towards intermediate status, or it might include specialisations such as devops, cybersecurity, test automation, etc.

• What do the team and the organisation need them to learn? This will be based on the tech stack, cross-functionality gaps, upcoming migrations, etc.

You’ve likely clocked that all of this changes over time, so don’t worry about getting the learning plan perfect at this point. Just focus on putting together a first iteration that feels about right, knowing that you’ll be adapting it as the developer makes progress and as circumstances change.

Take notes and look for trends

For most managers and mentors, supporting a junior developer in achieving their learning goals takes the form of weekly or fortnightly one-to-one meetings, sometimes accompanied by pair programming and code review.

These are excellent tactical tools. Checking in week-to-week gives you opportunities to make observations and provide immediate feedback, but these need to be supplemented with a month-to-month view, so that you can also give the developer strategic guidance.

How is the developer tracking overall? Are there specific challenges or concepts that they tend to struggle with? Are they gaining momentum, or are they getting stuck? Are they still on-track, or do they need to pivot?

To answer these questions, you need to be able to retain and compare your observations over many weeks and months. For a busy manager with an entire team to look after, this is simply too much information to keep mental track of.

Which is why you should absolutely delegate that task to a notepad or digital file:

• During each mentoring session with a developer (one-to-one, pair programming, etc.), keep a physical or digital notepad handy, and take high-level notes about their progress, habits, and obstacles.

• Once a month, take a moment before each one-to-one to go back over the past month or two of notes for that developer, and look for trends. Use your discoveries to inform the agenda for the one-to-one meeting.

Your developers will notice and begin to anticipate these monthly “strategic one-to-ones”, and they will quickly become the most valuable conversations you have with them.

Continually adapt as reality asserts itself

Just like software, learning plans are never finished.1 During your monthly strategic one-to-ones with each developer, revisit the learning plan, recognise their progress, and see if a new iteration is needed. This helps you ensure they always have high-level goals that they’re working towards.

Remember that an effective learning plan strikes the right balance between:

• What the developer wants to learn.

• What you want them to learn.

• What the team and organisation need them to learn.

And don’t forget that keeping track of things is just as important a skill for you as it is for your developers. Make sure that you’re taking notes and looking for trends so that you can provide strategic guidance, not just tactical feedback.

Before you know it, you’ll have a hard time keeping junior developers…because you’ll be regularly promoting them into intermediate developers!

We all know that we’re not supposed to blame individuals during retrospectives, but…you know…sometimes when bad things happen there’s clearly someone at fault, right?

Maybe a team member bypassed code review to merge in a controversial change, which ended up causing downtime and a hasty rollback.

Or perhaps someone rushed through a schema migration, resulting in a late night spent restoring corrupted data.

Or maybe a team member got stuck on a problem and spent half the sprint at the bottom of a rabbit hole instead of asking for help, until it was too late and the team missed their sprint goal. And so on.

Whatever the cause, the result is always the same: as soon as the topic comes up during the retrospective, everyone’s head swivels simultaneously to stare down the instigator of the team’s misery.

How do you keep things on-track, avoid personal attacks and defensiveness, and most importantly, how do you ensure your team comes out of the session with an actionable plan to improve things together?

The perfect blend: one part collective (team) ownership, two parts curiosity

The key to winning The Blame Game is for your team to take collective ownership of the problem, and to be curious about the perspectives and circumstances surrounding the incident.

There are many different ways you can facilitate this during your team’s retrospectives. Below are a few examples of approaches that I’ve used.

There are no people problems, only process problems

No-one is the villain of their own story. Sure, maybe someone made a mistake that negatively impacted the team, but in the moment they genuinely thought they were doing the right thing. They were just missing a key piece of information or a critical step in the process that would have helped them to make a different decision.

Shift the focus of discussion away from the person and towards identifying what that missing piece could be:

• “Where did our process fail? How can we make it more robust without slowing us down?”

• “What knowledge could have helped us to make different decisions? How do we make that information more accessible?”

Software development is a team sport

A high-performing team doesn’t require every member to be a superhero. Rather, a high-performing team has learned how to work together to create something that is greater than the sum of its parts. When a member of the team makes a mistake, the team must collectively own that mistake, so that they can learn how to be even more effective together in the future.

Try nudging the conversation towards fostering more collaborative ways of working:

• “As a team, how can we support each other better, so that no-one ends up in that situation again?”

• “What would have been a better outcome, and how could we have worked together to help bring that about?”

If you have a team charter or working agreement, this is a chance to reaffirm (or revise) your team’s ways of working

Many teams have a team charter or working agreement…filed away somewhere in the company intranet, untouched and un-viewed since the day it was created.

Retrospectives are a great way to keep this part of your team culture relevant:

• “This sounds similar to something we talked about when we last iterated on our team charter. Did we miss an opportunity here to help each other to stay true to our shared values?”

• “I don’t think anything like this came up during our last working agreement session. Maybe this is an opportunity to schedule some time to draft the next iteration?”

Avoid the temptation to make amendments to the team charter or working agreement during the retrospective. These sessions require a different mindset, and you don’t want recent events to bias the outcome. Instead agree to scheduling a session to work on the team charter and then move on to the next topic.

Keep cultivating curiosity and co-operation

The common through-line for resolving team conflicts during retrospectives is collective ownership and curiosity.

As the team manager, in rare cases you may have to step in to address performance or certain interpersonal issues. The remaining 99% of the time, however, you’ll affect more lasting positive change by:

• Helping your team members accept collective (team) ownership of each problem, and

• Facilitating curiosity to explore different perspectives of problems and potential solutions.

Remember: retrospectives are about the future, not the past.

In the meantime, we’re not yet done with retrospective anti-patterns! I’ll be back in a few weeks to explore The Shouting Match and how to make sure everyone on your team has an opportunity to make their voice heard.

If you want to do it within 3 months or less, teach them habits to help them manage cognitive load.

Let’s look at a common source of conitive load that causes junior developers to get stuck: distractions.

The developer is in the middle of fixing a bug or implementing a feature, when they think, “Hmm, this code is kind of hacky; I should refactor it to make it cleaner.1” So they switch into refactoring mode and start rewriting, but then they bump into an unfinished part and have to switch back into solutioning mode.

This goes back and forth a few times, with the developer continually context-switching between refactoring and solutioning. Before long, they have a Frankenstein’s monster of half-implemented ideas, everything grinds to a halt, and the developer is well and truly stuck.

Our hypothetical developer isn’t lacking a technical skill. There isn’t a principle or pattern they can be taught to help them avoid this situation — they may even be able to cite solid reasons2 why the refactor is necessary.

The real issue is that the refactor is a distraction, and the developer hasn’t yet learned how to manage these distractions.

Unfortunately, the advice most developers receive about managing distractions is, “ignore them”, but this won’t work either.

Distractions are like kittens: they won’t tolerate being ignored for long

The trick (and where the metaphor hopefully breaks down) is to have a system for funnelling them into a holding area, so that you can deal with them later.

Here are some ways I teach junior developers good habits for wrangling all those fusspot distractions.

Ugly code that works first, then pretty code that works

New developers don’t understand the difference between coding and refactoring — and critically, they don’t understand that there’s a context switch that occurs when flipping between the two. During pair programming, help them identify when they unconsciously switch from coding mode to refactoring mode, and then to switch back before they lose focus on their original goal.

Construct a parking lot

As developers work, they will naturally identify issues and inefficiencies in the surrounding code. This is a good thing — it’s how a lot of teams discover the majority of their technical debt, after all. So, you don’t want your developers to disregard these discoveries, but you also want them to avoid getting diverted into rabbit holes.

To strike that balance, work with each developer to design and create their own parking lot. When they discover an issue in the code that would potentially distract them, they can stuff it into their parking lot, to be dealt with once they’ve freed up some headspace.

Experiment to find the system that works best for each developer. Some examples that I’ve found work well include:

• A separate text file, Notion page, etc.

• Adding stub cards to the product backlog.

• Adding warning comments (TODO, FIXME, etc.) to the code where issues are found.3

• Writing in a physical notebook or on sticky notes.

We’ll go over how to follow-up on the items in the parking lot in a moment, but first….

Commit after every win

Once the developer has a working solution – no matter how ugly – get them in the habit of committing their changes before attempting any refactoring.

This is useful for avoiding cross-contamination, but it’s also important for keeping that cognitive load at a manageable level. Until the changes are committed, the developer has to maintain a “mental snapshot” of their work, so that they can undo further changes in case they break something during their refactoring.

With practice, developers can build up their capacity to maintain these mental snapshots (to an extent), but especially for new developers it can be extremely taxing. Teach them instead to “page out to git”, so that they can free up mental RAM for the next operation.

Getting back to that parking lot…

After solving the original problem and committing changes to version control, the developer is now ready to go back and follow up on the issues they stuffed into their parking lot.

Some of the issues will be small or straightforward enough that they can be addressed right away (don’t forget to commit after every win!). Others will need to be added to the product backlog as technical debt.

Keep moving forward

In my experience, the biggest factor keeping junior developers from being productive is rarely lack of technical knowledge. Rather, where they tend to run into trouble is not having built up habits to manage cognitive load and free up that mental capacity to apply to technical challenges.

Teach your developers good habits for recognising and managing distractions, and leveraging git as virtual mental RAM, and you’ll start seeing their productivity gains compound.

It’s not the most important skill software engineers can have overall1, but I think it is easily the most important factor that determines how quickly a junior developer can get up-to-speed.

Here’s what it looks like when a developer is struggling to keep track of things:

The developer is working to fix an error or get some functionality to work. They try one approach and don’t get the result they expected, so they back out their changes to try something else — but they forgot some of the files they touched and end up only removing part of the attempted solution.

They try again with a different approach that would have worked, but instead it fails because of the changes they forgot to revert from the first attempt. However, the developer doesn’t realise this, and so they [partially] back out their changes to try something else.

After a few iterations, the developer has cross-contaminated the codebase with overlapping partially-implemented solutions. The app is now showing the white screen of death, and the developer is well and truly stuck.

Preventing cross-contamination

Cross-contamination is easy to catch during pair programming as long as the navigator is paying attention, and you can sometimes find artefacts of it during code review as well. However, the surest way to fix the problem is to coach the developer to build good habits, so that they can avoid it in the first place:

Check working copy status regularly

Each time they back out their changes to try a different approach, ask the developer to do a quick git status to make sure they caught everything. By regularly comparing their recollection of everything they touched against the actual state of their working copy, the developer will build that mental muscle.

Debugging statements need to get backed out, too

For better or for worse, developers (of all skill levels) tend to do most of their debugging by adding statements to print out values of variables and expressions…and they almost always forget to remove those statements later.

After a few iterations, the console gets polluted with lots of no-longer-relevant information, further increasing cognitive load and making it that much harder to keep track of things. Get the developer in the habit of removing debugging statements as soon as they are no longer needed.2

Teaching the developer how to use their IDE’s debugger is also super helpful in the long run, but choose your moment carefully — it takes significant mental effort and a context switch to learn a new tool.

Diff the code before committing

Every time a developer types git add . && git commit into their console, there is a fairy somewhere that falls down dead.

Before creating a new commit, encourage the developer to run git diff --cached and go over the changes they are about to commit. Reviewing the change set as a whole puts the developer in a different mindset to help them catch issues that they overlooked during coding, and it is another way to build that mental muscle by checking how well they remember the changes they made.

Teach them to love tiny commits

Expert rock climbers can scale sheer cliffs without a safety rope. In order to survive long enough to become expert rock climbers, novices must learn to hammer pitons into the cliff face periodically and attach their safety rope, so that they won’t lose too much progress (amongst other things) if they fall.

Software developers can do the same thing with code commits: as soon as the developer makes incremental progress towards solving a problem (and has passing tests to prove it), get them to make a commit. This helps to keep cognitive load manageable, and it acts as a piton for the developer’s progress — they can feel confident to make even radical changes to the code without risking losing their progress towards the overall solution.

Just as in cooking, the key to preventing cross-contamination is to build healthy habits. Coach your junior developers to manage cognitive load and build their capacity to keep track of the changes they make to the code, and it won’t take long before they develop the confidence and independence that they need to start their journey to intermediate status.

At one point code review served as an important stage-gate to prevent bugs, security vulnerabilities, and other code quality issues from getting into production (with debatable degrees of success, but let’s not get into that here).

However, now that we’re in the golden age of devops, your CI pipeline should be catching the vast, vast majority of quality and security problems, long before your pull requests get to the review stage.1 As a result, it should be very rare that code review uncovers a problem severe enough that it should prevent the branch from getting merged.

To stay relevant, code review has evolved into a practice for facilitating cross-training and upskilling within your team. It gives your team members a chance to familiarise themselves with what’s happening in other parts of the codebase, and it can be an exceptionally effective way for your senior developers to teach and reinforce software design concepts for your junior and intermediate developers.

But most developers haven’t caught on to this just yet. Far more often than not, developers still approach code reviews with the mindset of hunting for problems. As a result the most positive review a developer can hope for is an absence of comments pointing out any major problems with their code, and only a few quibbles on minor points of style or practice — effectively praising with faint damnation.

It doesn’t have to be this way! Here are some ideas you can communicate to your senior developers to get them out of this trap and start getting real value out of code reviews:

• Since they aren’t yet familiar with software design concepts, junior (and intermediate) developers can sometimes luck into writing something the right way without realising it. Calling out correct usage of design patterns and adherence to software design principles in the code review (and explicitly naming the principle or pattern!) can be a huge boost for that developer’s learning.

• This is also a great way to reinforce concepts that you are currently coaching the developer on. Comment on instances where you see them applying those learnings correctly, so that they have concrete examples to help them better understand the technique and recognise the progress that they are making. As a bonus, the event will be cemented in their mind, so you can bring it up in your next one-to-one with them to build a bridge to the next concept you want them to learn.

• Because they don’t (yet) have years of experience doing things a particular way, junior developers are often ridiculously good at discovering libraries, features, and techniques that their more senior teammates didn’t know about. Seeing a simple, “I didn’t know we could do that! Great find!” in their code review comments is highly motivating for a junior developer (or of any skill level, really) and it will help bolster their confidence and independence.

• It makes junior developers less intimidated to review (and learn from!) their teammates’ code. Junior developers struggle continually with imposter syndrome, and this makes them very hesitant to review code written by other developers…especially when they think that the job of the reviewer is to identify problems with the code! But when your junior developers see their teammates praising good practices and calling out learnings in code review, it shows them that their perspectives are also valuable, and they’ll be more encouraged to participate.

• Praising well-designed code helps solve the “tone problem” of code reviews. An overwhelming majority of code review is conducted asynchronously, usually by leaving typed comments on a pull request, and we all know how easy it is to read a negative tone into written messages, intended or not. By encouraging a practice of calling out the good stuff during code review, it cultivates a more positive mindset for both the code author and the reviewer, leading to less conflict and more productive discussions.

Thanks to advances in the field of devops, automation has created the space for your developers to engage in more thoughtful and positive discussions during code review.

Don’t fall into the trap of praising with faint damnation. Praise with genuine praise, and your code reviews will become catalysts for multiplying your team members’ learning and productivity.

Worse still, I found that it was impossible for me to improve on my own. Every gear change was such a frantic scramble to pull and push every lever I could find (and hope that I did it in the right order), that I could barely keep track of my movements, let alone inspect and improve my technique!

My instructor – with the patience of a thousand saints – helped me overcome this problem by drilling a mantra into my head: Slow is smooth, and smooth is fast. By making slower, more deliberate movements with the controls, I was able to feel the bike respond, which then allowed me to adapt my technique and execute gear changes smoothly. And even though at first I had to go painfully slowly in order to get it right, I got faster and faster with practice…until one day I was shifting gears even faster than my original frantic scramble, and with far fewer complaints from the transmission.

The same principle applies to writing software, especially when you’re first starting out.

Junior developers feel tremendous pressure to solve problems quickly. They have heaps of imposter syndrome to overcome, they are worried about being a burden on their teammates, plus there’s a natural pressure that everyone feels to “prove themselves” when they start a new role.

As a result, junior developers often get fixated on trying to get the desired result (i.e., the correct sequence of characters typed into the editor) as quickly as possible, and they avoid any activity that they perceive would slow them down (i.e., debugging).

I’ve seen it time and time again: The developer writes some code and tests it out, and they see that it doesn’t get the result they expected — but instead of stopping to figure out why it didn’t work, they instead dive straight back into their code to try something else. Unfortunately that something else doesn’t work either, and round and round they go. It doesn’t take long before the developer is completely out of ideas, and now they’re well and truly stalled.

Fortunately, it’s very easy to coach junior developers out of this. The key is to teach them how to make slower, more deliberate changes to the code, observing how the programme responds as a result, and adapting their approach in order to find the solution in fewer iterations:

• Teach them where to set the breakpoints in their process. Pair program with them, and when you see them neglecting to analyse the results before diving back into the code, gently interrupt them and point them in the right direction. It shouldn’t take long before they pick up the habit themselves.

• Get them to internalise the Two Questions™ when there’s an error message. When the code generates an error, ask the developer the two key questions:

  • “What does it say is the problem?” — get them in the habit of reading and understanding the error message…and in particular, not ignoring the complicated-looking parts (I’m looking at you, TypeScript).

  • “Where does it say the problem is happening?” — get them in the habit of analysing the stack trace.

  It should only take a few iterations before the developer starts hearing the sound of you asking these questions in their head every time they see an error message. And also in their nightmares, but I’m told that goes away with time. Usually.

• Ask leading questions instead of giving answers. Pair programming often feels slower than working individually because many of its outcomes (cross-training, code quality, upskilling) are invisible and come at the cost of raw coding speed. When the junior developer gets stuck or overlooks something, you will be tempted to tell them what to do to get things back on track quickly — but this will only make them more dependent on you. Instead, challenge yourself to come up with leading questions that will foster their curiosity and help them to learn the way to the right solution themselves.

• Reinforce takeaways at the end of the session. Before you close out a pair programming session with a junior developer, take a moment to reinforce the learnings you want them to take away from the session. In particular, be sure to call out any progress that you’ve observed, not just suggestions for improvement!

This process is going to feel uncomfortably slow at first, and especially during the first few pair programming sessions you might feel like you’re not making much progress in terms of the actual coding. That’s OK — the primary outcome you want here is for the junior developer to develop a more systematic approach to analysing and solving their own problems. Once they have that down, they’ll get faster and faster with practice.

Slow is smooth, and smooth is fast.

“At regular intervals, the team reflects on how to become more effective.” Sound familiar? This is one of the 12 principles from the Agile manifesto, and for most teams, this principle manifests as a regular retrospective meeting of some kind.

Except… I lied to you.

The principle actually states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.” But, for many teams – especially when they’re new to running retrospectives – they tend to forget about that second part.

Where teams go wrong

Your team sits down for their regular retrospective session, and engagement is ridiculously high. Everyone shows up with plenty to talk about. Your teammates celebrate their wins, appreciate one another, vent about things that didn’t go according to plan, and they may even propose a few ways they could do things better in the future.

And then the meeting ends, everyone goes back to work, and nothing really changes. There may be a few half-hearted attempts to implement some of the ideas that were discussed, and occasionally someone on your team captures an action item by accident. But by and large, team members walk away from each retrospective with maybe a bit of closure but mostly the feeling that they just wasted another hour on yet another pointless meeting.

How to fix it

It may sound counter-intuitive, but retrospectives are not fundamentally about the past — they’re about the future. During retrospectives we discuss what happened in the past as a means to an end, not an end in itself. Talking about the past ensures shared understanding of the problems we want to solve, and it provides context for the solutions we want to try.

If your team struggles to get actionable outcomes from retrospectives, here are some things you can work on with them:

• Dedicate space on the whiteboard to record action items, and nominate a facilitator to own that space and make sure it gets filled in. This makes the goal of the meeting highly visible to all participants, and it formalises accountability for making sure the discussion progresses towards that goal. The facilitator is also empowered to participate in discussions, so long as they prioritise their duty to record the outcomes of those discussions.

• Once your team members have started discussing a topic and everyone has a good understanding of where things are at, start guiding the discussion towards designing a plan of action. There will be some topics that your team members will have very strong feelings about that they want to express, and that’s great! By all means, let people spend a few minutes getting things off their chests… and then they need to start channelling that energy towards a productive outcome. If a discussion starts going in circles or seems to be devolving into a venting session, start prompting the participants to suggest ways the team can improve the situation.

• Carpark topics that aren’t yielding constructive discussion. There are some topics that are not appropriate for retrospectives. These may be problems that your team members aren’t ready to discuss potential solutions for yet, or that only affect a small minority of your team, or that originate from outside the team. If the facilitator is struggling to direct a conversation towards devising a plan of action, ask to carpark the issue and move on. Also, be sure to flag these items for later follow-up, as you may want to incorporate them into one-to-ones with your team members, discuss them with other team leads, etc.

• Treat process improvement tasks just like regular work tasks — track them on the board, bring them up during standups, reserve bandwidth for them during sprints, etc. That may be a contentious recommendation, but in my experience it’s the only way to reliably ensure that teams actually trial new ways of working. I’ve seen way too many teams put in all of that work to run productive retrospectives and capture action items… and then toss those action items into a process improvement backlog, where they are never seen again. Keep these tasks highly visible, and keep your team accountable for following through!

Your team should now be getting regular actionable outcomes from its retrospectives, which will also boost engagement and improve cohesion within your team. This is a great start, and there are many ways you can gain more value from this practice. I’ll be revisiting this topic from time to time — keep an eye out.