Innovation and integration
Last week a short interview with (Sir) Jon(athan) Ive, senior vice-president of industrial design at Apple, appeared in i, the Independent’s cut-price stablemate. As the force behind such products as the iPod, iPhone and iPad, he presumably knows a thing or two about successful technology-led innovation. Mark Prigg, the interviewer, asked what makes Apple design different. Ive answered by focusing on the design process, rather than on its products, and said this:
We struggle with the right words to describe the design process at Apple, but it is very much about designing and prototyping and making. When you separate those, I think the final result suffers.
Although Ive was talking largely about the creation of physical technology objects, his words have relevance for software developers too. Integration of processes is key, he says, yet the structures and roles defined in many organizations militate strongly against this. A common problem is what could be termed paralysis through analysis. For a certain sort of organizational mind, no problem is quite so alluring as devising a logical org chart, in which each business function is resolved into a set of processes, separate roles are defined to address every stage and functional element of each process, and those roles then turned without further ado into jobs.
To those of this analytical cast of mind, jobs look well-defined when the key activities with which they are associated are relatively uniform. And indeed often this makes good sense: doubtless it would frequently be counterproductive to combine into a single job a variety of tasks that demand radically different skill sets or personal attributes. But take the approach too far and you end up with dull, narrow jobs that fail to embrace functionally substantive chunks of business process. One consequence is that to accomplish anything at all requires the effective operation of a communication network the size and complexity of which is out of all proportion to the nature of the fundamental business requirement. In addition there is the risk that job holders derive little satisfaction from their work. After all, they are not responsible for very much, and their ability to do their job depends as much – or more – on the performance of others as it does on the skilful exercise of their own abilities.
If you don’t feel responsible for something meaningful, your motivations will tend (unless you are one of those rare types able to remain serenely absorbed in a task, irrespective of how worthwhile the task seems to be) to be extrinsic – and often negative, in the sense that the principal justification for effort is liable to become the avoidance of the disciplinary measures likely to attend poor performance. Thinking about motivation brings me to something else Ive said in the interview. When asked ‘What makes a great designer?’, he replied
It is so important to be light on your feet: inquisitive and interested in being wrong. You have that fascination with the what-if questions, but you also need absolute focus and a keen insight into context and what is important – that is really terribly important. It’s about contradictions you have to navigate.
The flexible, deep engagement Ive describes surely requires an at least partially intrinsic sense of responsibility for an outcome, of ownership of the problem of realizing that outcome. (‘I want to do this, because it seems important to me.’) Ive talks about the need to be both inquisitive and optimistic, and those qualities are quite demanding in terms of the conditions they require. You must have confidence in both your own abilities and those of the organization you belong to. The harder the problem, or the more initially ill-defined the solution, the more you need the support of your organization. You need to know that your efforts will not be in vain, and that support will be available when you need it.
Probably anyone who has worked in software development has encountered situations in which innovation has been difficult if not actually impossible. These situations may be such that they fail to provide the conditions under which individuals can engage in depth with a problem, and/or they frustrate the collaboration needed to ensure that individual efforts sum positively. Commonly the problem is not lack of absolute quantity of resource, but rather lack of resource of the right type at the right times. Indeed, many failures in software development probably stem from having too many people involved with a project, working in roles that are too narrowly and rigidly defined or that are defined in a way that is somehow orthogonal to the natural grain of the business or the project.
The price of functional atomization of project resources is, more often than not, a very high communication overhead. People will spend more time in meetings trying to negotiate requirements, or writing documents, memos and emails as inputs to or outputs from such meetings, than they will in actually trying ideas out and turning them into working solutions. This is where we should heed Jon Ive’s cautionary remarks about the separation of activities. Integrate roles. Combine activities. Focus on user needs, the problem space and the functional area, not on the technology set. Select your staff well, then trust and empower them. Avoid premature commitment to a specific solution; make sure you’re exploring the solution space as fully as possible. Keep things fluid. And don’t over-decompose a project, thinking that with more staff it will get done quicker. (It will just get harder for everyone to see what they’re driving at, or to change direction mid-way.) This is where agile as it’s sometimes practised doesn’t seem to get it quite right. Sometimes there’s a benefit to providing longer periods of time for problem wrestling and solution wrangling, a chance for multiple rethinks and fresh starts of which no one need ever be aware apart from the individual or team involved. Sometimes the best solutions are the ones that look least like what you first thought you needed.