Feedback-feedback on Mobbing

Sami Lamti
Feb 9 · 5 min read

We’ve gotten some great feedback on our recent article on Mobbing! Thank you for that; please keep it coming!

The feedback boiled down to three topics (and two bonus ones!), which we will address in this follow-up:

  • Team performance
  • Individual performance
  • Project ownership
  • Optimizations
  • How we work

Let’s start with the Team Performance. The feedback boiled down to this: “How do you know that a mobbing team will perform better than a non-mobbing team?”

It is hard to compare two distinct teams from one another — especially if the teams are working on completely different things. So instead of trying, we tried to introspect how our own team performed before/after we started practice mobbing. What we have found, is that our team does not perform worse / are lacking in perceived velocity after we transitioned to mobbing. Or, put in other words, management and external parties are not lamenting the lack of features and fixes we output, but instead are working to keep up.

When bringing the question up in the mob, we started talking about how we are less concerned with performance as such and instead choose to focus on the knowledge sharing that naturally occurs. This means that a task is never stalled because a key member is busy or away for whatever reason. The work flows along anyway because a large part of the team is completely up to speed. There’s built-in redundancy in the process.

By mobbing extensively, we make great strides towards eliminating knowledge silos. Yes, we have engineers who are particularly good at certain products, but through mobbing, everyone can pull their weight.

I’ve tried to illustrate the Team > Individual below approach through a diagram that shows that, expertise comes in different flavours — you can be really good at e.g. “Machine learning”, but have very rudimentary knowledge of “React & Redux”. As a part of a mob, however, the shared knowledge covers both areas, enabling the mob to continually produce high quality software.

Individual vs. shared expertise


Individual performance

We achieve this by actively rotating the navigator and driver roles throughout the day and through a process whereby we give open and honest feedback. To put it simply, our team lead asks us individually how we are getting along, if we have any feedback for one another and is then able to act on that. Adding to this, we have a daily retrospective at the end of the day, where we focus on things that has gone well, and things we can do better the following day. We end this retrospective with some fun time, where we play games together, which helps us bond and delineate between work and our family lives.

If any of this sounds good (and we hope it does!), this is a good time to point out that we are currently hiring!



  • Because we work together, features and fixes gets merged into the main branch and delivered as soon as they are done, instead of having to mature on a board, waiting for someone else to review them.
  • Because we work on one thing at a time, we have to spend very little time trying to resolve merge conflicts.
  • Because we have our new starters as a part the mob as soon as possible, we get to identify problems that they experience first-hand, which lets us continually improve both our onboarding experience, lets us simplify concepts and make our products easier to use.
  • Because we work together, we always have someone to bounce ideas on, without having to spend a lot of time introducing them to the problem space.

How we work

Sometimes, individual contributors choose to work on their own (e.g. to prepare a presentation, to prepare/conduct an interview, …). In these cases, when they later rejoin the mob, they tell the mob what they’ve been up to and demonstrate their work to get feedback and to debrief. If it’s code that’s been written, the merging is done in the mob.


Ingeniously Simple

How Redgate build ingeniously simple products, from…