The Team is the Unit of Delivery…as a Service

One of the reasons I joined NotBinary — the transformation agency I am now working for — is because a big part of their model is this idea of supplying squads to clients to deliver specific outcomes. The clients could be any kind of organisation / business but of course public sector is a big player in the strategy (otherwise why the hell would they have hired me!).

I have opinions and ideas about how the squads as a service model could work. I’ve had them for a while — since I brought my first squad in to help with the ONS Alpha project and have been mulling them over for a couple of years without an opportunity to really dig into them.

Until now.

All of this is just my opinion and much of it is the kind of thought exercise that probably never gets beyond a blogpost (or two — there is a companion piece in the works.).

I absolutely subscribe to the idea of the ‘team is the unit of delivery’. Technology is easy compared to people. High performing teams are more than the sum of the individual members expertise. The relationships, behaviours, personalities, foibles and histories all have a say. Teams gel over time (some quicker than others) and need nurturing and occasional pruning to ensure the best results…but really successful teams don’t happen overnight.

This is a weakness in the current squads model — we (all) sell teams but they are ad-hoc, collections of individuals thrown together based on CVs and phone sifts. This brings talented individuals together but then you really have to cross your fingers and hope the dynamics work and they can at least partially deliver to their potential.

Then just when they really start to hit their strides the contract ends and they go their separate ways.

Now to use a totally inelegant movie reference — what if the team was more like ‘The Expendables’. A core team of ‘veterans’ (hopefully a little more diverse than Mr Stallone’s friends) that stayed together from assignment to assignment, occasionally supplemented by additional, known, people with special skills as needed but the squad arrived on day one with a strong culture, great communication, technical know how and ways of working so the early days were immediately 100% about learning about the client, the assignment and not each other.

Also what if all those ways of working and histories were available openly ahead of times so that the client knew exactly who they were getting, how they operated and what to expect. The other, aforementioned blogpost is on how this openness might work.

Basically — Have Alpha Will Travel.

I wonder what this would look like practically? I suspect to ensure the kind of flexibility you’d need a core of multihyphenates (UX-researcher, product-delivery manager, the fabled ‘full-stack’ developer or three..) which isn’t to everybodies taste and how would you cope with the fallow periods between assignments in a way that prevented the team breaking up? Some kind of retainer system? I like the idea of a team that works together even when not on assignment — on open source projects maybe — but I haven’t worked out how that would be sustainable I have to be honest.

What if the team had a ‘dispatcher’ — someone who handled all the admin — the apartments, the trains, the contracts, the money so the team just got to get on with the work with the rest taken care of — so not distractions and no worrying about where the next gig was coming from.

Could something like this work? Is it pie in the sky stuff? I really would like to try it but maybe I am just barking up the wrong tree. Did I just watch too much The A-Team as a child?

Anyway — we are on GCloud if anyone has a project where they thinking something like this might work (or anything else interesting really — give me a shout!).

%d bloggers like this: