What goes into decision-making when it comes to structuring engineering teams?

It takes the form of KPIs and formulating a plan-of-action. For a company, their engineering team structure is designed to tackle the problems at hand. Building features? Fixing bugs? Streamlining previously built features, which introduces more bugs, which then need to be fixed?

It comes down to a story of growth. How should the company grow? How should it allocate its resources such that it is efficient in growing? The engineering team is a resource; their time and focus is limited and you want them to be as nimble and simple to pivot as possible so the resource has minimal downtime.

In this post, we’ll go over several factors that affect how companies should select KPIs:

  • Whether they can afford to focus on long-term versus short-term goals
  • How growth introduces complexity
  • How the product’s maturity influences learnings, bets, and growth initiatives

We’ll start with a metaphor of the company as a seed.

What are Its Long-Term vs. Short-Term Goals?

It’s a seed with a dream: one day, it will be a giant tree. But given its current state of limited resources, it has very real, very short-term worries. Can it survive? Can it germinate?

What can a seed afford to do in this position?

Emerge. Take root and put out a few sprouts that can collect some immediate, unfiltered sunlight.

The seed’s entire strategy is focused on surviving the next few days or months. It would be pointless to plan years ahead of time when it’s not even a sapling. Putting out roots and sprouts right now is an actionable, short-term KPI. It knows what it wants to accomplish with this growth, and it can get that done immediately. It shouldn’t spend time deciding how it’s going to bear fruit because that’s not an immediate concern.

The seed is limited to short, achievable goals.

After all, without immediate access to ground, water, and light, it won’t survive at all. Worrying about competing seeds or incumbent trees should not matter. The only thing that matters is the short-term impact of the decisions it makes right now.

We could envision some KPIs for this seed:

  • Focus on resource acquisition now to ensure its future ability to pivot to longer-term goals.
  • Gain a foothold in the immediate surroundings instead of aiming for ground that is currently out of reach.

When the seed grows into a stronger sapling, it can begin to sacrifice some short-term KPIs in service of its longer-term goal of becoming a giant tree. But it cannot store nutrients for long-term growth when it needs to burn them to power short-term growth now. It needs to make the most of every resource at its disposal.
If the seed were a nascent mobile team, what would this resemble in its engineering team structure?

  • Small teams, probably just a single iOS and Android developer. They handle everything from feature development to debugging to monitoring.
  • Prioritization on feature development over stability and performance concerns. After all, the most important thing at this stage is acquiring users.

The mobile team cannot afford to specialize at this stage. There’s not enough money or manpower for separate feature teams, tooling teams, platform teams, etc. Once the app starts growing, the mobile team can explore these options.

The Complexity of Growth

Once the sapling grows a thicker base, a strong set of roots, and releases more branches, it becomes a tree. It begins measuring where it’s seen success and where it’s failed to see a return on investment. It prunes offshoots that have grown into areas without sufficient sunlight. These offshoots are not producing dividends, and it’s better to dedicate resources where there’s a better chance to succeed.

This does not mean the tree does not try new prospects for growth. On the contrary, the tree must continually make bets. After all, any KPI is a gamble.

For larger bets, the tree must weigh the complexity each undertaking requires:

  • Does the growth require investing in branches with very specific skillsets (e.g. team specialization)?
  • Does the growth require a large outlay of resources (e.g. high CPI)?
  • Does the growth require branching into completely different areas (e.g. new regions, user segments)?

This is important because the same engineering team structures that worked as a sapling may no longer work as a tree. Vertical growth can only do so much before horizontal expansion is necessary. And so the tree may change its structure for growth and reallocate resources as a result.

The tree’s bets might have underlying complexity issues that require certain skills it may not have and thus would need to develop internally or with the help of others. For the tree, it may expend resources to attract pollinators or develop seeds capable of flight.

Companies do these all the time. A mobile company may need new features once the product has reached a certain stage. Do they shuffle their engineering team to build it? Do they buy it from third-party vendors? Once again, KPIs come into question: how and where should the company expend its resources to achieve the growth it wants?

Product Maturity

Is the tree continually learning, placing bets, and growing?

Our tree, much like a startup, is constantly doing all three. But at times it needs to focus — how does it know when this is? Let’s go back to KPIs.

Learning is something that needs an objective. This may differ for each company depending on what space that company is in and what their short-term and long-term goals are. But learning must have a goal. For our tree, this means evaluating every play for whether it contributed to growth and what the cost in resources was. It also means taking steps to learn different things based on its lifecycle. After all, the learnings from when it was a sapling will differ greatly from the learnings when it is a tall redwood.

The tree should adjust the size and type of bets it makes based on its size. The larger the tree is, the more risks it can take. The tree should put more resources behind initiatives with outsized returns and pivot away from bets that aren’t panning out.

  • Is it large enough to outgrow the currently tallest tree?
  • Can it steal sunlight from nearby trees to further its growth?
  • Can it drop the leaves from branches that have grown into heavily shaded areas?

The tree should also make decisions based on how fast it is currently growing. Initiatives that offer meager returns might have been worthwhile when it was a sapling but become distractions once it gets to a certain size.

…and it grew, taller than the rest, for it was guided by knowledge, means, and good allocation of its resources…

Embrace believes all seeds can grow, yet not all make it. Sometimes, the seed was planted in a poor location. Other times, the KPIs were set incorrectly, resources were spent that produced no results, or the worst case: that seed had no idea how it was supposed to grow.

The beauty of KPIs is that when used correctly they serve as a great outline for determining growth and how the engineering team should be structured!

Engineering team structures are like the tree’s systems — they’re designed for efficiency at whatever they do, whether it is providing maximum surface area to capture sunlight or attracting pollinators for germination. But unlike a tree, companies can adapt and make changes quickly — as soon as an engineering team needs to reprioritize, it can be restructured and given new KPIs.

There is a common denominator for making these decisions and that is information:

  • How can you set a KPI when you don’t know what should be measured?
  • How can you grow in a certain direction when you don’t know what lies at the end?
  • How can you know when to prune when you don’t know if pruning is the correct decision?

Visibility and organization of information are what empower mobile teams to quickly adapt when changes need to be made, whether they entail building new features, fixing broken ones, addressing user complaints, or expanding into new products or regions.

The mobile teams we work with frequently tell us that their previous tooling:

  • Overwhelmed them with information that wasn’t actionable
  • Required manually processing data to discover insights
  • Forced mobile engineers to waste time stringing together multiple sources of information only to end up with limited visibility into the problems affecting their users

The good news is, Embrace can help.

How Embrace Helps Mobile Teams

Embrace is an observability and debugging platform built for mobile teams. We are a one-stop shop for your mobile app’s needs, including error debugging and monitoring performance and feature releases.

Want to see how Embrace can help your team grow your app with best-in-class tooling and world-class support? Request a customized demo and see how we help teams set and exceed the KPIs that matter for their business!