Reality hits (part 2)

One good, if fairly glib, way of summarising the purpose of a manager is that he or she is there to prevent the next crisis. This involves all the ingenuity and wisdom that human experience can bestow. Management is anticipation, organisation, and diplomacy; everything else follows.

When a crisis does occur, though, overcoming it is surprisingly easy (assuming that it’s possible at all). There’s none of the effort of anticipation, because the next big problem is already happening around you. Everything you need to know is available, and the number of exits is strictly limited. As if that weren’t enough, most of the circuitry of the human brain is wired for reactive thought: people are at their resourceful, energetic best in times of difficulty.

So, most fools can govern in a crisis (unless it’s a political crisis); the true hallmark of skill is preventing one from happening in the first place.

It’s now two or three weeks since the events of the last article unfolded, placing me squarely in the ‘most fools’ category. To recap, we were left with about three working days before a major tour of the US, gazing at a supremely broken keyboard and facing a very irritated CEO. What we needed to do was obvious:

  • Stop adding features and refactoring, except to fix bugs.
  • Tackle problems in the order of greatest-impact-first rather than easiest-first.
  • Decide every day which bugs we were going to fix, circulate this list, and include the CEO in the circulation.
  • Honestly demonstrate steady improvement to restore the CEO’s confidence in the team.
  • Keep testing our work by buttonholing an independent product specialist every evening, to get a user’s perspective and to reveal new bugs.

And, of course,

  • To work really crazy hours until we’d won.

If you’re part of a software team and you haven’t been chained to a radiator for the last two decades, you’ll recognise a fascinating convergence. That list, without the addendum, can be translated into software-speak as:

  • Prioritising bugs over features.
  • Managing the expectations of important people outside the team;
  • Holding daily stand-up meetings to review progress and triage new cases;
  • Employing regular, independent, integrated testing.

These are cornerstones of software best practice and, more importantly, of Agile project management. So it seems that Agile fits our problem!

Agile almost certainly had its genesis in the reaction to a crisis such as ours, but it goes much further. The textbooks I have read on the subject recommend just foisting a flavour of Agile onto your team in one huge, indigestible thrust. I hate doing this to any fellow human being, so I am happy to discover that it is possible to creep towards new working practices effectively, little by little, minimising disruption while sharing complicity and control. When done properly, Agile should be liberating and democratic, and there’s no reason why the transition itself should resemble an abduction.

Naturally, it helps to have a crisis, and our predicament provided the necessary catalyst for change. The great surprise to me, as it had been at Focusrite, was how hungry everybody is for more formality, and for better delineation of working rules.

The founding fathers of Agile must have invented the art in a piecemeal way too, without access to flashy collaborative software, burndown charts, or the lexicon of trademarked, capitalised, quasi-sporting macho jargon that Agile practitioners tend to love. This language in particular is at once distateful and alien to the anchoritic, genteel tongue of the British nerd. While our biggest competitors may talk in terms of sprints, scrums, after-parties and touchdowns, it’s an oft-demonstrated fallacy that everybody must imitate a winner exactly or die. Google, Apple, and Oracle look very different, and they didn’t get there overnight. Better to evolve, to question, to cut one’s own clothes, and to pass each milestone at a sustainable pace.

The beginning was messy, as it had to be: the day’s top three bugs (along with the next three, in case we had a good day) were scrawled on a whiteboard and marked with asterisks, and crossed out with a flourish whenever a small victory was scored. Reports and updates were circulated two or three times a day via emails and ephemeral, free-form documents. Our testing was fairly ad-hoc, usually starting some minutes late and skipping from feature to feature with everybody talking at once, but it actually did the job and we ended up with a really decent, demonstrable product that supplanted our old prototype in a matter of days, and a happy boss who trusted us again. I characteristically resist enthusiasm, but a few minutes of playing a Seaboard now makes an electronic piano feel primitive.

The last few weeks have left a lingering taste, and some time to tidy up and consolidate our new system. It’s no shame to admit that a talented software team has occasional organisational difficulties. Everybody does; it’s a fact of life. Mistakes make great lessons, though. Biographies that chronicle noble failures are far more informative and more honest, if lamentably rarer, than those that focus only on success. Creative teams are always caught between between having enough formality to collaborate effectively on really difficult tasks, and respecting those sparks of individual brilliance that will make a product shine. The equilibrium between the two must adapt continually — often painfully — to fit the evolving team, but that’s what Agile is supposedly all about.

Our jobs are constantly in flux. Focusrite, six months after I left, has put in so many new practices that, were I to return, I wouldn’t know where to put myself. And yet, Agile is a peculiar beast to shoehorn into a hardware company, as it doesn’t fit well with the process of making physical objects.

The next article will probably be about how software-centric Agile collides with hardware-centric ROLI. Particularly, we’ve been thinking about how we can make the necessary heaps of planning and due diligence work in our favour, by softening the boundary between our work and its documentation.

Actually, that’s not an article. It’s a career.

Reality hits (part 1)

A year ago, when asked to write a few words for graduates starting their careers, I ventured the following:

Often, things are going best when it feels most like you’re about to be sacked.

One aspect of writing is that your own bons mots will occasionally haunt you. At Focusrite, I never felt I needed to save my skin by working 60-hour weeks (although sometimes I did) or weekends (which I never did). At ROLI, in common with the other technology startup I once joined, it’s quite a frequent occurrence. Not part of the culture, but a necessity nevertheless.

Start-ups do more with less: embracing greater technical challenges with less money, fewer staff, and very limited previous experience. Everbody carries the balance of the company’s success or failure.

Those involved in any business face challenges of an individual and team nature that are competitive, all-consuming, and at once rewarding and livelihood-threatening. Although neither war nor sport, the nature of business is such that it may readily use military or athletic metaphors without appearing ridiculous. What helps is that business, unlike sport or conflict, is not a zero-sum game. We’re putting something new out there, and if we win, it won’t be at anybody else’s expense.

Seaboard GRAND
Seaboard GRAND

At the moment, ROLI doesn’t feel like a job. It’s more like a hobby with an element of danger. Everybody’s genuinely brilliant in a way that I’ve never experienced to this degree in any other company: motivated, pleasant, smart, and positive, and work feels like socialising. I risk making ROLI sound like a cult, or myself a victim of the sunk cost fallacy. It isn’t, and I’m not, but people continue to inflict upon themselves the pain of a start-up only because they want to.

A new technology company invariably reaches its first product through hard work, grand intentions, and a minimum of forward planning. This is what makes such companies inventive and agile with a small ‘a’: we’re carving our own domain. It’s us, rather than the market, that still determines what we should do next. There comes a time, however, when we have to face the realities of commerce, and let the market determine our future.

Such a time comes when your boss embarks on a prestigious tour of the US with a few production prototypes, performing on the keyboard with the help of a product specialist, and shaking hands with a host of frighteningly famous people (who I’m probably not allowed to disclose right now). A week before he flies out, he fires up the prototype on the understanding that we’re pretty much there, and …

Well, not exactly nothing happens, but something not very good. It makes a few desultory noises, and then crashes, taking the synthesiser with it. So he restarts it. And it crashes again. It’s too late to manage his expectations, or anybody else’s. A day later, the whole team is facing his displeasure, and something’s got to change.

A colleague of mine sent me an article about “Steve Jobs’s first demo of the iPhone”: I’ve been there before, and so have most tech companies. Apple’s been there over and over again, and we were there a week ago. If you haven’t watched Micro Men, do so. It’s brilliant, and pertinent to the feeling of being exactly ‘there’: in fact, Sinclair was terrible at this, and eventually made high-profile failures his trademark.

One week on, I have the freedom to sit at home on a Saturday night only because we turned it around, but the adventure has been, and continues to be, an interesting one. In the next post, I’ll talk about we did to overcome what architects refer to as the ‘Oh, shit‘ moment.

Smart engineers don’t make the same mistake twice. Next time stuff goes wrong, it’ll look different.

Five months later

In April last year, I bade farewell to Focusrite, a company I had been part of for more than six years. It’s not easy to leave anything after six years, which perhaps is one reason why engineers have a reputation for itchy feet. Six years of sixty-mile round trips; of pouring some of the best years of my youth into an enterprise that is part company, part community; of building stuff that made a detectable impact on the small world of audio product design. It was a lot of fun, and a wrench to walk away. Consumer audio is uniquely challenging and compelling, and to practise the art in a supportive, well-managed, profitable company is an undertaking that less fortunate engineers might dream of.

Focusrite continues to be a great company: the Sunday Times thinks so too. The best companies do many things for their employees, but one of the most important is to foster an energising environment: innovation is encouraged; people know what they need to do, and have the support to grow; mistakes are sometimes made but never repeated; generally the quality of goods increases over time, but the cost and pain of doing so does not.

I made the modest steps in these endeavours that my talent afforded. My boss, Dave Hodder, proved himself one of the finest managers I’ve ever worked with: he had a natural flair for motivating people. He improved the ways that we organised and communicated work. It took some persuasion and some very charismatic people to pull me from this environment into the riskier world of ROLI, a VC-funded hardware company with less collective experience of delivering a viable product. But now I am navigating these turbulent waters, just like many of my former colleagues in Focusrite’s younger days, to produce a musical instrument of rare beauty and audacious complexity.

I took considerable notes for my own benefit as I was weighing up my choices. Over the next few postings, I will share a some reflections on old and new jobs because I hope they have a general appeal. Of course, where matters of corporate loyalty are concerned, there’ll be no finger-pointing and no secrets betrayed. I’m here to teach if I can, and learn if you’ll let me.

It’s good to reach a wonderful stage of my career when I am occasionally asked for my opinion: quite the most dizzying, gratifying, and responsible place to be. And finally I write because, when I left Focusrite, I was given a piece of advice by more than one of my colleagues: ‘Keep writing!’

Thousands of words have been written in the meantime, of course, all for my new employer, and with mixed success. Most of my energy is channelled in the same way it has always been: to make my adoptive community a better place to be. Meanwhile, though, I’ll find a little time to reach a wider world. I’m hoping that there’ll be enough people like me who are thinking about the worlds of hardware, software, management, and company strategy, to give this site an audience.

I’m also hoping I won’t make too much mess in this delicate task, but if I do, at least I’ll entertain. Bear with me!