I’m enjoying Zucked by Roger McNamee more than I expected to. What’s useful about his account is the stress it places on the engineering capacity of startups. What makes cloud computing significant is not just enabling growth without major capital investment in infrastructure, but also “eliminating what had previously been a very costly and time-consuming process of upgrading individual PCs and servers“ (loc 674). What makes open source software significant is not just the reduced costs of free of the self components, but the time saved when everything can be built on open source stacks. I’d tended to see these things as a matter of reduced costs and increasing flexibility, without grasping their significance for how limited resources could be deployed within the firm.

Both mean that the engineer capacity of a startup can be directed mainly at the “the valuable functionality of their app, rather than building infrastructure from the ground up“ (loc 660). This led to the lean start up model and the capacity to go live then iterate in response to what happens. Without this modus operandi and the infrastructure supporting it, would the harvesting and use of what Zuboff calls behavioural surplus have even able to happen? A little earlier he frames this in terms of an epochal shift in the engineering constraints which tech startups had been subject to:

For the fifty years before 2000, Silicon Valley operated in a world of tight engineering constraints. Engineers never had enough processing power, memory, storage, or bandwidth to do what customers wanted, so they had to make trade-offs. Engineering and software programming in that era rewarded skill and experience. The best engineers and programmers were artists. Just as Facebook came along, however, processing power, memory, storage, and bandwidth went from being engineering limits to turbochargers of growth. The technology industry changed dramatically in less than a decade, but in ways few people recognized. What happened with Facebook and the other internet platforms could not have happened in prior generations of technology.

Under these conditions, it’s much easier to experiment and it’s easier to fail. As he points out, Facebook’s infamous motto Move Fast and Break Things is emblematic of the freedom which decreasing engineer constraints offers for a nascent firm. But what does this mean culturally? I think this is a crucial question to explore both in terms of the firm itself but also the expectation which investors then have of what constitutes adequate growth for a lean startup?

To what extent does the obsessive drive for increased user engagement have its origins in the changing expectations of investors and the challenge of meeting them?  McNamee observes it makes investors more inclined to identify what they perceive as losers and kill the startup before it uses too much money. The rewards on offer for successes are so immense that many failures can be tolerated if they lead to one success.

It also makes it much less onerous for the firm to scale, with important consequences for a nascent corporate culture. Inexperienced staff can be a plus under these circumstances, as long as they have the relevant technical skills. McNamee argues that the success of Facebook’s staffing policy had a big impact on human resources culture in Silicon Valley.

There’s a great story in Losing the Signal, Jacquie McNish and Sean Silcoff’s history of Research In Motion, relating how the management responded to the threat of the iPhone: promise an ever more amazing phone to wireless carriers and then simply demand that the engineering team produce it on a minimal timescale. From pg 142:

RIM was racing to roll out Bold phones for 2008; now it wanted to shift gears and create a new phone in nine months! It took eighteen months to create a new BlackBerry. A touch phone was something else. Although Storm would use BlackBerry’s existing operating system, it would need new hardware, radio and antenna configurations, and additional software. RIM products were reliable, never this rushed. There would be no time for proper “soak-testing”—engineering talk for working bugs out of software. Waving off protests, Conlee, RIM’s product enforcer, asked each engineer to explain what he or she needed to make the touch phone happen. The room of problem solvers reluctantly itemized the parts, software, and staff they would need, immediately. Conlee then turned to Perry Jarmuszewski, a soft-spoken radio engineer who had been with RIM for more than a decade. “Perry I guess you’re good to go. You haven’t said anything,” Conlee offered. Jarmuszewski, who preferred solving problems to making them, had deliberately held his tongue. Prodded by Conlee, he pushed back. “On a scale of 0 to 10, if 10 means no way, then this project is an 11,” he said. “It’s impossible. It’s something I would not be able to deliver.” Conlee shrugged and gave his marching orders: “Well, you guys are the heads of our engineering groups. You are paid accordingly. I expect you to get it done. Verizon wants an answer to the iPhone. We have to do it.”

Is there anything exceptional about this? I’m interested in how certain aspects of managerial culture (a basically suspicious view of the self-reporting of employees concerning workload & feasibility, a valorsation of ‘visionary’ leadership, a competitive pressure to accelerate production timelines) contribute to a reality of intensified work: ‘leadership’ in practice means stressing the fuck out of your staff, taking credit when they meet these demands and punishing them when they don’t. The problem is the competitive escalation that emerges from the fact that sometimes people do meet these demands. If that can be pointed to then it undercuts the potential objection of any other team when confronted with demands they believe to be straight-forwardly impossible.

This is how managers then talk of such a team, once they’ve been leading it for a while. From pg 149:

“This is a team that prides itself on pulling off miracles, pulling all-nighters, working hard, solving the most complex problems, getting things done on time, getting things done under the wire. This is a team with a can-do spirit,” he says.