Alignment on great product teams
To move quickly towards a mission, the core attributes of product teams –strategy, design and engineering – need to be well aligned.
But how do you achieve that alignment and what happens when you don’t? I gave a talk at Building Intercom on alignment as a key quality of a great product team. You can watch the video above or read on for a lightly edited transcript.
Startups, they’re a bit crazy, right? What really drew me towards startups as a place to work was just how intense and exciting they can be.
They’re exciting to me, because when your company is as small as a startup, the scope of ownership that you have and the scale of your responsibility is going to be so much larger than they would be elsewhere. Individually then, the impact that you can have towards the success of your company can be huge.
What makes it intense though, is that your time is short. That time that you have to build a really great product that’s either compelling to consumers or investors is really limited. If you don’t manage to build a great product in that time, it’s game over for you and your company.
Alignment equals speed
Early on, you have to be able to move with so much momentum, just to have a shot at success. It can absolutely feel like you’re just figuring out where the track should go as you’re hurtling down it. Especially in this startup world where individuals can have so much impact, one of the things that you need to get right is ensuring that you have good alignment.
Now, half of you are probably thinking right now, “Alignment, what a buzzword,” and sometimes I’d agree, but what do I really mean by it? To me, it simply means knowing what is it that’s important in what we’re building. What does it mean to be building the right product for our customers?
“There are three core pillars that good product is built upon: engineering, design and strategy”
I’ve been an engineer at Intercom for about three and a half years now. To put a little color on how we’ve changed over that time, when I started at Intercom, it was this itty bitty startup, and now we’re a company that puts on engineering events at Vicar Street.
We’ve obviously grown a lot, and we’ve changed a lot. But, over that time and throughout all that change, I’ve thought a lot about the great product teams that I’ve worked with and the consistent qualities that they have. To me, alignment is one of those qualities, and I want to give my take on how that works.
The core pillars of product
When I think about product, I think that there are three core pillars that it’s built upon: engineering, design and strategy. I think of these as the dimensions of products. A really great product will be strong in each dimension. It’ll have a smart strategy, it’ll be well built and it’ll be easy to use and understand.
To give a concrete example of that, I think the original iPhone is a really good product that was strong in each dimension. It was well built. You couldn’t just put in a blank password and log in. It was so easy to use that my grandmother could use it. Apple really nailed the strategy at the time.
While their competitors were focusing on making things like business email in your pocket easier, Apple came along and put a platform in your pocket and just let you do what you wanted. Maybe had this not happened, Gavin Joyce’s demo would have been us sinking polyphonic ringtones in our Blackberries. But, it covered the entire spectrum, every dimension of product.
At Intercom, we structure our product teams to try and capture each of these dimensions, too. Typically, a product manager will take on team strategy, a designer will take on UX and ensuring that the whole system fits together and engineers will build, run and maintain our systems. But, we all work together in unison to try and make this product.
It’s interesting to think of product in this way, as something that exists in this space, something that isn’t just one dimensional, that appears as an icon on an app store or as a website in your browser. But, maybe what’s more interesting to think about is how do you actually get a team that’s capable of building a product that’s strong on each front. Because, for every original iPhone team, there have been thousands of teams that have just crashed and burned along the way.
Multidimensional skill sets
Well, maybe a good place to start is with you, the individual on a team, and the skill sets that you bring to your team. As an engineer, you’re naturally going to be more focused on those engineering problems such as making sure it’s scalable, making sure your product is fast and making sure it’s well tested. But, you’re not completely one dimensional. Regardless of what your core discipline is, you’re still going to have some knowledge of the workings of the other dimensions.
Does anyone remember Top Trumps, that amazing game you used to play as a kid? It’s kind of like that. You’ve a range of skills. You’re not just one dimensional. Top Trumps would have been terrible if it was just a single number on a card.
Thinking of individuals in this way and the skills that they bring to the teams kind of opened up this chain of thought in my mind, that teams are like vectors. I can look around, and some of you are probably having Vietnam-style flashbacks to your Leaving Cert maths classes where you didn’t really understand what a vector was. But, I was bad at maths too, so I’m going to walk you through what it is.
“Each individual on a team has influence and bias”
A vector is simply a quantity that has a magnitude and a direction that it moves in. But, the interesting thing about them is, if you have multiple vectors and you combine them together, the overall output of that function is the individual magnitudes, the individual directions of each vector put together.
That’s interesting, because I think that maps really well to teams. Specifically, I think it maps really well to the different functions of teams coming together to try and build a product. Just like a vector has magnitude and direction, I think that each individual on a team has influence and bias.
What do I mean by that? Well, influence is just the pull someone has over another person. It’s a common property of any human relationship, really. It’s that person’s ability to really push for change in a group of people.
Why is this an interesting one, though? People hear that word and they think, “Bias. Who’s biased? I’m not biased.” We are all biased. But, I don’t mean it in a negative way.
In a sense of building products, your bias is just that area that you’ll naturally give more focus because of the skill sets that you have. Again, as an engineer, I’m obviously going to be more focused on a scaling problem than some UX problem that my designer’s looking at, regardless of the overall priority and impact that it has on the product that we’re building.
“It doesn’t matter how fast you’re moving if you’re building the wrong thing”
If you take each individual then and you look at their biases, the skill sets that they bring to the table and the levels of influence that they have, that is typically what determines our levels of ownership in a team, that kind of slice of the product that they will really fight for and think about. If you take each of those individuals and you put them together, just like we did with the vectors earlier, that is what will determine the direction your team will take and the momentum it will have. Remember, early on, we need to move at such momentum just to have a shot at success.
The direction and momentum of a team
Your team’s direction is interesting, though. Because, if you get that wrong, it doesn’t matter how fast you’re moving because you’re kind of screwed anyway. You’re building the wrong thing.
Great teams are well balanced. They’ll have strong owners in every dimension. They’ll know what it is that’s important to their customers because they cover it from every dimension. In poorly aligned teams with unbalanced people, they’ll be trying to pull the team in all different ways. They’ll build the wrong thing in the wrong way.
Let’s imagine for a second that you’ve just started a new company or a new team within the business that you work in, and you’ve built this team, you’re really confident that you have the skill sets needed to build a great product. You can kind of get almost this map to success in your head.
“Really great product teams are constantly tuning and iterating on the direction that they’re moving”
Unfortunately, our road maps in work don’t actually look like maps. I kind of wish they did, though. But, it’s easy to get this map to success, right? There’s this X that marks the spot. It’s that perfect product that you want to build. It’s a straight line down the road, right? I have a great plan, I have a great team. Everything’s going to go perfectly. Real life is never, ever that simple. There’s always going to be unforeseen challenges along the way.
Imagine I’m the engineer on this team, and somewhere down this road I see a problem that we’re all intimately familiar with. It’s that scary mountain of technical debt. As a team, we were originally moving in the correct direction, with good momentum, but if we don’t change what we’re doing now, we’re going to hit this first mountain.
It’s my responsibility, as the owner of that engineering dimension of the product that we’re building, to pull my team around this mountain. But, the only way that can work is if the other functions on the team trust that I am doing the right thing. Because, remember, they’re going to be biased as well. They will have a vision of where they think the team should be going. I need them to trust me that I’m doing the right thing and pulling the team in the right way.
Sometimes you need to repaint the picture of what you think is true
The direction of your team needs to be fluid, organic and reactive to what life is throwing at you. Really great product teams are constantly tuning and iterating on the direction that they’re moving. David Lynch put it in a really nice way. He said that sometimes you need to repaint the picture of what you think is true.
It’s that diversity in your team, that diversity of skill sets, that gives you vision to see that problems are about to occur. But, just having vision isn’t good enough if you can’t actually react to them. It’s that ability in you and your teammates to be able to realign and compromise on where you think the team should be going that actually lets you react.
If you look at any successful project, you’ll see that you’ll have weaved and bobbed through loads of challenges along the way. Passive teams, the teams that never changed how they worked, they’ll still be stuck on that first mountain.
What happens when you have poor team alignment
We really value this kind of iteration at Intercom, this tuning of direction. It’s something that we really try and do every day. But, we’re human, and we’ve absolutely gotten it wrong. I want to go through an example. It’s a feature that we built almost two years ago now. It’s called Smart Campaigns. It’s essentially a feature that would intelligently deliver the best message to the best people at the best times. Sounds good, right?
The first version of Campaigns that we launched, on the face of it, was successful. It solved some major requirements of our customers, it made Intercom a much more powerful messaging platform and shockingly for this industry, it launched almost on time.
Internally, though, it was a scaling nightmare. It kept engineers awake at night. It cost us a lot of money to run, far more money that we’d ever hope in making in profit from it. In fact, simply running it was a danger to the overall availability of our product. And fuck me, I led that project. How did we get to this point? But, I want to go through it, I want to touch on it, because, to me, Campaigns is the perfect example of alignment in a team gone wrong.
See, when we started building Campaigns, we thought that there was this strategic need to build this huge feature set for our customers to use. We thought that because we had customers using an older version of our messaging system, and we wanted them to move to Campaigns.
However, there is an upfront time cost associated with them actually doing that, and we wanted to make the choice as compelling as possible. Serena Fritsch talked about having empathy with your customers, and this was us very much trying to tick all the boxes.
“Misalignment in a team compounds on itself. The longer you leave it, the harder it is to get back on track”
As engineers, we could see that there were going to be scaling problems down the line, but we were so strategically aligned to this vision that we needed this huge product breadth, that we just kind of hoped that we could buy more AWS instances and buy more Mongo capacity. All right, that’s going to be cool.
Real life doesn’t work that way. Just like the straight line down to the X on the map, it’s never that simple. I think maybe Serena said that it took her 6 weeks to rebuild Snooze. It took us 7 months to get Campaigns to a place where it was stable.
You know what? Retrospectively, we looked back at the feature set that we built, and we realized we didn’t need all of this stuff. We were all so blinded by this strategic vision that we never fought for that engineering side. There was absolutely a smaller set of features that we could have shipped, that we would have nailed on all of these dimensions.
My key takeaway from that was we were misaligned from the start. But, misalignment in a team compounds on itself. The longer you leave it, the harder it is to get back on track. I should have fought for my engineering ownership earlier and brought us back on track.
But, it’s a learning process, right? Getting this alignment right is hard. You have to be able to constantly tune where your team is going.
The T-shaped skill set
I talked about the benefits of alignment to a team and how it helps your momentum early on, and we’ve also shown what happens when it goes wrong. I’ve also talked about this concept of being able to fight for your area of ownership, or being able to compromise when someone else is fighting for theirs. But, those are kind of opposing points, right? How do you actually get the skillset to know when you do that? What do you look for in a really great product engineer, or just a great teammate in general?
There’s a lot of talk about T-shaped people in the tech industry, and certainly when I was a manager, these were the kind of people that we really wanted on the team. For those of you who aren’t familiar with what a T-shaped person is, it’s simply a person who has great depth of knowledge in a single area, but great breadth of knowledge in many others. It’s that breadth of knowledge that let’s them know how to approach problems outside of their domain. They’re curious people. You tend to be able to throw them in the deep end, and they’ll figure out how to swim.
“Great product engineers should have insight into things like product strategy or the UX system that we’re using”
Now, in a great team, each individual should understand the high level function and concerns of the other functions on the team. That might be me, as an engineer, understanding why getting something to market now is more important than fixing some issue that’s been really annoying me for the last week.
If you go back to this original T-shape, and you zoom out across roles, you’ll see that it remains true. Great product engineers should have insight into things like product strategy or the UX system that we’re using. You don’t have to be the expert, and I’m not saying that you have to be at all. Just having that overview can give you this amazingly useful empathy with the people that you work with.
Everyone has a mental model of product development, it’s how they think about the process. It’s two different sides of the same thing sometimes. When you gain this broader context, you start learning the mental model of the people that you work with. You start learning how they think.
“Teams are all about balance between individuals, what their vision of the team should be and what’s actually good for your customers”
When you learn how someone thinks, you learn how to communicate with them incredibly effectively. You learn how to say when you are fighting for something that’s critical to you, and you learn when they’re fighting for something that’s critical to them. It gives you this overall empathy and trust with the people that you work with, and it’s those two skills that give you the ability to know when to compromise and when you should fight for you area of ownership.
Balance on product teams
At the end of the day, teams are all about balance. Balance between individuals, what their vision of the team should be and what’s actually overall good for your customers. Your team direction needs to be fluid to be able to move around the obstacles that life throws at you.
Sometimes, it’s really hard to see the forest from the trees, and you need to be aware of the influence you have over others and the biases that you’re bringing to the table. To do that, you need to grow yourself, but you need to grow yourself outside of your core domain.
“If you want to grow a great team, you have constantly tune and iterate on the direction and build empathy and trust with the people you work with”
Waheed El Miladi talked about how he didn’t understand the problem he was trying to solve until he worked with product and until he worked with design, it was only then did he realize what he needed to do to build the right product for his customers.
Ultimately, your job as an engineer is not just to write code. It’s to help build a business. The best way that you can do that is to help your team build the right products.
If you want to grow a really great team, you have to be comfortable with constantly tuning and iterating on your direction. You have to build that empathy and trust with the people that you work with. When you do, you will build better products.
