squad
/skwɒd/
noun
a small group of people having a particular task.
Background
I recently wrote about our new Squad Manager role(s) and wanted to just dig in a bit to how we see our squad model growing and evolving.
Like many companies and organisations we follow Spotify in referring to our agile delivery teams as ‘squads’. The basic premise of a ‘squad’ is a multi-functional team, of 10ish people, working in an agile manner with a specific focus.
Notbinary predominately supply software engineering squads with some additional capabilities (BAs, user research, architecture, data science, SREs and of course our Squad Managers) to deliver agreed outcomes over set period of time…give or take.
Sometimes this is Alpha →Beta → Live type stuff. Sometimes it is more feature factory style. We occasionally do Discovery work but to be honest we probably have a relatively narrow niche there and over time I suspect we’ll work more closely with partners to undertake more of that type work.
While our squads may vary in size and shape depending on the gig but they all have some common elements and ways of working and this post is me trying to articulate that. Some of this is how we are already operating, some of it is imminent, some of it is aspiration.
Nucleus
At the core of every Notbinary squad is a partnership. We rely on the double act between the Squad Manager and the Principal Engineer to lead the squad and set the tone. There is a wider Notbinary culture but each squad is unique and within a broad framework they set their ways of working and approach.
They are supported in a servant/leader style by the Engineering and Squad Directors who oversee a larger portfolio of squads and relationships with our partners plus also the Chief People Officer who oversees hiring — both permanent and independent contractors.
Each squad leadership partnership will also (eventually — we are still working this out) be assigned an ‘early career engineer’ to mentor and work with on projects. This will probably need a blogpost of its own but I’m keen we find a route into this type of work for people from different backgrounds (maybe via bootcamps, online courses, hackdays??) and give them a chance to work on real projects early but with suitable support.
Almost every squad will need a business analyst (usually on the feature factory side) or a user researcher (on the GDSesque style delivery lifecycle). I haven’t quite worked out whether this is an additional ‘nucleus’ role. I have warmed to the idea of ‘slash’ roles (BA/UR for instance) as I have worked with a couple of great ones recently — but I suspect they are still a bit Unicorn-y. From a personal point of view I have been lucky enough to lean on some really good user researchers over the years and they are often the difference between failure and success. I suspect I’d like to get to a point where we add some kind of research capability to the squads by default — just need to work out what that looks like.
To be clear those roles will always be in the squads one way or another — via our partners, our network or our contract hiring — the question is whether they become a permanent member of this settled core team.
Additionally I can see a need for a number of other specialist roles that are permanent staff that act more like floating specialists supporting the squads as needed. In particular I can see a need for ‘Site Reliability Engineers’ , ‘Data Scientists/Engineers’ and ‘Cyber Security’ specialists who can provide advice, support to squads and occasionally drop in for a sprint or two.
Something that I think will help stitch all this together is the idea of Concierge role — different than a PA — more like an old school travel agent or a dispatcher— who makes sure everyone is where they need to be, with whatever they need for a comfortable, productive stay. That is probably another blogpost but the more I mull the idea the more I like it.
Network
Now that is already a lot of words but given I previously said that squads are often around 10 people I have maybe only covered half the team.
The reality is the rest of the squad comes from ‘the Network’ (not the Green Day side project I just discovered on Google!). Many squads are cobbled together from independent contractors — often a few will have worked together before. The high performing squads often having a core of pre-existing relationships and chemistry from day one. It isn’t unusual though for them all to meet on day one. This can still work fine if they are a good mix with talented leadership but it is a risk.
I am all for minimising risk.
Notbinary is now part of TPX — a fast growing digital transformation group. Our partners already include Manifesto (who recently acquired Deeson), Greenshoot Labs, Questers and Bene Agere. The growth shows no sign of slowing any time soon. So our immediate Network already includes expertise in UX, front-end development, software engineering, AI, chatbots, digital strategy and performance analysis amongst many other things.
Now I’m not saying the intention is to have an internal group market loaning staff around willy nilly but there are opportunities to take advantage of the breadth of skills available now and that is a lot more nodes in the network than just us.
Broadening the network is vital — I want to empower our squad partnerships to form their own teams and I want them to work with people they know and trust whenever possible — but the reality is that isn’t going to always happen so the more people we are aware of who are a directly known quantity to people within the Group the better.
This is all going to take some kind of ‘Talent Management’ operation — Database/CRM of whole network of independent contractors who are known to or recommended to our Group with their skills, availability, day-rates and ‘riders’ (London only, max three days on site, never work next to an Indian burial ground…). Keeping on top of this feels both bloody hard and equally important as we scale. Not to mention continuing to build a culture and offering that appeals to these people.
s-minus-1
This is another stub of an idea I am currently thinking through which will likely result in another blogpost.
I can’t find the reference but the idea that every time you make any change to the make up of a team it is essentially a new team means that no matter how much effort you put in to have a stable core in your squad each time it lands it is a thing. To counter this I have been thinking about what I am calling s-minus-1 (basically Sprint Minus One — something before Sprint Zero) where you bring the team together for a few days, offsite, in a room and basically give them a bit of time to get their shit together, find their voice, agree all the admin and ways of working — away from the view of the client. So when they land on site they are ready to roll.
Well that turned out to be longer than I planned! Obviously had a bit on my mind.
