Continuous Reteaming and Self-Selection

Continuous reteaming and self-selection

13 minute read

In the book Drive, Dan Pink proposes that the 3 sources of intrinsic motivation are autonomy, mastery and purpose. In my experience, our system of work is rarely aligned with that. More often than not:

  • You are assigned to a project by your manager,
  • You follow a prescribed methodology like Scrum or Kanban (or have none at all and no forum to reflect),
  • You have a long list of requirements that sound quite disconnected from any tangible business impact (possibly written by a PO/PM, sometimes they may even let you talk to the customer ;-)).

This is not ideal. Though life could be worse, after all, you could be a SharePoint developer for instance! :-)

So how do we make it better? The community developed several methods over the years like the Spotify model. There is not a one size fits all approach. Ironically, Spotify agile coaches do recommend against using their model as is. It was just a snapshot in time of their practices. They suggest instead that teams around the world should start their learning journey to find a model that works in their context.

That’s what we did and we ended in a very different place… a place where engineers can self-select and decide what to work on, a place where team composition evolves every quarter. And since it’s easier to communicate a concept when it has a name, I decided to call our way of working Continuous Reteaming (The “G-Research model” doesn’t sound that sexy if you ask me, and it would be a lie anyway since we’ve not crossed the chasm yet, only ~50 of us work that way, with various levels of understanding). It was massively inspired by Dan North.

Since I thought this could interest some people, I was recently presenting Continuous Reteaming at, a conference for experienced agilists / agile coaches. I received a lot of questions. Some attendees told me afterwards that it was inspiring. I also had the distinct feeling that very few of them, if anyone, had directly experienced such a high level of self-selection and self-organisation. I’m pretty sure I would have been a happier developer myself if I had worked that way. This is my attempt to broadcast those ideas, fasten your seat belt.

Continuous Reteaming and Self-Selection — the origin

It’s the beginning of 2018, by all apparent measures my team of ~15 engineers works very well. We deliver value to our stakeholders, our lead time is low, we lead the technology adoption in the company, people are happy. And still, a few questions keep me awake at night:

  • Why are people not taking more ownership?
  • How do I scale myself and the team?
  • How do I react to changing business demands?

Our structure is project-based at this time. We run a few projects in parallel with mostly a fixed scope. Since quality is also mostly not negotiable, resourcing/time are the variables (see the project management triangle).

Managing the lifecycle of these project teams is pretty hard. I’m the one assigning people to teams, meaning I need to be aware of people skills, desires or ways of being (you probably want some diversity in the way people think, right?). Those evolve constantly, but I don’t necessarily get a memo. I also need to transition people from one team to another, but the end of projects rarely align, so we are spending 50% of our time in some sort of transition. I tend to find out too late, by moving someone from A to B, that they were essential in keeping the balance that made things tick in team A. Ouch.

I also still need to provide some form of planning for the quarter. Let’s be honest, this is pure guesswork.

While I’m doing an OK job at it, it’s stressful and keeps me quite busy. There is too much complexity, and I can’t get it 100% right. People blame me if they end up in a project they think is less appealing. They feel like pawns on a chessboard, rightly so.

I would like to say that I had a eureka moment, but the truth is a lot more boring. I merely get the green light from my management to engage Dan North for a few days of consulting to be spent over the course of the following 12 months. Dan is one of those people that can be annoying: you struggle with something for some time, and he asks you a straightforward question that rocks your world. In this case, it was something along the lines of:

“Julien, if you struggle to come up with a plan and people are not as engaged as you would like, why don’t you ask them to come up with the plan themselves instead?”

Hmmm… What?… (Thinking…) F**ck me! I’ve been doing it all wrong.

“Thanks Dan, this is brilliant but I hate you right this second! :p”

But there is hope for my team… I’m not afraid of change. If there is something that we learnt to do quite well over the years, it’s experimenting and innovating. This one is a massive leap of faith, particularly for me. It’s time to lead by example, time to make it happen.

Continuous reteaming and self-selection: the overview

The following is an overview and doesn’t go in depth. I’m trying to give you a feel for the overall system of work, not a detailed recipe. Each topic will be explored, hopefully, in follow up posts. Feel free to +1, comment, share, clap or cheers to motivate me to write those sooner than later :-).

The idea behind continuous reteaming is a simple one: on a regular cadence, quarterly for us, engineers cluster the work and assign themselves to a team that is going to deliver that cluster of work. As much as possible, we aim to have teams that have end-to-end ownership / no dependencies. Engineering managers have little power in this process. They just decide what the constraints for forming the teams are. That’s it. It’s quite uncomfortable at first for them… At least it was for me. So how do you make sure you don’t end up with an absolutely crazy plan?


Central to continuous reteaming is the idea of having a planning day with the whole team. It is massively inspired by “planning as a social event” at lego.

In summary, the following things will happen:

  • Teams will celebrate their achievements from last quarter and start the day energised
  • The pre-selected demand side will pitch the work it wants to be done and participate in a Q&A session.
  • Engineers will cluster the work, assign themselves and answer a fixed set of questions (Who are we? Who are our stakeholders? What is our mission? What are our OKRs? …). They will iterate until all constraints are met. This is where the magic happens.
  • The plan will be tested and broadcasted to the attendees
  • People will build relationships by having breakfast, lunch or drinks together.

I will provide more details on each part in a future post. The planning day does require two important things though: a list of projects/business impacts and a list of constraints.

The list of projects/business impacts should mainly be managed by your stakeholders. Out of the 200 things you could be doing, you need to know what is the subset that you are going to focus on for the next few months (presenting all the demand would be impractical, there is too much of it). It’s the business impact that should be achieved. Not a to-do list, not a long spec, the business impact. It should be straightforward to summarise on a few slides and pitch it. When the work starts, the team will self-organise, find out all the details and co-create a more detailed plan with the stakeholders. The hard part is to come up with a list that is not too big. Despite knowing it, we tend to plan significantly more than we can deliver in the quarter. We have not mastered this skill yet. However, that’s not a big problem as long as the stakeholders’ expectations are managed properly. Worst case scenario, the extra demand will feed into the following quarter.

The list of constraints is a different beast. As an engineering manager, this is the primary tool you have to avoid chaos and make sure the result of the planning day is acceptable. Better look at some examples, these are ours:

  1. All work is either picked by a team or de-prioritised by the stakeholders
  2. Team size between 3 and 6 people
  3. If a team is a continuation of last quarter, at least one new person must join, and one team member must leave

Let’s dig into those:

  1. is about making sure that people do all the work. Not just the stuff they like doing. You could make it a market place instead and drop projects that no one wants to work on, but we are certainly not ready for that.
  2. is about making sure that you actually have a team. With less than 3, if you have people on holiday or on support, you quickly end up with just one person working in the team. More than 6 and internal communication starts to be a problem (the number of communication paths in a group scales exponentially)
  3. is about enforcing some level of cross-pollination, fight a low bus factor, and making sure the most exciting projects have regular open slots for newcomers.

Those are just examples, of course. You can pick your own. In our case, they are sufficient to ensure a successful plan for the quarter. But please, keep their number small and trust your people :-)

Once you have both constraints and a prioritised portfolio, you have most of what you need to have a successful planning day. Everything else is logistics. Your people will self-select, and self organise. At the end of each iteration they will have to answer the following questions:

  • Are the constraints met?
  • Is there too much work / not enough work somewhere?
  • Do our stakeholders have any significant concerns that need addressing (ex: my work is exclusively UI/UX, and the team is solely hardcore Scala developers that never touched Angular or React)

If it all looks good, congrats, you have your plan. Time to call it a day, time to celebrate, time for drinks, cakes or whatever you like! If not, start a new iteration and make it shorter than the previous one to instil a sense of urgency.

Is the job done then? Not yet. Before jumping directly on delivering whatever business impact you are targeting, we need to nominate or elect a delivery lead and finalise the OKRs first.

The delivery lead is the only formal role that we have in a team, and it’s a critical one. While the team will self-organise for the next few months, we need to make sure that someone will hold the compass and make sure the team is working on the right things, e.g. the OKRs. In my experience, engineers are quick to go in a tangent without a constant reminder of their goals.

So the delivery lead role is to engage with stakeholders and engineering managers to agree, week after week, that we are still working on the most important things. They prioritise the KRs and ensure work in progress stays low. However, they are not a tech lead; they don’t have any particular power about the “How”. They are just responsible for the “What”, in collaboration with other people.

Delivery leads are responsible for the OKRs which are the primary way we are going to track progress. OKRs stands for Objectives and Key Results. They have been popularised by John Doerr who is known for having introduced them at Google. He wrote a great book about it that I highly recommend: Measure what matters.

It took me years to really understand OKRs. It’s all in the nuance… What follows doesn’t do them justice, stay tuned for more.

OKRs are the what you want to be achieved. They don’t say much about the how. They are aspirational. They are moonshots. They are not commitments! I repeat, they are NOT COMMITMENTS! The simple idea behind that is that even if you miss the moon, you will probably still have a beautiful view of the landscape.

The objective is the overall idea; for instance, this could be my personal objective: “Get Continuous reteaming known to the agile and tech community”. That’s a bit vague, so you need key results to tell you whether you are getting closer to that or not. So it becomes :

Get Continuous reteaming known to the agile and tech community

Key Results:

  • Talk at 5 conferences
  • Publish 1 blog post that has 50 likes
  • Be invited to talk at 1 podcast

OKRs are essentials in our system of work. They drive the teams daily and lead to fascinating conversations. Where? Mainly in the weekly status meeting.

The weekly status meeting achieves several objectives. It is a fast-paced meeting with the delivery leads, our PM, my boss and myself. I split it into two parts. Part 1 is the OKR review. Each delivery lead goes through his OKRs and updates the group on progress (ideally reflected in the KR scores, but not always) and confidence level for each KR that we will reach it by the end of the quarter. They also share what their priority of the week is or if any KR has to be dropped or changed. Confidence levels are amazing to detect and discuss discrepancies. Here is an example conversation:

  • Delivery lead: “KR is on track for completion, we plan to release X later this week which is all that is left to do.”
  • Me: “Great! What’s the confidence level that you are going to be done by the end of the quarter then?”
  • Delivery lead: “70%”
  • Me: “WAT?”
  • Delivery lead: “Ah yes… we depend on this other team, and we’re not sure of their timeline. Plus bob tells me that half their team is on holiday for the next two weeks.”

There are many other patterns. This is just one example that hopefully show you the value they bring.

During part 1, people have the opportunity to write down on a post-it any follow up questions that we will discuss in the second part of the meeting. More often than not those are either technical topic or things that tend to not fall clearly into one team or another. We just take one after another until done.

Those days, the whole meeting lasts ~45mins and cover the work of 5 teams. More importantly, the delivery leads do find it useful, this is not just reporting upwards.

There are a few other ceremonies that are part of our system of work like stand-ups (standard stand up, scrum of scrum, …) and showcases (internal or with stakeholders). But those are very typical, and since this article is already long, that will be a topic for another day.

This concludes the overview of our system of work. There is a lot more to cover, but hopefully, it gives you a feel for it. Writing this was hard work, I hadn’t done anything like this in years. So I have a favour to ask you. If this was interesting and you want to encourage me to go in-depth and write the next N articles, please let me know by commenting, resharing, liking, clapping, tweeting or whatever else work. After all, I’m focussing on impact. There is no point in publishing an article that no one cares about; I wouldn’t reach my key result :-)

Many thanks to Erik Uzureau for reviewing the post before publishing!

💗Did you like this post? Please let me know by clicking 👍 below, or leave a 💬!

comments powered by Disqus