Alan Sugar, in a recent episode of The Apprentice on BBC, said that in his experience, no Engineer had ever built a successful business. His outburst provoked an amused reaction from those who recognise the contribution Engineers have made and continue to make to the economy and society in general. But it got me thinking: are there some attributes of the way that Engineers are trained to think that make it less likely that they will succeed when it comes to building a successful business? As an Engineer trying to build a business, if there are common mistakes, I really want to be sure to avoid them!
Once upon a time, I worked for DEC (Digital Equipment Corporation), back when it was the second largest kid on the block, after IBM. Digital is a case study for anyone trying to understand what can happen when an Engineer builds, and then continues to run a company. When Ken Olsen, who passed away earlier this year, founded DEC he tried to create an environment in which Engineers were encouraged to “Do the right thing” one which felt like an MIT lab. That meant for a while there were few better places to work if you were in Computing; and its culture seemed quite different to that of IBM at the time. DEC’s European headquarters, DECPark was in Reading (now demolished). IBM were based down towards the south-coast. Basingstoke, which lays somewhere between the two, was a no-mans land. The aptly named ‘’Jekyll and Hyde” pub off the A33 which connects Reading to Basingstoke was a real halfway house. You could immediately spot which camp people came from: DEC engineers wearing t-shirts and jeans and the IBM guys were all in dark suits, white shirts and ties. There was even an urban legend prevalent at the time that they were not allowed to have facial hair. Perhaps this incentivised some DEC Engineers to grow quite magnificent beards.
This was a superficial difference, but there were real differences in the way that the businesses were run. As it was explained to me, Olsen believed in the technical superiority of his systems and partly influenced by that, and partly by his moral code, his salesman were not paid on commission. He seemed to share a technocratic belief, superficially attractive perhaps to scientists or engineers in positions of leadership, that a business was just a hard problem which to be successful needed clever people to think harder about in order to ‘solve it’. As a clever guy, he made sure he was very involved in the detail of the business: approving the design of the boxes (when I was there, they were all beige); instituting the, now surely abandoned by all right-thinking organizations, scheme of matrix-management (only a technocrat could have conceived such a complex system to try and manage people.) So, to cut a long story short (and you can read more in a number of books about Olsen or the story of DEC,) DEC ended up being acquired by Compaq who were in turn eventually acquired by HP. The Engineers at DEC did some truly amazing things: PDP-11; VMS; the OSF/1 64-bit *nix operating system; they worked with MIT on Project Athena; the Alpha 64-bit RISC chip. But in the end, perhaps all that technical superiority was not enough to run an enduring business. Was it because Olsen saw his company as a complex machine, a system which he could Engineer? In some respects I am a fan of Systems Thinking, but if we follow this train of thought too far we end up with Cybersyn, the absurd (though fascinating) attempts by Allende to create a socialist utopia and control the economy of Chile with the aid of the British Operational Research maestro, Stafford Beer.
One situation that we have found ourselves trying to experiment with recently in Surevine is how we go about building a real sense of belonging in the team when we have consciously built a company in which our people spend significant amounts of their time either working from their workspace at home or from a convenient co-working hub. Of course, we really heavily use the kind of web collaboration environments which we build for our customers, and we go out of the way to make sure that the spaces that we have at home have better kit and are better connected than what you would expect at an average office (we run internal ‘Hot or not’ competitions for the coolest Surevine workplace.) We have a regular calendar of real face-to-face meetings; and we try and get the whole company together at least quarterly. But we have also evolved a Way of Working which ensures people don’t feel isolated on a day-to-day basis. And it is in this area that I think we have a problem. I think that there are three practices we have evolved, for what seemed like a good reason at the time, which are causing issues:
- Skype presence status permitting interruption
- Scheduled daily Scrum meetings causing disruption
- Our values explicitly encouraging a ‘heads up, not heads down’ culture
The first practice basically means: when you are working, you log into Skype and set your Skype presence status to green. Green means: if you want to talk to me, just video conference me immediately, you don’t need to ask my permission via IM. We try and make sure we set our status to Do Not Disturb when we are talking to other people, but encourage people to set their status to green at all other times.
The second practice means that developers are, at the same time (around 10am) every day, drawn into one or more virtual daily Scrum meetings. But some people work best in the morning, so may already be up and running from 6am or earlier, and others work best at night and find 10am a struggle. For the latter group, who start their day with the daily, the dailies are less of an issue, for the former group, the effect of holding a daily at 10am is to discourage them from getting their head down and stuck into a juicy bit of work which takes a long time to ramp-up into, and they are more likely to postpone that until after the meeting, or even until after lunch!
The third issue centres around our own use of the kind of social tool we develop. We encourage people to microblog frequently, and have built a heuristic that if someone has not updated their status in the last hour, we should start to worry about them: perhaps they have had an accident at home? The problem with this became apparent to me recently when one of the team was demoing some cool new features the team had developed in the latest release of a secure social networking product. Throughout the duration of the demo, every few seconds, a notification popped up that he had received an e-mail, that someone he followed had updated their micro-blog status, that someone had DMed him in Twitter or liked his post on Facebook. We felt it distracted from the demo (although some of the updates gave us a laugh!) but I found myself thinking about that pattern of interruptions continuing over the whole day and how, if I were coding, it would have a really serious impact on my productivity.
This reminded me of the great article on ‘Makers schedule, Manager’s schedule’ by Paul Graham, a Y-Combinator partner, which was referred to in a presentation to the folk at Twitter “Broken Meetings” given by Merlin Mann.
Since I find most of my time now is spent building a company rather than building software, I find my day is increasingly salami-sliced. I spend most of my day talking to people, and expect to be interrupted and perhaps expect others to deal with my interruptions: I work on ‘Managers time.’ But having spent almost all of my career developing software, I feel uneasy with those continual interruptions, and yearn for those stretches of uninterrupted silent thought: ‘Makers time.’
So we, inspired by reading “Interruption is the enemy of Productivity” in the Rework book written by the folk at 37 signals, kicked of an experiment in what we call ‘Focus time.’ Twice a week, on Tuesday and Thursday from 2pm to 4pm, everyone is expected to switch off all notifications and distractions (including e-mail and mobile phone) and not to use them to distract or disrupt others.
We’ve been running the experiment for a few months now, and what we have found has been surprising and unexpected. Those of us who spend most of our day talking to people or travelling from meeting to meeting cherish the opportunity and actively plan the activities we are going to work on, during our uninterrupted focus time. Maybe that is because we are really ‘Makers’ at heart, and working in this way is a comfortable mode of operation. The stranger observation is that those of us who we thought would actively benefit most from the uninterrupted time, those who are still mostly ‘Making’ in fact routinely and willfully ignore it. Perhaps that’s because they are using other techniques to ensure they get their focus time when they need it (starting the day really early; starting later and then working later into the evening or even working at weekends) I know if I were them, I would need those long stretches of silent time.
So it seems like a good time to leave that experiment behind. Those of us who need to carve out the days can still schedule regular spans of time in the calendar to advertise that we will be setting our “do not disturb” status on Skype; using tools to temporarily switch off all distractions; and switching off the phone.
It seems like the next thing to experiment with is the scheduled meetings: our scrum dailies; the fortnightly sprint retrospective and our monthly all hands co-working days. Although these genuinely seem like an advance on other waterfall-style creeping death progress meetings, they seem for us to universally cause disruption, irritation and force people to work in ways that are not the most productive for them.
It’s got me wondering whether there is some technique, perhaps its in Kanban, which will trigger a meeting only when there is enough of a critical mass to genuinely require it.
But hold on, maybe this is just the Maker, the Engineer in me believing I can find a technical solution, a technique, to plan our way out of our perceived problem. Is that the any way to run a business? Look where that route got DEC in the end!
What would Alan Sugar say? Oh! hold on, I think I know: “You’re…”