Scaling Delivery Using Vertical Engineering Teams — Part 3: Coding Challenges

By: Brendan Cone, Director of Engineering, Flipp

This is the third part in a series of articles discussing Flipp’s migration of its engineering organization from system-based teams to vertical (or “mission-based”) teams, and the challenges we experienced along the way. This was written last year from my perspective as the team lead of one of the first teams to make the jump a couple of years prior.

In Part 1 and Part 2, I talked through the challenges of people growth and challenges of work coordination. In Part 3, I will walk through some of the challenges we had more specifically around how we coded, and describe how we chose to address them.

Part 3: Coding Challenges

When each vertical team has complete freedom to solve problems in the way they choose, technology sprawl is inevitable.

We decided, as a team, that the best language to work with for a major back-end project several months back was going to be Typescript. We concluded that a serverless architecture made the most sense for the problem set. As a company, we had never used many of the technologies that we ended up using on that project in any production capacity.

We had the freedom to do this due to the nature of our team. It ended up being fruitful in that we are leveraging many of the features of the language and the infrastructure, but as an engineering organization it left us with a problem. We were the only team that had worked with that specific combination of technologies and coding paradigms.

Solution: Platformization and standardization.

As developers and as human beings, we tend towards the path of least resistance. As a deadline looms in the distance, we are resourceful; we will cut scope where we can to get something out on time. The challenge, then, as an organization, is to ensure that the path of least resistance also happens to be the best path for the company as a whole.

At Flipp, we have invested countless hours into developing a microservice platform as well as a set of boilerplates for our most common programming languages, frameworks and tech stacks. The platform takes care of many of the infrastructure challenges that the average developer shouldn’t have to worry about such as load balancing, containerization, continuous delivery and continuous integration. The boilerplates make several opinionated choices on individual packages that influence developers towards consistency and help define a base structure for the applications we produce.

While teams still have the freedom to deviate from the standard if their particular problem set suits it, they are encouraged to develop new boilerplates when they do. Our team produced a boilerplate for our serverless typescript architecture so that if another team finds that this is the best architecture for them, many of the technical challenges that we had to solve are already solved for them.

As a close deadline looms, developers will often find that the best course of action is to use one of the boilerplates that have been developed by the Flipp engineering community to save the manpower costs of attempting to solve all of these problems again from scratch. This allows the organization to drive toward a smaller set of standards.

Each vertical team ends up reinventing the wheel.

When you have everybody you need on your team to develop a feature front-to-back, it can be enticing to do just that. But what happens when another vertical team comes along and has to solve the exact same problem? How do we let them know that we think we already have a pretty good solution?

Solution: Make opinionated choices and tell people about them.

In addition to the boilerplates mentioned above, Flipp has also invested time in developing custom modules and packages for our most common languages which solve problems in a standardized fashion. From standardized logging formats and methods, to business metric monitoring and alerting, to reporting and exporting functionality, we have covered many of the major problem sets we have experienced repeatedly in the past. We make consistent improvements to these modules in order to benefit all the systems that use them.

The next challenge that logically follows is one of dissemination: how do all of the other vertical teams find out about these new things that are being developed for their use?

As our company’s arsenal of boilerplates, modules and packages is built up, we continue to have regular meetings among our technical leads where we discuss pain points and agree on common ways to solve them. By virtue of having the technical leads participate in the solution, it is our hope that every team has these standardization efforts top-of-mind when developing a new service or feature.

As well, the case for their use is simple when you present it as the path of least resistance: a complex task that would take weeks or months can be reduced to the simpler task of linking together several services which already exist developed by the company at large, with only a bare minimum of added business logic.

Conclusion

The transition from system teams to vertical teams can be foreign and uncomfortable for the team members involved. We encountered quite a few challenges, and we recognize and understand that there will be many more to come as we continue to make the transition.

However, with all this being said, the benefits have certainly outweighed the costs. The small adjustments that we have made as a company to attack these problems have allowed us to make the transition successfully and move into a much more promising future.