A talk at the University of Surrey

Every couple of years, the University of Surrey honours me by inviting me back to talk to students for an hour about what I do for a living. I’m made to feel so welcome that I barely know where to put myself, and I will be presenting my fourth such talk on Tuesday afternoon.

As I get older, and my career changes, my ability to connect where I am today to where I started slackens, as does any connection between the undergraduate course I was taught and what today’s students must learn. Many of this year’s undergraduates were born the same year that I first strolled onto campus.

Although it doesn’t feel like it, I’m conscious of the fact that I’m now of a different generation, and my talk plan is becoming more reflective and somewhat generalised.

In case they help, here are echoes from previous talks I’ve given, that I wrote for Focusrite’s blog.

Finally, because he’s the only acoustics lecturer I’ve ever heard of who was also a self-made billionaire, I feel obliged to post the late Dr. Amar Bose here. In the last six minutes (from 54:10), he sums up everything I would want to tell a University student about starting their career.

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 founders 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, frat-boy words that Agile practitioners seem to love. The weird portmanteau words like after-party and touchdown are alien to British nerds; use of sports metaphors like sprint and scrum spark memories of weekly abuse on playing fields. While those sweaty signifiers are everywhere, it’s an oft-demonstrated fallacy that everybody must imitate the winners 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”:http://www.slashgear.com/iphone-smoke-mirrors-as-apple-engineer-dishes-on-steve-jobs-big-reveal-04300300/. 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.