Building engineering orgs and new products at Segment, Dropbox & Facebook - Tido Carriero

[00:00:00] I find that the best engineering managers and really leaders across the board are able to continually create clarity for the team in terms of if there is some ambiguity about, should we do a or B like having that deep business context to be steering toward the right outcomes, spending time, there is incredibly important.

I think the prototypical thing to do is maybe to spend time with the engineers, really understand all of the technical challenges, all of the architectural challenges. I'm not saying like, don't do that, but I don't think that's 95% of the job. I think that's maybe 50% of the job. And the other 50% of the job is really understanding what the business hopes to achieve out of this team.

And often it's actually not super clear. And so it's on the kind of edge manager to go drive that clarity.

[00:00:48] Welcome to in depth, a new show that surfaces tactical advice, bounders and startup leaders need to grow their teams. Their companies and themselves. I'm Brett Berson, a partner at first round, and we're a venture capital firm that helps startups, like notion, roadblocks, Uber, and square tackle company building firsts through over 400 hundred interviews on the review.

We've shared standout company, building advice. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast. In-depth you can listen into these deeper conversations every single week. Learn more and subscribe today@firstround.com

for today's episode of in-depth. I'm really excited to be joined by Cito Carrie arrow. Tito started his career in 2008 as an early member of the Facebook ads engineering team, and went on to become an engine manager on the pages team, a transition from IC to leadership that he talks about in this episode in 2012, he joined Dropbox where he built out the team responsible for the core product across all platforms, as well as the inj team that shipped the initial Dropbox for business product, eventually managing 170 engineers across four engineering groups.

Tito then joined segment as the VP of engineering in 2015 to build out the enterprise team in 2018, he moved up to the product development officer role, adding product design and security to his plate in 2020 Twilio acquired segment, giving him a new lens into how yet another company operates in today's episode, Tito and I get deep.

Into organizational design and engineering management. What I appreciate most is how these experiences building orgs, launching new ideas and scaling core products have given him a unique perspective. He has so many examples and actionable tips to share. We get started by talking about segments, single threaded leadership approach and the pros and cons of having all those functions roll up under him from how to troubleshoot when goals are missed.

To his black box analogy or assessing a team's performance. There are tons of tactics in here on how leaders can really dig into planning and execution. We also chat about the path to product market fit specifically for multiproduct strategies. Tito shares his advice for going from zero to one in a new product, including the simple milestone his teams have to hit before whole green light, a new project.

And he also gets into why he prefers iterative approaches over big bang launches and his thoughts on why Dropbox really struggled here. Finally, we also get into a great discussion on his advice for new engineering managers and new managers of managers, including why NG leaders should spend more time understanding business outcomes.

And the question he asks himself before every one-on-one with a new direct report from how to solve the typical, we're not moving fast enough conundrum to tips for building a really high trust environment. Tito shares the critical lessons he's picked up. Over his expansive career. I think they'll really be helpful for both early stage founders and engineering leaders, but also for managers looking to level up really in any function.

I hope you enjoy this episode. And now my conversation with Tito, thanks so much for joining us, Tito. We're so excited 

[00:04:30] to have you. Yeah, thanks for having me really excited to chat again with this community. One place 

[00:04:35] to start with in the theme of organizational design and team structure, one of the things that's been sort of interesting to look at your experience at segment, at least as I understand it is you start out more leading engineering and for the past five years really lead both.

Engineering product design security, all kinds of roles up to you, which I think for a later stage, company's fairly atypical. I think maybe what's more typical is you have a chief product officer, CTO, VPE, et cetera. And so there's more of division of responsibility that then reports into a CEO. So I thought it might be interesting just to talk about that journey for you and maybe some of the things you've learned just at the highest order bit about how you landed in that organizational design structure, at least from a leadership team perspective.

And maybe some of the pros and cons of setting things up that way. 

[00:05:24] You to share some sites. So, yeah, my background at segment, uh, joined as the VP of engineering about five years ago, really with the responsibility to build out the engineering team. And then about three years ago, started building a security function.

We hired an amazing leader named Colleen, who is our CSO. So she really built most of the security function and then product and design were transferred over to me. Those. Functions had already been built, but for a number of reasons, which I'll talk about it in a second, we were kind of looking for a single threaded leader to oversee both the engineering and product side.

And so, yeah, I think what it really comes down to is. There is this critical role of someone that needs to basically make these hard trade-offs. I mean, there's the constant tension that's just always going to be there about, are we going to pay down this technical debt, slow down, focus on reliability, focus on efficiency, or are we going to go build some new product features and focus on delighting our customers and go to market and just bringing the product?

Forward, you get the product voice in the room and the product voice wants to do the latter and you get the engineering leader in the room and probably they are deeply concerned about at least one or two architecture. Or tech debt or reliability issues. And so you really need a tie breaker. And I think the way I would think about this as who is going to be that tie breaker and at that tie breaker can be the CEO, especially if the CEO really wants to spend a lot of time thinking about these two areas and really in the weeds enough.

To help with that balance, or you can have it be someone else that is appointed by the CEO. And I think about three years ago, sort of the shift was we decided that I was really the right person who was kind of in the weeds enough on both some of the technical scaling challenges we were having and then also the desire to pull the product forward.

And so that was when we, when we made the shift was actually, my boss went on paternity leave and came back and said, ah, this seems to be going pretty well. Why don't you just. Stick with it. So that was how it happened. But I think it really had to do with like, was Peter my boss really going to be that tiebreaker?

Or was he going to let me do it? And as it happened, he had a bunch of passion areas and go to market that he wanted to go focus on. And so it really made a lot of sense. And actually, interestingly, so segment just got acquired by Twilio and. It's quite interesting to see their structure. Obviously Twilio at scale is also thinking about these problems.

And Twilio really has embraced a similar concept of these single threaded leaders in the sense that the whole R and D organization effectively has a number of different. Yeah. GMs which run both engineering and product. And I actually think it's for this very same reason, having these single threaded leaders that can make those difficult trade-offs what is best for the customer, because sometimes it's best to slow down and focus on reliability.

And sometimes it's best to speed up ahead and deliver a new feature. And so Twilio is really architectured this at scale, by having a number of GMs who are so empowered in the same way that I was three years ago to make these trade-offs. So I've been kind of interesting to see that. This is even sort of how it plays out at scale.

[00:08:36] modality? Yeah. Yeah. There's definitely pros and cons to every org structure. So the thing that becomes much harder and maybe I'll talk a little bit about Twilio scale, but I think the same things apply to smaller startups. So let's say you have a horizontal cross cutting project that you need.

Every business unit. To participate in. So I'll give you an example. There was a recent Schrems, two ruling, basically saying that if you have EU based customers, you cannot be having your data center in the U S which is true for many startups. You need to have an EU specific version of the infrastructure running that specific laws about making sure you don't transfer personal data from.

The EU to the U S anyway, a project like this calls for typically more of a multi-region type architecture, meaning that you have a region that is running in maybe your us west two or wherever you started your infrastructure. And then another region running in say Dublin. And so this is a very horizontal cross cutting initiative and this structure.

Makes it much more challenging to execute on these kinds of initiatives because you effectively need to get every single BU to pony up resources to actually go spend it on this particular problem. And actually our chief product officer at Twilio has a number of amazingly clever and intricate. Funding rules for how you incentivize be used to do this.

So it's not impossible to solve, but these cross cutting things like, Hey, we're going to make everything more reliable, or we're going to execute on a multi-region strategy to address that the Schrems two ruling, they just become more challenging in the structure, but then there's obviously lots of pros too.

You have these single-threaded leaders, which are really pushing each business line forward as. As quickly as possible. And I do think in many ways, those pros outweigh the cons, but it can be harder to really do those horizontal things like quality or how the system is deployed. What about, 

[00:10:30] or at least smaller company, like segment where in your case, you're running product and engineering, was it all benefit or there was even in that more simplistic structure, there was some trade off or downside to having one leader on both versus it report up into 

I think. The same problem does happen at smaller scale. And two, three years ago, we had similar challenges with GDPR where we needed to do deletion infrastructure across every single product line. When we would do a big quality push. Definitely more complication. Well, I guess maybe I should also say like, Underneath me, we have similar structures where there are product leads and NG leads who are tasked with vertical outcomes for the business.

So the same problem that I was just describing at Twilio has existed at segment for years as well. But I think you can chip away at some of the problems. You can have a horizontal infrastructure team. That's really just responsible for going around and thinking about quality all day, or thinking about cost efficiency or whatever the metric is.

You want to drive and you can kind of balance. Some of these trade offs by making sure that there are horizontal teams in addition to the vertical teams. But yeah, I think this concept of a vertical oriented org structure where the primary outcome is a business metric, like the growth of a product line has inherited downsides that if you want to get the five different.

Vertical outcome oriented teams to all execute on something more horizontal in nature. It just will be more challenging because there's tension against sort of the incentives of those leaders across the board at a smaller company like segment, it's obviously a lot less complex to. Go figure out how to execute on something like GDPR or friends too, because there's less people involved and it's easier to get everyone in a room.

And we don't have nearly the complexity of sort of funding structures to make these things possible that Twilio needs to think about. But I think the same inherent tension I was talking about still exists at a much smaller scale as 

[00:12:27] well. The comments you made a couple of minutes ago was some of the clever and incentive structure things.

That the chief product officer at Twilio has done to mitigate this to some extent. Can you talk a little bit about that in terms of this specific kind of. Issue around cross-functional or multi business unit horizontal work, some of those tactics that 

[00:12:47] potentially. Yeah, absolutely. So he instituted a rule that if someone shows up to your business unit with funding, you must accept that funding and you must.

Prioritize building the thing they're asking for. And so the way a project like data residency gets funded is, you know, you might spend like X million dollars to go fund this large infrastructure rewrite. You would hand that to an empowered GM who has the team to go execute on a plan. And so that Twilio there's a very strong data residency core team that is building a lot of the basic platform primitives for data residency, but they also have funding that they can take.

To the business unit leaders and they can say, Hey, here's four engineers worth of funding. We need you to either hire some new engineers and go prioritize this work. Or ideally just prioritize this work with existing engineers and then hire some new engineers to backfill them. But the idea is a business unit owner cannot say no.

So if the business unit owner is allowed to just be focused only on their own metric, Then you run into these issues where perhaps this thing will never get funded because you can only get like, you know, nine out of the 10 be used to agree on this. And that tends to be you isn't paying attention. And so the mechanics are really about you think about the business outcomes you want to achieve and the funding you're going to give to achieve that.

But then that funding does not always play out in. This particular org hires, the a hundred engineers that got funded. It actually may be that this particular org only hires 15 engineers to build the core pieces. And then that funding actually gets sprinkled across all of the different BTU's and the GM's have to play along with that funding.

And can't basically block the broader project. And so there's a bunch of those kinds of mechanics that exist, which really makes a lot of sense at this kind of scale because. You do need a clear path for a horizontal business, critical project, to be able to find the light of day, how do you then handle 

[00:14:50] the tension where the business unit owner, then doesn't hit whatever their north star metric is.

And they're like, well, yeah, cause I was working on this other thing. Do you think you run 

[00:14:59] into that? It's a good question. I mean, there's certainly is still tension. This idea of horizontal. Funding must be. You should be able to use your funding to Trump. Anything is a challenging thing when GM is, are really trying to chase metrics.

I'm not an expert at this, but the way it feels like it's played out is when someone shows up with funding, the expectation is not that the business unit will drop. Everything that they're currently doing. Typically the arrangement is, okay, we'll take this funding and we will go hire some new engineers that will achieve this goal.

And so we can commit to taking the funding now and building the team in Q1 and Q2. And then we will execute on this in Q3 and Q4. So these horizontal sort of demands, if we want to call them that are not time bound. In the drop, everything sense, but typically the way it happens is these horizontal things happen a little bit more slowly.

It's not a recipe to ask someone to drop everything and forget their typical goals that does happen on occasion, but that should happen very, very sparingly for true emergencies only. I'm sure that there will be moments where it's not working quite as perfectly as I described, but I do think some of this is just.

Tensions that leadership needs to be thinking about. And there are no creative processes that will let you just like do three times the amount of work at once. So there really are trade offs that leadership needs to think through at times, but by and large, I think this funding concept has been quite helpful for how business units should operate and still giving them quite a bit of autonomy to go run out there.

[00:16:35] we zoom out slightly, what would you say are Tito's rules for organizational design or Tito's philosophy? For org 

[00:16:45] design. I think it's really cool.  that every area has a clear north star that is clearly connected to the business. Success or business outcomes you're trying to achieve that typically leads to a slightly more vertical, heavy organization, meaning that most teams are a little bit more oriented toward clear business outcomes, whether it's like growth of a brand new product line where you're incubating it.

Or perhaps it's growth of top of the funnel for MQ L's that will turn into opportunities for the sales team, but just really having like a clear north star metric. And I would say probably 70, 80% of resource should go into these more vertical teams. I think often. You do want to leave 20, 30% of resources for these more horizontal teams, quality oriented teams, efficiency, oriented teams, security oriented teams, but even for those teams, then it's also super important to have a really clear metric for instance.

In segments passed a couple of years ago, we were having some gross margin challenges and we took one of these horizontal teams and got them insanely focused on moving our gross margin up. I think we achieved a gross margin improvement of something like 23 percentage points in six months. Our CFO who had just joined.

Uh, she said she had never seen anything. Like it, that's the power of a really strong business goal where there's just a really, really clear business outcome to achieve. I know it sounds pretty simple, but I think that's the important key here. And then maybe the one other thing I'd add is just making sure.

That the organizations are clearly non-overlapping as well because those overlaps cause a lot of tension for teams and a lot of consternation. And is that even necessarily turf wars, segments has really escaped being a political organization, which I'm really, really thankful for. But it's often just like ambiguity of like, Hey, this customer thing popped up and we're not sure if teammate or team B is even supposed to do it.

Obviously both teams would slightly prefer that they continue on their roadmap as planned. Like, what do we do that kind of clear delineation and sort of non-overlapping scope is the other important piece of things. And then maybe one more thought for smaller teams is you do have to be practical in terms of.

Having large enough engineering teams. So often if you have like a two person or three person mobile team, even if you do desire them to work on a couple of different vertical outcomes, like I'd probably keep that team together as a horizontal team, until you can at least seed vertical teams with two mobile engineers each.

Cause you don't want singletons working completely alone on their own technology platform that just leads to a suboptimal outcome. The 

[00:19:28] last couple of things, kind of on this organizational design theme, what do people screw up a lot in this area, other than doing the opposite of what you said you should do?

So like the, the opposite would be there. A lot of teams that don't have one north star area mission that they're focused on, but are there other traps that you see a lot of folks running 

[00:19:45] into? I don't know if I would quite categorize this as organizational design, but the thing that kind of jumps off the page to me is I see a lot of teams just very, very late to basic execution, accountability structures.

I think segment when I got there, it was one of those teams, but I think having really clear, you know, we're going to do a two week sprints or we're going to do a six week sprint in the earlier days. We really did two weeks. Sprints. Here are the committed goals we're going to actually go in and grade these as green, yellow, red.

For all of the yellow and red goals, we're gonna, you know, we're not gonna immediately go fire. Anyone who had yellow or red goals. That's okay. But we want to see sort of a thoughtful post-mortem of what happened here, what we're going to do differently when setting the goals, or maybe it's actually a red that, you know, we're proud of.

We realized two days into the. Two weeks sprint that this was actually a bad idea. And so we canceled it. We moved to a different goal that was more important, but really having teams like show that they're taking goals seriously, thinking critically about it, knowing that leadership is going to ask them about goals.

And obviously like I'm not in the different teams at the two week cadence anymore, but we do that now on a. Six week check-in and really quarterly cadence where we're really talking about, you know, performance against goals. And you know, it's not that everything always needs to be perfect all the time.

But what I really want to see from leaders is that they're thinking critically about things that didn't go well and they have a plan to. Make them go better. I think the worst thing I can see is people papering over what looks like bad performance, but they have a bunch of explanations about why it's not bad rather than just saying, yeah, this one actually was bad.

And we learned this and this, and we're going to do this differently, which is totally fine. I know that's not quite answering your org design question, but I just see it. Especially earlier stage companies. So much more of the problem has to do with just not doing some of these basic hygiene, fundamental things about like clearly setting goals.

And then checking in to see if we hit the goals. I think that I ended up creating, you know, wild amounts of clarity for the team about exactly what we're going to go do too. And sometimes it actually can be hard, especially for like a startup finding product market fit to actually have a year-long mission.

That makes a ton of sense. And so. That's okay. But I think you can create clarity about what is the most important thing right now from a goal setting, accountability oriented structure, but that's far and away. The thing I see as the most common trap is, especially when you move from founders, who obviously are just like incredibly bought into the company and incredibly driven and just.

You know, no things in and out to the first, you know, five or 10 employees, uh, there is a big shift that needs to happen, where you need to get some of these goal setting and accountability structures in place. And again, it's nothing super heavy, but I think having a sprint check-in meeting every two weeks where.

You set new goals for the following two weeks and you reflect on what happened over the last two weeks and an honest and open way can be really transformative for, for just like making sure that trains are running on time and that things are progressing as planned. The 

[00:22:45] thing that constantly comes up is when you see a lot of red or yellow, how do you diagnose whether it's an engineering performance or execution issue versus a fundamental estimation 

I think I'm often asking the. Angie manager, the tech lead the PM. Whoever's at the session. Walk me through what happened here. This goal didn't seem that ambitious to me. Am I missing something some kind of deep technical complexity beneath the surface? Or am I just often my assessment I'll often challenge a little bit with what the laws of physics thing seemed to me.

This feels like a pretty simple feature. We built a feature that was equally complex in half the time, two months ago, I'll do like a gentle push toward. What I think is going on here, but then really let the teams have autonomy and space to explain to me that I actually am wrong. And there's like this and this and this.

So I don't know that I have like a hard and fast rule here, but I'm really just trying to double click and get more color from the PM. From the tech lead, from the engine manager, whoever it is, that's accountable for the goal. And I'll actually try to have these meetings be small enough that we can freely talk about performance issues if there are performance issues, because actually, if you have the wrong size of room here, you kind of immediately shut off the ability to easily talk about performance issues.

And obviously you do want these things to be a pretty open dialogue, but yeah, I'll say that. With really good leaders that I trust a lot. They are really calling out their own performance issues pretty clearly. And for the ones where I'm concerned, what they're telling me is going well, doesn't always check out with sort of the black box assessment.

If I just think about this team as a black box, the resources we put in and what is coming out, either feedback from the go-to-market team feedback from customers directly, you know, Something is off. And then they're showing me that the black box is running really, really efficiently. Then I'm starting to worry a little bit more about the leader and I'm going to hop in over the next couple of weeks and come to my own conclusions.

[00:24:44] team in the black box analogy, and you're concerned that maybe there's something off. And you said you might dive in over a couple of weeks. What does that actually look like? What are you doing to get to conviction that some change needs to happen? Or maybe you go deeper over those few weeks and then you decide no, actually it is 

Think I'm just trying to understand what work is happening on the ground. If this is an engineering project, I'm trying to understand what PRS are getting written and or are they getting written and then it's not actually getting reviewed on time or actually maybe two out of the three people are.

Doing like circles around the third engineer. And it's really the third engineer. That's struggling a lot, but no one really wants to speak up. I think often looking at the source material itself in the case of engineering, it's probably PRS or architecture docs in the case of product is probably raw notes from customers on and kind of customer research and product design is probably the mocks themselves or the design review process, but really looking at the source material itself.

Cause often at these check-ins. You're talking about the goal sheet and whether it was green, yellow, or red, or if his OKR is, you know, one point our 0.8 or 0.3. So you're getting sort of a synthesis, but the DoubleClick is all about the source material itself is like, Hey, walk me through, what are the PRS that X produced?

What are the PRS that Y produced? I'm really just trying to understand. And I think when you do that sort of source material check where you're really looking at the root work, it will. Fly off the page in terms of what's happening here and you, it may be like actually an overwhelming amount of work that just ladders up to a less impressive goal.

But you're like, yes, yes. This makes sense. Like, I understand why we're doing this architecture work. You've clearly like, thought through this and we're just not representing this well at the goal stage, but I would say more often than not, it has a lot more to do with. A particular person might not be performing or like there's something broken about the way the team is working together.

That really does jump off the page. Once you take it down to the actual work that's getting done. When you think about that planning, 

[00:26:47] execution, reflection process in building software, are there other rituals or practices or pieces to that that you've found useful, or maybe other teams, as they're thinking about double checking, what they're doing, cleaning up, what they're doing, things that might be useful.

[00:27:04] I think the, the main thing that I really really recommend and here is creating a space where people can really talk about it and feel psychologically safe to talk about it. I think that's just so, so, so important. And it's like setting an example, like if you took some goals on and you have some red goals, like.

Don't hide them as green goals say that these goals are red and this and this and this happened, and here's how I'm changing things. But I think leading by example, to create this psychological safety is super important. And like, by the way, this psychological safety is way more important than just for talking about engineering commitment.

Say it's really important to have intellectual honesty as you're trying to find product market fit in a new area. Like I've been in many projects over the years where this. Sunk cost fallacy that you get into where you just keep investing in a direction. Cause there's kinda sorta okay. Feedback on it.

Today's episode is with Tido Carriero, an engineering leader who's built out teams at Facebook, Dropbox and Segment, where he is currently the Chief Product Officer. From his thoughts on organizational design and advice for newly minted engineering managers, to tactics for launching new ideas and scaling core products more successfully, Tido shares the key lessons he's picked up across his career.