Structuring engineering teams to deliver value to multiple markets
What’s the ideal organizational setup for a company building a digital product? Of course, there’s no single answer. It depends on many factors, including the stage of the organization, business domain, company culture, and underlying technology. But here I’d like to share the approach and principles our team has successfully applied at heycar.
As an engineering org and company as a whole, we believe the ability to connect with customer needs and country market specifics is critical for our success as we expand into new markets. So, how do we structure our organization to reflect that?
Introducing stream-aligned teams
Teams can be organized in many different ways. You could have a stable, long-living team structure with flexible project-based assignments. You could organize teams around domains or product features in a cross-functional way, or around technologies or functions such as backend, frontend, and infrastructure.
In Team Topologies, Matthew Skelton and Manuel Pais introduce four basic types of team: stream-aligned, platform, complicated-subsystem, and enabling. Their core idea is to build your organization largely relying on stable cross-functional teams organized around value streams.
Stream-aligned teams are focused on a single stream of work. This could be a whole product, a service, a given user journey, a user persona, or even a single feature. The team is focused on delivering user value quickly and independently without relying much on other teams to perform other parts of the work.
Building stream-aligned teams require effort. But there are a number of best practices you can adopt to help you get there, from domain-driven design and the reverse Conway maneuver to measuring and reducing cognitive load, and more.
Here I’m going to focus on the importance of building your stream-aligned team in synergy with the overall organization structure so that you can allow for a direct connection between engineers, business experts, and your users’ problems.
Building cross-functional value streams across the organization
Too often, the structure of engineering teams is discussed in isolation from the design and communication of the entire organizational structure. But for overall efficiency, engineering structure should go hand in hand with value streams design across an organization.
We know the benefits of cross-functional setup and team autonomy in engineering orgs. We can reap the same benefits by including business development, marketing, or customer care folks in the same value streams.
When different functions are working on the same value stream, getting them to bond early in the process is important. It makes a big difference when you see your colleagues as teammates rather than stakeholders. We’ve had engineering participate in creating business plans and participating in the early discovery of business ideas. What value could engineers bring to such an exercise, you might ask? Well, they can give very fast feedback on the complexity of the ideas and various product development directions, bring their own ideas based on delivered solutions in the past when working on similar problems, get a deeper understanding of some business problems, and simply bring their analytical and critical mindset into the room.
Close collaboration between engineering and people from other teams also leads to a better understanding of engineering problems in the broader organization. When a company’s core offering is a digital product, the tech is the backbone of the business, and a wider understanding of what’s happening in the engine room is essential.
When our non-engineering colleagues understand and support our work, it makes it easier to maintain solid engineering standards, address technical debt, spend proper time on design and research, and not rush the delivery of product features. I’ve observed that in organizations with a close cross-functional alignment, leaders of different functions become more empathetic toward each other’s goals and challenges.
Also looking beyond immediate requirements and understanding what’s waiting for the product behind the corner helps us to make technical decisions that will work long-term. Having a continuous flow of information on user feedback and business plans can help with that.
Using local-focused teams to address local market needs
When your product starts working in multiple markets, you’ll probably find that different markets vary by nature. Sometimes all you need from an engineering perspective to make a product launch in another country is to add localization to another language. In other situations, however, taking a product to another market can feel like completely reinventing it.
The difference in user needs and competitors impacts the market, country legal regulations, local logistics, financing partnerships, and many other peculiarities that can bring significant localization needs. These needs can be fairly major and might drive the creation of local market-specific value streams of their own.
Having a good understanding of the local market becomes more challenging with company growth and international expansion. To have a better understanding of the local customer and business needs, many companies decide to have local offices with customer care, marketing, business development, and other functions. It’s certainly a proven idea to hire people from the same location to bring that inside knowledge into the company. Some tech companies create product roles per country or region to bring local requirements to global teams.
At heycar, we believe in connecting engineering directly to the local market specifics. That’s why we have engineering teams working with a focus on local markets, forming part of cross-functional, market-specific value streams.
A larger part of our product will be the same in all the countries we operate. At the same time, we acknowledge that in some cases we need country-specific solutions. Some examples from the heycar product include market-specific partner integrations to catch attractive offerings. As a result, we have engineering teams focusing on a given market (such as Germany, UK, Spain, etc.), teams focusing on several markets, and many more teams focusing on global fully-international parts of the product.
By designing an engineering organization around common business value-stream teams — both globally and locally — in synergy with the overall organization structure, we’re able to deliver maximum value to customers in multiple markets.
Originally published at LeadDev this post is also a part of a 4-episode series on how to build an engineering culture that centers on a customer. If that’s the challenge you are aiming to solve the other publications in the series could be helpful as well.
