Why I Gave My Engineering Team a Chance for a Do-Over

“Don’t reinvent the wheel,” the idiom cautions us. It’s a phrase that seems wise on the surface, a reminder to not spend time creating something that already exists. Too often, however, the idiom has been deployed as an admonition, a warning to not upset the way things are, even when those things are outmoded or just plain wrong.

Creative engineering minds, thankfully, generally ignore that kind of advice or we would all still try to get around on wooden rims and spokes. Wheels -- and many other things -- do frequently need to be reinvented to take advantage of advances in technology and changes in customer needs.

Technology companies are at such a moment of inflection now. Even as they have invested in monolithic applications, they have had to shoulder the limitations imposed by the size of their code and their inability to handle independent scaling. Many now understand that they will need to transition from a monolithic application to a microservices architecture in order to better position themselves for future growth and product development. A microservices architecture offers greater global accessibility and enhanced functionality for customers. It makes it possible to iterate new features and improvements as they naturally occur and creates a flexible platform for the integration of future products and features.

Shifting from a monolithic application to a microservices architecture also enables engineering teams to innovate at the pace inherent to that team and to scale up based on the needs of the specific microservices they are developing. The shift allows the team’s technical vitality and innate innovation to flourish as they experiment to find the best way to deliver new functionality. It frees an organization’s best minds to try, and occasionally fail, without compromising a product as a whole.

Nevertheless, as they reinvent their respective wheels, leaders of engineering organizations should know that there are five challenges they will face as they transition:

1. Embrace cross-functional complexity. If your organization has not already taken down the walls between engineering, product, tech-ops and QA, the first steps towards your new direction must begin there. The goal is to build cross-functional teams focused on overall product features and delivery, not merely looking to add next-gen bells and whistles to an existing product.

All of us in this field know Conway’s Law, but we don’t often set up the foundation for change in a way that will avert a collision with it. There is no easy path to a microservices architecture from a monolithic environment. Leaders must resist the impulse to simply build a new monolith and migrate over to it when it seems done; they must embrace the nuances and complexity and reinvent their product at its core based on the needs of the business and functionality, not just technological feasibility.

2. Let metrics drive. With a cross-functional team in place, the next step is to break up the existing system incrementally, taking it apart functional module by functional module and reinventing each one in turn, with the right metrics top of mind. We learned that replicating an existing functionality into the new services alone was not enough; each engineering leader had to define success metrics for every new service.

Leaders must define the cost metrics of the changes that they are envisioning and clearly communicate them to their engineering organization, and they must make sure that engineering has all the data it needs to make appropriate, data-driven decisions. There must be checks and balances such as frequent and recurring design reviews to keep the work aligned with company objectives.

3. Automate, automate, automate. Tech teams also need to be encouraged to move away from a narrow reliance on tickets to address features and feature bugs. Our own infrastructure engineering team learned to scale from solving individual problems to building tools that enabled different microservice teams to solve problems. Process and handoffs have to be supplanted by tools, with an emphasis on automated tools. In a simple environment, one can have a single team member look at a graph. If latency breaks a threshold, a troubleshooter can be called in. With a complex environment, all of this must be automated.

4. Make mistakes and learn. We’ve learned a lot from the past two years, and have made it a goal to share learnings in engineering all-hands meetings every month. To successfully implement a transition to a microservices architecture, teams must have frequent working sessions around the APIs they are creating, as well as around the functional changes that will be needed in each of the envisioned microservices.

As they work, they must be given time not only to put forward new ideas, but to make mistakes and to learn from them. To circle back to the wheel analogy, remember that the original models didn’t have rims or tires. Both were innovations brought about through learning about how people were using the wheels, and feedback regarding what more they desired them to do.

5. Grow into the new approach. Leaders must also acknowledge that the existing company and its monolithic application must continue to thrive during the transformation process. That will mean starting the microservices transition with a small team and then growing incrementally as each success is achieved. Zuora began its transition with a team of only two, and has made progressive investments to expand the team to its present size of over 30. Leaders must also take care to avoid labeling their engineers as two separate teams (e.g. the “old” monolithic application team and the “new” microservices team).

All team members are needed to maintain the company’s growth and development, and there should be opportunities for all engineers to participate and move forward with the new direction. Zuora's practice is that a single team will own the same functions in the monolith and in new microservices. This team will be responsible for reinventing the functions in the monolith into new microservices, migrating existing customers to the new microservices, and sun-setting the functions in the monolith. This is how everybody participates in and contributes to the reinvent initiative.

Transforming to a microservices architecture requires a transformation across all disciplines: engineering, QA, program management, operations and product management, as well as customer support. It will not be easy work, but a shift to a microservices architecture will provide ancillary benefits well beyond primary goals because it brings consumer-level scale and architecture into the enterprise and makes it easier to take advantage of changes in the computing and technology landscape. It also allows each microservices product team to act as a mini-startup company within the organization that owns its own destiny, innovates at the speed of its brightest minds and maps its own journey--which it will travel on an ever-adaptable set of wheels.

Brent Cromley, Jr. is the senior vice president of engineering at Zuora, Inc., a SaaS company that is an evangelist of the Subscription Economy. A graduate of Dartmouth College, Cromley joined Zuora in 2016 from Zappos, having grown its tech team from 15 engineers to more than 250 worldwide.