What I learned from Alcoa
What I learned from Alcoa
Rally to a vision to help people change
Just a quick update before the essay. I’m giving a lightning talk (15 minutes) on May 8 here in Madison, but it will be broadcast online. The talk is about using virtual threads in Clojure. I’ve written an online guide to this cool new technology to go with the talk. Now for the essay.
What I learned from Alcoa
The Alcoa story is famous. A new CEO (Paul O’Neill) defied Wall Street expectations by focusing on safety over profits. Many feared the company’s demise, but 13 years later, it was worth five times as much—and their safety record was outstanding.
I won’t try to retell the story here. Go read the versions I linked above.
What can we take away from this story? There are three things I see:
Rallying vision: He found an issue simultaneously linked to profitability (injuries cost money) and intrinsically good (preventing harm). Getting people to care.
Raw leadership: O’Neill defied shareholder demands and didn’t back down. He asked employees to call his personal number to report safety concerns, personally assumed the blame for an employee's death, and fired executives who hid safety issues. Strong follow-through.
Keystone habit: I am borrowing this term from Charles Duhigg’s book The Power of Habit, which highlighted the Alcoa story. By focusing on safety, he created channels of communication, process improvement, and a focus on operational excellence. Getting people to change.
All of that was strategically chosen by O’Neill to get that last thing—to impart change. He knew asking people to work more efficiently wouldn’t be enough.
Rallying vision
While at my last job, I often complained about leadership there, using this story as an example. The company had poor vision. Read more about it in this piece:
When I was made a leader, I worked on a vision but failed to find something so singular, though I was on the right track. We didn’t have safety issues like molten bauxite, but we did have support and on-call, which seriously affected developer morale and productivity. Looking back, I think setting an ideal for zero call and support messages would have been a suitable rallying cry. They’re intrinsically good (letting people sleep at night) and linked to productivity. And I think they would apply universally. Who likes pager duty? If I ever work at a company again, finding such a vision will be one of the first things I do.
Raw leadership
The leadership would not follow through. There was cheerleading, but no teeth. Then, I was given a leadership role. And I sucked. I had moments of real leadership, but mostly, I fell prey to the pressures from above. I wished I could be saved by the CEO. Wouldn’t he see that I was right? Here’s what I learned: Everybody has a boss they need to stand up to. Even the CEO has a board and shareholders breathing down their neck. Wherever you are in the hierarchy, stop complaining and become a leader.
See this article and this one for more discussion.
Keystone habit
At that company, people talked a lot about DORA metrics. We knew that they were important, so we tracked them. Whenever we improved something, we mentioned which DORA metrics improved. Our metrics were pretty good, so we were content with them. But that totally missed the point.
The point is not that a 1% improvement in deployment frequency is linked to better outcomes. The point is that figuring out how to increase deployment frequency is challenging. It requires taking ownership of the deployment process. It requires teamwork and collaboration. It forges new channels of communication as your team negotiates better tooling with managers up the hierarchy. In short, driving the DORA metrics requires people and the organization to change.
I failed to set up a keystone habit. Now I think it’s crucial. We need something to improve, whether the number of midnight pages or the DORA metrics. Those keystone metrics need to be in tension. For instance, the safest thing to do would be to shut down the factories. So safety has to be in tension with fulfilling customer requests. Likewise, we can’t just shut off the pager. We still have to respond to issues. The goal is to have no issues to respond to.
Ideally, the leader will drive the improvements through focused efforts. Sometimes, we need to push through a stepwise change. Also, team members should be rewarded continuously for experimenting to improve the metrics — whether or not the experiments work. Further, people should be encouraged to bring up problems and setbacks (i.e., complain) so that they can come to light. I’ve been surprised many times by people having a solution to my problem, but I didn’t want to bring it up because it felt like I complained too much. Complaints are an important signal from the trenches. We shouldn’t dismiss them.
Conclusions
While Alcoa's story is special, I think it contains general lessons on leadership. My main takeaway is to find a rallying cry that people can get behind. Developer happiness is a good one. It is counterintuitive enough to turn heads, is linked to productivity, and will get the developers' support. Developer skill is also a candidate. Or drive symmathesy through the exploration of domain concepts. What vision would you get behind?