Ephemeral teams
I remember joining a young web company in London about ten years ago. The CTO (a great leader) liked to tell me that “other companies come to us to find out how to do Agile”. The company was full of very talented young developers, some of whom specialised in testing or UI or architecture, but all of whom worked great for the Agile concept of a cross-functional, autonomous development team. It worked, although estimation was never brilliant, and there was never a sense that we owned any part of the product.
Then, a few years back, I remember discovering Spotify’s squads, tribes, chapters and guilds concept and being pleasantly surprised that someone was innovating in the team formation space. The nice thing about Spotify’s model is that they take team autonomy seriously and that each team is encouraged to pursue MVP-style business goals. I’ve only worked very briefly in that fashion, but I could immediately sense the ownership experienced by the squad. They were interested in the outcome, not just in sprinting their cards across the Kanban board…
I love the idea of a team having the freedom to own the delivery of what they are working on, and at times I advocate duplication of code, or even architecture to achieve this. When teams feel that they have ownership, it can be powerfully motivating.
On the other hand, I’ve seen quite a few systems descend into a disorganised mess due to a lack of coherent architectural design. Even well designed, coherent systems, designed in parallel, descend into chaos once the original team structure which produced them is dissolved.
Here I should probably wheel out Conway’s law to point out that it makes sense that a system starts to lose its internal coherence if the communication model of the team(s) creating it changes over time.
In working with Agile methodologies (such as Scrum), similar problems occur when trying to apply principles such as velocity to the process of Agile estimation. Often development teams exist to complete a particular project (perhaps 9 or 15 months). At the end of a project, it is normal for a team to change considerably — adding or losing members, or perhaps disbanding completely.
But what about all those velocity measurements we made!!! Those would be so useful for estimating the next project! Don’t disband the team! I just learned how long a 5 point story takes! (← sarcasm)
So teams are good (and often a lot of fun), but teams also introduce risk. There is a hidden cost of maintaining or breaking up a team which businesses underestimate.
Teams can bond together around a common goal, but sometimes our business goals aren’t discrete or long-lived enough to sustain a team’s ethos. Often particular people are needed in several different areas of responsibility at once. Often a company has many development teams, but only one flagship product. Shouldn’t there be just one team who can feel like they own everything?
Teams often use Kanban boards these days. I really like the simplicity of Kanban, but as a person who is passionate about growing systems I’d like to be able to apply Kanban across the entire graph of changes needed to achieve my next MVP (not just a team’s assignments). Finding a good subset of changes to fit a particular team’s availability or skillset can be very challenging.
So, recently, I’ve started to brainstorm some ways to stop having development “teams”. One idea is something I call an ephemeral team structure. I could have called it “micro-team architecture” but I was afraid of getting mugged.
Essentially the idea is to compose a team of three or four just-in-time to carry out a particular mutation of a particular deployable unit into production. The team isn’t expected to continue beyond their immediate task, although individuals might choose to work together again in the future.
Rather than managing engineers in “teams”, wouldn’t it be better to just have a pool of talented engineers, each with our own specialisms and areas of interest, who come together as needed in ephemeral teams in order to complete the next piece of work (architectural mutation) needed? This way we can leverage the best person for the job every time.
Such an ephemeral team structure requires there to be a hierarchy in order to function. I know, I know — unpopular opinion. Hierarchies are evil. Autonomous teams are good. I get it. Bear with me here…
When a system grows beyond the size that a team of three or four can meaningfully grok, it’s really helpful to have someone who can stand back and observe the work going on across several subsystems, or across a portfolio of micro-services. Such a person can think about any dependencies between services, and worry about the critical path for delivery.
In that sense, a hierarchy of understanding, or responsibility, is formed. So it’s more about perspective and role than about who-manages-who.
Having a pool of engineers that form into ephemeral teams allows us to de-risk early by targeting the best people at the scary stuff first. It also means that we can leverage design swarms, mobbing, pair programming and individual coding as it suits for the work assigned and the people doing it. We can time-box where there’s a risk of losing our way, or fast-track lean delivery if there isn’t. The ephemeral team doing the work can use whatever delivery system they like.
I like it! And ephemeral sounds so nice too…
