Optimizing Our Product Development for Scaling Up

Since the last time we wrote about our Engineering practices in the fall of 2019, we have yet again doubled the number of product development teams to 26, multiplied the number of micro-services, and expanded to support two new advertising platforms — Snapchat and TikTok. What's more, we have shifted from a more or less fully co-located setup to a hybrid setup in early 2020, with developers working from across Finland and Germany.

Growth and complexity can't result in sluggishness in an industry as fast-moving as ours. So to maintain our product development speed and react quickly to changing customer needs, we have reshuffled our Product Development organization and optimized our ways of working.

Mitigating siloing of autonomous teams

Software development at Smartly.io has always been based on strong and autonomous teams, and that has not changed. Our full-stack teams still take end-to-end ownership of their parts of our platform. Especially when combined with fast growth, however, the flipside of autonomous teams is siloing. If left unchecked, everything from the infrastructure to the user interface can turn into a hodgepodge of isolated, poorly coordinated elements.  

To avoid sacrificing the development teams' autonomy while ensuring a seamless user experience, we grouped the teams into product development units based on shared goals. These units are Media, Creative, Architecture, Infrastructure, Data Science, and Engineering Operations.

Just like our development teams have an Engineering Manager and a Lead Engineer, each unit has similar leadership roles. There is an Engineering Director in each unit who makes sure the teams are all pulling in the same direction, and a Principal Engineer who oversees the technical work and could also be considered as the unit's architect.

Since we offer one SaaS (Software as a Service) solution, all the units need to work towards the same end goal. And for that, we must bind the groups together —loosely, to maintain autonomy, but still. We manage this loose coupling through Objectives and Key Results and Actions – in short, OKRAs. First, objectives are defined at the company-level and drawn from the strategic roadmap to make sure we are aligned as a company. Then, the units and teams within them decide the best ways to reach those high-level goals and set their own Key Results and Actions. When goal setting is transparent, it's easier to coordinate the units' and teams' plans. This way, we work towards a shared vision while allowing teams their independence and maintaining their velocity.

More focused efforts through Discovery, Planning, and Delivery

Previously, each autonomous development team was responsible for delivering features and functionalities without a shared framework. This worked well for a small team of engineers but began to pose discrepancies in long-term planning and forecasting when our team grew. We also noticed that the teams were not equipped to weigh in on strategic decisions without clear metrics and predictability.

To maintain our ability to anticipate customer needs and our speed in turning them into successful products, we have fine-tuned our discovery-planning-delivery pipeline. As our business has grown to serve a larger, more diverse customer base, there is an increased need for Discovery. Close collaboration and continuous dialog with key customers, as well as dedicated Product Managers and Product Designers help development teams focus on shaping solutions that create the most impact and value. Together with the Product Director, Product Managers are also responsible for coordinating with their peers in other teams to align efforts within the same unit.

As soon as the team is confident that the new development item, possibly a new feature, brings value to our customers, they enter the technical Planning stage. The outcome of the planning process is a work item that meets our Definition of Ready — has an explanation of what we are building, how, and how long it takes to implement.  

The whole team takes part in planning new development items. Our Chief Technology Officer Lauri Tarkkala recently wrote a blog post about how we have adopted a more structured estimation cycle. Typically, we follow these rules:

• Epics should take 3–6 months.
• Stories should be completed in two weeks.
• Tasks should be doable in a day.

Some teams use story points in their estimates, but most follow a #NoEstimates principle where work items get broken down into similar-sized parts, and you can predict how long it will take to complete those. After the pandemic closed our offices, all teams started using JIRA to keep track of their progress and backlogs. This has proven to be a better solution than our beloved physical boards.

After the plans are clear, implementation kicks in at the final stage of the pipeline, called Delivery. This is the domain of the development teams, and they take full ownership of it, which allows Product Managers and Product Designers to work on the following Discovery items.

Usually, our teams own specific micro-services that live in their own repositories in version control. Therefore, we can make changes in several parts of our solution by providing clear APIs without extra waiting times or extensive coordination effort. This setup makes expanding the product easy and helps teams to stay independent. However, scaling our organization in terms of people and micro-services started to pose challenges with running our development environments on developer notebooks. Our Developer Tooling Team has tackled this challenge with the help of Kubernetes, providing each developer the possibility to test any changes on our application in their own test environment and, as a result, getting more capacity with fewer constraints on equipment.

We deploy to production several times a day to get the deliverables to customers. Through fast implementation, continuous deployment brings value with a quick feedback loop and a better customer experience. Incomplete features are hidden behind a feature flag, allowing us to do A/B testing and gradually roll out new functionality to our customers. The upside with the controlled release is that we can react faster to changes in customer needs and build more valuable solutions for customers.

Reworking continues towards the next phase

We continue to monitor how our redefined ways of working support increased product development speed and quality with the most changes implemented. As we continue to grow, we will continue to revisit our delivery pipeline and organizational structure, as well as other engineering practices. Even though we have a bit more structure nowadays, we continue to believe that independent and empowered teams are the best way to move fast and stay relevant.

‍