Why integrated engineering teams outperform their siloed counterparts
At first glance, the idea of integrating engineering teams with designers, product and project managers may seem inefficient. Do engineers really need to be on client calls and user interviews? Is that actually a good use of their valuable time? And more to the point: shouldn’t they be writing code?
In reality, though, we’ve discovered that integrating all the practices of our organization has led us to be not only more efficient but also to deliver more creative and innovative solutions to our clients.
Here’s a look at why, when it comes to complex projects, integrated engineering teams are able to consistently outperform their peers who operate in silos.
Integrating teams removes friction
The traditional way of building digital products involves a lot of “throwing it over the fence.” Project managers meet with the client to understand their needs, and then hand their notes to the design team. The design team conducts user research and mocks up a product that it hands off to the engineering team to build. The engineering team builds it.
Sounds fine, right? But there are two major problems with this model.
First, it can work a little like a game of telephone, where the original message gets more and more garbled as it gets passed around. It’s possible that the people designing and building the product never actually speak to the client or users they’re building for. There may also be a tendency for designs being more complicated than they need to be and engineers doing more work than necessary.
But nobody realizes that what they’re hearing is not the original message. So they execute on it and end up having to do rework. Or else they do recognize that the message isn’t clear and do their best to interpret the real message––and, if they interpret it incorrectly, end up having to do rework.
Or maybe they recognize that the message doesn’t make sense and reach out to the person “over the fence” for clarification.
This is where the second problem comes in: when teams opt for clarification instead of interpretation, they add unexpected time to the project. An engineer who isn’t sure how a designer intended a drop-down menu to function has to reach out and wait for a response. Ditto for a designer who can’t make sense of a project manager’s notes.
Now let’s revisit the idea of integrating teams.
When members of product and project management, design, and engineering are present on client calls, they all hear what's important directly from the client. The extra time spent in these interactions, where questions are fielded and answered, help prevent less back and forth later. Members of each discipline can confidently apply their knowledge to solve the client’s problems.
This is particularly valuable for complex projects, where nuance makes a big difference and changing conditions throughout the project might shift what needs to be created and delivered. To be honest, integrated teams often don’t deliver as much value for simpler projects – say, when the outcome is known and fits into an existing model. In those cases, it’s often more cost-effective to keep teams siloed.
As the complexity of a project increases, so does the value of having integrated teams (see Figure 1).
Figure 1: Project complexity and the value of integrated vs. siloed teams
But removing friction is just one facet of how integration empowers teams to build better digital products. Let’s look at another.
Integrated engineering teams make it easier to accommodate change
One big reason the waterfall software development model fell out of favor is that it doesn’t accommodate changing conditions. In today’s reality, that’s simply not tenable. The Agile Manifesto, on the other hand, explicitly prioritizes responding to change over following a planned linear path.
Integrated teams are great at responding to change.
Let’s use a non-software example to illustrate how: imagine you’re cooking dinner for a group of friends and you send your partner to the store for ingredients. When they get there, the store’s out of a key item. What do they do?
Before cell phones, they might have brought back five options in the hopes that one would work. Today, they might text to check. But if you’re not near your phone, you might see the message too late.
Imagine if you were truly integrated: say, you each had one earbud in and were tuned in to an open phone line, only speaking when you needed to. Then your partner could ask about specific options and you could reply in real time.
Similar scenarios happen in the world of building digital products all the time. We can’t divine the future, so we often find ourselves responding to changing conditions. For example, we may find that real-world data doesn’t let us implement good upfront designs. The data might cause a field to wrap or overflow in some way. There might be a hundred ways to fix it; working directly with a designer is the fastest way to determine which way is best. What's more, when we do that, both sides gain new understanding they bring to bear on future projects.
This way of operating is possible because we’re well integrated. We have Slack and Zoom and other tools that make us readily available to each other, even in a distributed environment.
When we’re truly integrated and accessible to each other, we can troubleshoot in real-time, adjust, and move forward.
Integrated teams can produce more innovative outcomes
When everyone is in the same (virtual) space, we can cover lots of ground fast. A designer might sketch a visual metaphor to achieve a specific goal. An engineer in the room might recognize that the design won’t work with the way the backend has already been built. They can explain this, then help the designer understand what will work. The designer can mock it up, and everyone can move on. (Like telling your partner to put down the white vinegar and grab a lemon.)
On a siloed team, that resolution might have taken a week of back and forth between teams.
And that’s just one tiny example. If you’re familiar with Agile development, you’ll recognize this as one of its key principles: individuals and interactions over process and tools. When individuals interact with each other, the team can move forward faster, which means we’re able to push ourselves toward more creative solutions than we’d be able to achieve if we spent our time documenting, clarifying, and reworking.
What we’ve found at TXI is that this forward motion has a sort of snowball energy: we’re not only able to move forward together faster in individual client engagements; we also learn from each other in each engagement so that we can start farther down that path toward innovation each time.
Designers learn what objections engineers might have and so mock up solutions more likely to be technically feasible. Engineers get a better sense of which functions users prefer and so build with that in mind. Everyone has a clearer sense of the client’s business goals so they can work with the big-picture end in mind. And so on.
Integrated teams innovate better
There's a famous Harvard Business Review study that demonstrates how businesses whose teams have more racial and gender diversity outperform those with more homogenous teams. The reason is that more perspectives leads to greater creativity and more innovation.
The principle applies for all kinds of diversity: when teams responsible for owning different elements of a digital product (desirability, viability, and feasibility) collaborate throughout the process of building a digital product, they’re able to develop products that users want, that benefit the business, and that work technically. And they’re able to do that faster. When those teams also include people from a variety of backgrounds and lived experiences, the outcomes are even better.
Interested in discovering how our integrated teams can help drive innovation at your organization? Get in touch. We’d love to start the conversation.
Published by Patrick Turley in Product Innovation