The Strength of the Wolf

Nathan Nicholson
7 min readNov 19, 2020

Not Quite Teams

I have had the opportunity to sit with many teams. In every case, the team was struggling to deliver effectively, whether they realized it or not. That’s why my team would be engaged. A strike force built to dive into the trenches with teams to help them address quality, consistency, and execution.

What I noticed, in almost every case, was that the “team” was, in actuality, simply a group of people that had been assigned to work on the same code base. This collection of individuals set about doing their best to deliver value. Sometimes they sub-divided into smaller groups by role, or work location, or some other reason, but they were never a cohesive unit. This was generally to disappointing effect for their customers.

Things I’ve heard from people in some of these groups.

“It’s not MY responsibility to write tests.”

“I had to figure it out on my own. So should they.”

“If you asked me to work on the same feature as someone else, I’d find somewhere else to work.”

“It needs MY approval. Otherwise, something will break.”

“Why should I have to be on-call? I’m an engineer. That’s support’s problem.”

These individuals act like lone wolves.

Lone Wolves vs. The Pack

In nature, lone wolves do not tend to last long. They subsist on small game until they perish or somehow find a place in a pack. A lone wolf will only go after big game in an act of pure desperation. Because it’s dangerous! That moose you so desperately want to eat is probably going to stomp you into the ground if you go after it by yourself. That’s why you have the pack.

Roshan Patel , Smithsonian’s National Zoo

The pack takes turns wearing out their prey, because tired prey is less dangerous prey. Flailing hooves and antlers can injure or maim, so the pack is careful to balance risk and reward when it comes to dinner. They switch out with fresher pack members who swap into support positions. Roles are fluid on the hunt, even if some wolves are better at certain things than others. Everyone has to pull their weight. The alpha may select the target, but the group moves as one to bring it down. If the pack is successful, they feast as a group on their hard-won victory.

Even with the pack, most hunts don’t end in success. A lot of nights are hungry ones. A successful pack learns from both failure and success. They realize the terrain, weather, and time of day that they are most successful and adjust their hunting tactics accordingly. The next day, the wolves will start their next hunt. The cycle continues.

How Does This Translate?

There are many lessons that can be gleaned from these terrifyingly adept predators.

Understand the goal and move the team closer to it

Do you know what the team’s goal is? I’m not talking about shipping bits to computers, but “what value or competitive advantage does our software give our company”. If you can’t answer that question, you need to ask some tough questions and make sure your team is working on the most valuable thing they can.

Image by Anja from Pixabay

Continuously strive to move towards that goal and occasionally reassess it to make sure it still makes sense in the context of your business. Be relentless in your pursuit of true as opposed to perceived value for the customer/consumer.

Moving the team closer to the goal may require you to become uncomfortable, learn new things, or take on/help with work you are not a specialist in if that is the most valuable thing the team can deliver. Good! You are making the team stronger. Relish your broadened skill set and the resiliency you are building for your team and yourself.

Without focusing on the goal, we risk wandering aimlessly.

  • Shared goals and focus brings better execution. Divided, we fall.
  • Learn how to measure. It doesn’t matter if you have a goal if you have no way of knowing where you are with respect to it.
  • Be honest about where you are with respect to your goal.
  • Does this new feature/action/plan bring us closer to or further from our goal?

E Pluribus Unum (Out of Many, One)

Working with people can be hard. Those pesky opinions of others can get in the way of our own, perfect, plans. In reality, we each have unique strengths and weaknesses. Our software will inevitably reflect that fact. When we work on our own, the weaknesses and strengths will be equally represented across the codebase. However, when we work closely with our team our strengths will coalesce and our weaknesses will be reduced. This is one of the reasons that pair and mob programming are such a powerful tools to have in the toolbox.

What I’m not saying that everyone needs to know everything. We benefit as teams from having people that have deep knowledge of particular skill sets. These team members can act independently, distributing the significant cognitive load required to deliver and support modern software. These are the Wolves of the Pack, and every single one has an important role and set of skills needed to move towards the goal.

Photo by Eva Blue on Unsplash

The problem comes when relying too much on specialization comes with risk that many do not want to acknowledge. That, without any knowledge depth shared by other team members, the team becomes fragile. One team member wins the lottery, and all of a sudden we have a huge problem on our hands because Jill was the only one who knew how to tune our services and they’re really getting hammered right now. Teams must be able to carry on when a team member is unavailable, even though it is unlikely be able to perform at the same level.

We work together to meet the goal. We won’t get there by ourselves.

  • Swarm valuable work until it is saturated with talent.
  • Help your teammates and ask for help.
  • Share often and with gusto.
  • Leverage your expertise by providing constructive feedback.
  • Seek to learn broadly. You never know when you’ll find random gems.

Talk About The Hunt

I’ve had the recent pleasure to read Dan John’s excellent collection of essays, Attempts. One of these essays, “Planning the Plan”, actually inspired me to write this article. In it, he summarizes the book The Gnoll’s Credo:

Plan the hunt.

Hunt.

Discuss the hunt.

And I’ll add one more point.

Repeat.

Doug Smith — National Park Service, Public domain, via Wikimedia Commons

I’ll focus on the last couple of points, because it’s the one that’s so often missed with teams that struggle. They don’t talk candidly (or at all) about how things are going. Retrospective or “Inspect and Adapt” sessions feel like useless exercises that never actually address the things actually holding the team back. So they are abandoned entirely or become vestigial meetings of an “agile transformation”.

See if you recognize some of these retro “smells” on your team and take note:

  • A million action items that show right back up at the next retro.
  • Some problems aren’t even acknowledged anymore because they just keep showing up. The team has accepted them as givens.
  • “What went well” is filled with normal work and not the results of experiments the team is running.
  • The team feels like the only way they can give feedback is anonymously.
  • Action items are unmeasurable platitudes like “Collaborate more.”
  • Retros are infrequent, poorly attended, or only a subset of the team is included.
  • No discussion of actionable metrics related to the team’s goal(s).

Apply these constraints and watch as your results improve in short order:

  • Retro happens every two weeks on the same day at the same time and include everyone responsible for planning, designing, building, verifying, shipping, and supporting the product. (If that’s over 12 people, we have organizational constraints that need to be addressed.)
  • Focus all improvements toward a single S.M.A.R.T. goal that attacks the greatest pain the team feels.
  • Change the goal if the situation changes, but don’t thrash around. Fix things.
  • Limit the number of experiments you are running. (max: 3)
  • Treat improvement items like any other work and track them in the same location as product work.
  • Share the results of your improvement experiments with others.

Conclusion

The fearsome tactics and cohesive teamwork of wolf packs have for time immemorial acted to terrify and inspire people across the world. Even today, in the context of modern software development, we can leverage learnings from nature in order to improve our outcomes and drive continuous improvement.

  • Understand what your team’s goal is and relentlessly move towards it.
  • Leverage pack tactics deliver more value and ensure a resilient team.
  • Reflect on the team’s collective experience to set better improvement goals and become a more effective unit.

And if you take nothing else from this article, reflect on these words and ask yourself if your own team embodies them.

“For the strength of the Pack is the Wolf, and the strength of the Wolf is the Pack.”
Rudyard Kipling, The Jungle Book

--

--

Nathan Nicholson

Senior Release Engineer and Value Stream Architect at Netlify