My interview and case study included quality analysis, but they did not answer a fundamental question:
How did AWS DevTool’s software development process end up in a state with such glaring problems?
To answer that question we first need to understand the history that led to the situation. When David’s AWS DevTools project started there was a single work stream. The work stream contained tasks related to building the product. There was no work to do besides build the new service using the current best practices.
When the project was launched, additional work streams were added to the software development process, some for integrations with other teams, and some to meet company-wide objectives.
When a project changes, the software development process can also change. Launching a project is a big project development that will often lead to changes in the software development process. This is expected and intended. Before launching the project, other teams will not be particularly interested in integrating with it. Before launching the project, company-wide goals will not be relevant because existing best practices will already be applied. As a result of launching the project, those things can change.
When the new work streams were added to the software development process they were not added deliberately. New types of work entered the process and were treated the same as the existing types of work. That is fine, why assume the new work streams are different?
Over time it became clear the process was not working well anymore. There were constantly shifting priorities and a lack of product vision. People were leaving the team.
If it was so clear that it didn’t work, why did nobody fix it?
Amazon does not have a culture of continuous improvement. Engineers are not expected to improve the development process. They are not given tools or resources for improving their software development. They are not rewarded for suggesting and implementing improvements. When I was at Amazon I brought improvements to my manager and he did not even consider them. My teammates had similar experiences so we stopped making suggestions. The message was clear-keep your head down and pump out new features in the short term.
Even Google does not have a culture of continuous improvement. Google does invest heavily in its software development process and empowers individuals to make improvements. But more than that is needed. The expectation needs to be that individuals are constantly looking for ways to improve the software development process. Individuals need to be given resources (like time) and tools (like process mapping) to make improvements. Individuals need to be rewarded for suggesting improvements even when they fail. Individuals need to be coached on how to manage making continuous improvements.
Cultural change is not easy, but the benefits of a culture of continuous improvement are worth it for building a sustainable business.
Leave a Reply