People > Process

In his post Why Software is Slow and Shitty, Robin wonders if the structure of a company - perhaps with an over-reliance on process and planning - can affect the quality of the software it produces:

My own time in a Silicon Valley startup has proved this much to be true; planning doesn’t make for better software. In fact today our design systems team doesn’t have sprints, we don’t have tickets or a daily stand-up… we independently solve problems at a blistering pace, and without an added layer of bullshit planning on top it’s become the greatest work I’ve contributed to in my career so far.

I’m currently helping design a service for the Department for Education, work which I consider to the be the most rewarding of my career too. But here’s the thing: we have plenty of process!

It’s probably best described as agile-ish. ‘Agile’ in that we observe all the usual ceremonies (sprint planning, stand-ups, retros etc.), ‘ish’ because needing to meet an aggressive series of external deadlines invariably means adopting a rigid timeline in which to deliver. So we also have a plan. The team was split into three groups, each focused on a stream of work that addresses the needs of various stakeholders. A fourth team works across these, with the intention that eventually these will recombine once different needs have been met.

Yet even with all this structure, I believe we are building a valuable, robust, accessible and inclusive service – albeit one built upon a foundation of government tooling and prevailing delivery-focused culture.

If I’ve learnt anything working in this industry, its that if you don’t hire good people – by which I mean not only talented in their own domain, but able to work and communicate with others – any process will soon become a crutch. But with good people around, you can pretty much get by with any process, no matter how poorly considered it might be. Indeed, processes will likely emerge from the team’s own needs and adapted as required.

This happened to be proven last year. In the final few months before launching our pilot, we were rapidly developing the product, concluding research and refining designs. We were also onboarding several new team members. For us designers, our number grew from 2 to 6, all in the space of a few weeks. Focused on delivery, we had no structure in place to help divide up tasks, or any process for feedback or critique. The strain soon became evident, but the calibre of the team meant people spoke up, and pragmatic short-term solutions were found. All that was needed was a dash of leadership and a pinch of professionalism. Now that we’ve moved into the next phase, we have the time and space to think about how we operate as this expanded group.

So while I don’t think having plans or structure has anything to do with software quality, I wholeheartedly agree with Robin’s conclusion:

all you have to do is hire smart people, trust them to do their best work, and then get the hell out of their way.

Any process needs to be a product of people, not the other way round.

With thanks to Robin for encouraging me to respond publicly.