Designing the mod(ern) squad


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

Chief Squad Officer

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. Their 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.

Another diagram to trigger some folks 😉

Network

The 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, Questors 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.

The Talent Manager

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

https://media.giphy.com/media/ALQ6OXrBDqBWw/giphy.gif

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 everytime 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 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.

Internet-era ways of working principles from public.digital


I’m on record as saying that the original design principles (latest version here) remain the most important thing (amongst many, many important things) that emerged from the formation of the Government Digital Service. They provided a blueprint for digital service teams across the public sector and beyond and articulated things that many of us already believed but were struggling to communicate more widely.

Many of that original GDS team now make up public.digital and they have published a new, updated take on those principles with an important piece of contextual guidance.

..break any of these rules sooner than do anything barbaric. It’s better to be pragmatic and make some progress, than wait for perfect circumstances that will never come, and not make any progress at all.

The new dozen principles are an evolution of those that came before them — and like the USDS version — show signs of lessons learned at the sharp end of trying to transform legacy organisations.

Personally I can see these finding themselves printed up and displayed on many a wall adjacent to agile teams and I’ll certainly be referring to the list in the future (alongside the capabilities outlined in the Accelerate book.)

There is much more context on the public.digital blogpost — I recommend having a read but here are the headlines →

1. Design for user needs, not organisational convenience

2. Test your riskiest assumptions with actual users

3. The unit of delivery is the empowered, multidisciplinary team

4. Do the hard work to make things simple

5. Staying secure means building for resilience

6. Recognise the duty of care you have to users, and to the data you hold about them

7. Start small and optimise for iteration. Iterate, increment and repeat

8. Make things open; it makes things better

9. Fund product teams, not projects

10. Display a bias towards small pieces of technology, loosely joined

11. Treat data as infrastructure

12. Digital is not just the online channel

The most ambitious crossover in history

When Warren Ellis accidentally spoke about my work life


At Thought Bubble a couple of weekends ago Warren Ellis gave a spectacular keynote — all about the future and history of comics — I loved it. It totally played into my own weirdly mixed feelings about my love for the art form.

There was this section of his talk though where I could of sworn he was talking about my day job. About how I feel about this whole digital transformation thing, the culture and network we built over the last decade and why I find things like One Team Gov and all the new Team #weeknotes folk so positive.

Anyway Warren just shared the relevant part of his talk so I thought I’d share it here and see if it makes sense for anybody else — just change ‘comics’ to your phrase du jour;

And, as more and more people realise that this artform is not in fact the exclusive preserve of fat old bald beardy white guys — hi — but is in fact a human commonwealth open to all — it will only get better still. New voices will be raised up, and the medium will change and grow and evolve. I don’t pay attention to what’s going in in comics at all and even I know that’s happening and will continue to happen. And it’s good. It’s making comics better.

I mean, for all that to really bed in properly, me and my generation will have to die. But I’m okay with that. Some of you probably only walked in here today because you thought I was already dead. As far as I’m concerned, it’s always been the time for ghosts.

Old people are sneaky. It’s how we got to be old in the first place. Never trust us.

From time to time, some of us will give up our seats and go hang out with the ghosts for a while. If you take our seats, then you know the deal — find new seats for new people to come and sit down with you. Keep growing. Keep moving forward.

I’m not quite a ghost yet but I definitely feel like it is time to make room and at least start finding more ways to share my ‘platform’ (as it were..) and to be honest I’m quite happy to take a seat with the ghosts for a while — I could do with a rest 🙂

Time to ‘Accelerate’ transformation

If you are anything like me you read a lot of ‘business’ books. For me these are usually at least somewhat related to doing work in the internet-era — often with titles including buzzwords like ‘lean’, ‘agile’, ‘transformation’, ‘sprints’ (or a creative combination of all of them!). Also if you are anything like me you do what James Herbert (boss of bosses at NotBinary) pointed out at a recent away day — read a third of the book and then decide you are an expert!

The book I recently read a third of (actually a little more) and that I am pushing at anyone who will listen, and which I have bought a real copy of just to easier lend out is this →

Written by some of the team behind both ‘The Phoenix Project’ and the annual ‘State of DevOps’ survey and report it really makes the argument about the importance of the technology aspects of transformation alongside the cultural ones that I stumbled around in my recent post about it not just being about people.

The book takes a notably academic tone — with a sizeable portion of the book just laying out the teams research methodology and process — and while this can at times make it a less than easy read I think it becomes a much more powerful artefact thanks to this decision.

It makes the conclusions much harder to dismiss when it is based on some data rather than just the opinions — no matter how expert — of the authors and I suspect it will mean that passages of this book will be wheeled out by anyone trying to convince the local ‘powers that be’ on the worth of investing in this kind of transformation for years to come.

There has no doubt it has had an immediate influence on my thinking. The last couple of months I’ve been sketching out some ideas about what a network of high performing teams might look like — given that is basically what I have joined NotBinary to try and achieve — and this book had the dual effect of (a) making me think I was on the right lines and (b) realising I needed to rethink everything as I wasn’t being ambitious enough.

The fact is I suspect there is very little new in the book for any existing high performing teams — especially those in and around the Government Digital Service world these last few years as much of it is the good practice as outlined in the Service Manual (and elsewhere) but it somehow feels more explicit in its recommendations and benefits from the weight of evidence provided by the survey.

I actually read the book (well some of the book) in a rather haphazard order. Starting with Appendix A which covers what they call the ‘Capabilities to Drive Improvement’ — these five categories are:

  • Continuous delivery
  • Architecture
  • Product and process
  • Lean management and monitoring
  • Cultural

As you might expect I found myself mainly drawn to the final three categories there — with each both reassuring me about some of my own beliefs about helping teams and organisations benefit from these new ways of working but also introducing me to new ideas (well to me) and approaches.

The Westrum model for organisational culture is seemingly well known and understood by others but was new to me and was an immediate lightbulb moment:

Pathological organisations are characterized by large amounts of fear and threat. People often hoard information or withhold it for political reasons, or distort it to make themselves look better.
Bureaucratic organisations protect departments. Those in the department want to maintain their “turf,” insist on their own rules, and generally do things by the book — their book.
Generative organisations focus on the mission. How do we accomplish our goal? Everything is subordinated to good performance, to doing what we are supposed to do.

Despite my retreat to my comfort zone even within my reading habits I have to say that it feels like this book really articulates the massive wins possible by embracing modern software development processes and particularly just being able to get to a point where you can deploy changes easily, regularly and safely which really opens up the possibilities of iterative improvements. This and the idea of ‘shifting left on security’ were lessons I had taken from my own experiences back at ONS so I was really pleased to see them stated so clearly here.

I think even as a relatively non technical product person I’d be nervous of working in any team where things like;

  • version control
  • automated deployments
  • continuous integration
  • automated tests
  • security involvement early and often (preferably as part of the team)

..were not at least the ambition if not the starting point on day one.

One of the things I am most proud of at ONS was moving from a situation where two deployments a year was the norm to an expectation of daily (or more) deployments. This felt like such a game changer and made a lot of the thinking around things like agile and user-centricity so much more real as we could genuinely iterate based on user research and our sprints had real skin in the game.

My professional goal is to take on roles where I need to convince those that need convincing that this approach is what is needed and then to provide the space and the culture for teams implementing it to succeed. This book will really help with that so thanks!

‘This thing of ours’ isn’t JUST about people..

Like many of us in ‘this thing of ours’ I am prone to making statements like — digital is all about people. In fact here is a picture of me standing in front of a massive screen saying something similar:


Now I stand by this but sometimes I worry I mean something different when I say this than some other folks and a couple of related comments I’ve seen recently have inspired me to dig into what I mean by this.

Paul Shelter recently had a little Twitter rant on this topic..

..and while I don’t entirely agree with the entire thread I believe there is a core truth there.

Then today James (the boss) posted the following (which led to a bit of a rewrite of this post!);

“Digital Transformation” — people say, “its about culture not tech.” True, of course, but understanding modern tech, associated practice and what sort of tech and related talent you need to attract are a vital part of that culture. As long as its that and not — “I can’t be bothered to learn about the tech that powers this stuff so I’ll make out its not really important” then that’s ok. There’s a difference.

Which I think it making a related point. That is in our efforts to change the narrative from ‘digital transformation’ being all about technology we have over-corrected.

Like Trump’s tweets I often find there is a Richard Pope post for every occasion — and once again here we are. Almost exactly two years ago he wrote about ‘It’s not about the technology — apart from when it is..

Technology does matter. Good digital / design / business / transformation / culture / strategy requires an understanding of the materials.

I’m a believer in ‘service design’ (if not always in the idea of Service Designers) and believe it is a genuine force for good in the world — especially in the ‘internet of public service’. I believe the elevation of ‘design’ in the public sector is a good thing and initiatives like Essex CC focusing on a ‘service design’ transformation to be a useful reframing…

…but I don’t think it negates the fact that an understanding of the opportunities offered by modern approaches to technology and broadly the Internet are the canvas upon which we are designing.

Applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.

I feel like I refer back to Tom’s definition of digital every week but it is the gift that keeps on giving. When I talk about ‘digital being about people’ — I mean two things.

  1. People who already totally grasp this definition
  2. People we have to convince.

Applying the culture, practices, processes & technologies of the Internet-era to respond to people’s raised expectations.

We absolutely do need great designers but we also need people who really understand the technologies now (and next) who can work out the best ways to implement that design thinking. Much as I hate the ‘lipstick on a pig’ accusations — (any) design without equal efforts to rethink technology leaves itself wide open.

We need technologists who understand privacy and issues around data sharing.

Who understand security without destroying the user experience.

Who can spot the next big thing vs the Emperors new clothes.

Now I am neither a technologist nor a designer. So I think I can be Switzerland here and say that it is the magic of the team — of disciplines working together — that makes this ‘thing of ours’ work….It is about people. It is about design. It is also still about technology.

Also — lets not pretend otherwise — it is also still about savings. To one extent or another most digital transformation programmes in the public sector are built upon Business Cases promising savings. This is probably a shared psychosis given how rarely the savings are actually realised but if they do happen the savings come from opportunities to simplify infrastructure etc more often than not….and this needs people who really understand it to do it well, safely and securely.

So anyway isn’t JUST about people..