EP.17 - Tido Carriero
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.
Brett Berson: [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 [email protected]
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
Tido Carriero: [00:04:30] to have you. Yeah, thanks for having me really excited to chat again with this community. One place
Brett Berson: [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.
Yeah.
Tido Carriero: [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.
Have you noticed specific
Brett Berson: [00:08:35] downsides in this
Tido Carriero: [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,
Brett Berson: [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
Tido Carriero: [00:10:42] the CEO.
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
Brett Berson: [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
Tido Carriero: [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
Brett Berson: [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
Tido Carriero: [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.
If
Brett Berson: [00:16:35] we zoom out slightly, what would you say are Tito's rules for organizational design or Tito's philosophy? For org
Tido Carriero: [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
Brett Berson: [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
Tido Carriero: [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
Brett Berson: [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
Tido Carriero: [00:22:56] issue?
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.
So let's say there's a
Brett Berson: [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
Tido Carriero: [00:25:00] perfectly fine.
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,
Brett Berson: [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.
Tido Carriero: [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.
And I think just like an environment where the leaders can come back to you and feel completely safe saying actually we're really not seeing. The kind of like pole we were hoping to see here and we really think we need to can this whole thing and go in a different direction. Like that's an amazing environment to create.
So I would just say, I don't know that I have like more specific tools, but I think as leaders, if you can create trust that someone comes into one of these things and say, Hey, we have failed over the last two weeks. That's super important. And I think these kind of sprint execution meetings that I'm talking about are the best way to start.
But what you'll end up finding is you can have these sort of introspective. Self-aware brutally honest conversations at a much more strategic level. If you can nail first the execution oriented ones. And that ends up just being so much better for three to five-year arc of the company, because you're not investing in large initiatives that just are going nowhere on a related note,
Brett Berson: [00:28:53] and it may be directly tied into what you're sharing.
I think something you often hear is, you know, you talk to a founder CEO of a 20 or 30 person company. One of the number one things that I think he or she often says is, Hey. I just feel like we're not moving fast enough. We're not shipping fast enough. We're not getting enough done. What advice would you give to that person?
Or where do you begin with something as squishy as overall? Output as
Tido Carriero: [00:29:17] you start to scale a team, things I'd really try to understand is how clear is the vision for what needs to get built. Maybe I'd even go so far as to say more often than not, not feeling like we're moving fast on things. Kind of boils down to the CEO or the founder, whoever it is having some mental model of what should be getting built that has not been communicated to the team properly, or the team is not sufficiently inspired on, or just somehow that context isn't flowing through.
And so I think. First and foremost, I'd, I'd really try to figure out how much clarity is there at the CEO level and how much of that has been communicated to the team. So I do think that sort of debugging often starts with, well, what are three things you want to get done in the next three months? And what do you think, like really strong progress on each of those three things looks like, okay.
So then you talk for 10 minutes about that. Okay. So the three things are a, B and C. Uh, who in the organization are like the right people to drive a, the right people to drive, be the right people to drive C. Do you feel like they have incredibly clear marching orders and the team to do it? And you're doing like a two week check in with them to sort of track progress against those goals?
I just think. Those muscles are so new, especially for a CEO of a 20 to 30 person company recently graduated from a talking with two other founders and three founding engineers, let's say, but that piece is often at the scale that the thing that's really missing is that creation of clarity about what these like really important goals are, why they matter and who is empowered to go solve them.
It's possible that all of that is super crisp and the leaders of a, B and C aren't the right leaders. So then you, you need to go find a new leader for C, but I think if everything just feels like it's moving too slowly, it's likely that that kind of Chris' vision is not making it to the broader team gears
Brett Berson: [00:31:11] a little bit.
Cause we're kind of talking about execution and building product. That'll be fun to talk. A little bit about path to product market fit, and maybe how that relates to building multiple products in a company. I think one of the things that, and I've talked with other folks that have joined us on the podcast before about this, that I'm endlessly fascinated with is how few true multi-product companies there are in technology and multi in the sense that like there are multiple in some ways adjacent or in other cases entirely unrelated.
Large business units that matter. And what often happens is most companies they're one thing tends to be there. One thing for a really long time, sometimes forever. I'm curious to talk a little bit about the zero to one stuff. Maybe a company goes zero to one in their first product, and then how that mechanism works over time.
And then what you've learned about it, given you've worked at. A bunch of really interesting companies that I think have done this to varying degrees
Tido Carriero: [00:32:10] of success. Yeah, absolutely. I was just talking with my sister who is a PM doing a zero to one project at a company she just joined and was trying to just codify some of the learnings over the years.
So I think one of the most important things. So when we're exploring some new Greenfield space, often the goal is. Okay. You have a quarter to go build some prototypes, build some mocks, do a bunch of research. And what I really want to see at the end of this quarter is three to five screenshots of customers you're talking with on slack, or you're allowed to give me video recordings or audio recordings with their permission.
What I want to see is I want to see insane levels of excitement. I want to see. Probably some kind of commitment to buy, or maybe not a commitment to buy that sometimes a little awkward, but a, Hey, this would save us three engineers worth of internal hours if this product existed. So you can at least start to see the value from a little bit more about financial lens metric, or like, I want to see a screenshot of them asking you if it's going to be ready next week.
Just anything that really demonstrates that. Excitement or pull. And I think this is a pretty simple milestone, but I found it to be a very effective one, which is like, Hey, we're not going to go nuts. Building a team of five, 10, 15 engineers until we really see this kind of crazy pole. And I think like often just the simple ask of like, Hey, show me.
Three customers or five customers that are really excited about it and show me the source material, like demonstrating that. They're really excited about it because often the classic trap with product market fit is everyone super polite about your idea? And when you do research, I was like, oh yeah, that, you know, that could be really interesting.
You know, this sort of a problem. Yeah, no, no, no, no, no. That doesn't count for anything. What I need to see is I need to see this person articulating back to you, the money you would save this company. Or, Hey, we need this by two weeks from now. And so we're looking for those high energy customer moments.
And I just think having like a really clear gate before you do large amounts of funding, that sort of show pretty viscerally, like there are customers super excited about this is a really, really healthy first step. Frankly, not everywhere I've worked has had that. I've seen projects where 30 40, 50 engineers got invested for six months, nine months, 12 months.
And it never really took off because like, we never really understood the problem well enough that a customer could recite it back to us with extreme amounts of excitement. That's a simple. Thing, but what you will often write one of these kinds of internal hype docs, where we really outlined the problem.
We think we're solving, outline the opportunity. You know, why segment is particularly well suited to solve this problem. And then there's just a section that I think is the most powerful section is often very visual, like lots of screenshots of us. Chatting with them on slack. Often with these early stage customers, we'll be talking directly sort of on slack with them and just show me those three to five high energy moments.
And then we can talk more about making a much more serious investment. Other things
Brett Berson: [00:35:08] you found, like when you diagnose, when something really worked, when you launched a second or third or fifth product and it got to scale and. Millions or tens of millions in ARR or what have you, other than this seems like a starting point.
So what has to happen organizationally?
Tido Carriero: [00:35:24] So you kind of get to this pitch doc moment and you gain a lot of buy-in and almost approval that this is going to happen. I think the next step organizationally is you really just need to take a small team. And it's often a pretty small team, three engineers, a PM, a designer, something like that.
And you just start setting these slightly too ambitious goals and saying it's okay, we don't quite hit this, but like doesn't it seem feasible that. Maybe three weeks from now, we could have this ready or, you know, I have a presentation with this customer that I'd really love to show them this in two weeks.
It's very incremental in nature almost. I think one of the failure modes is okay. You get through the pitch document moment and then, okay, we're going to go fund this team of 50 engineers, and now we're going to. Spend six to nine months to like go build out this team. And then we're going to take over the world in two years.
It's just like, I've never seen a project succeed like that. It's always very incremental in nature and it's like, okay, well what would be a really cool milestone three weeks from now? And then what would be a really cool milestone two more weeks from now and what would be another really cool milestone a month from now?
It really is much more of that kind of iterative process. And along the way, just make sure that you're really tracking toward that initial thesis that you had the pitch doc. And I think it really does look like a bunch of deals are flowing in within. Three six months often part of the PM's goal is actually closing the first million dollars of revenue.
I think that's really, really important that it's not just like the product exists and then sales is expected to figure out how to sell it. And it's like, no, that first million dollars of revenue, you basically need to be riding along in sales deals selling it. And yeah, maybe after a million, it. The onus starts to shift to sales, to grow the revenue line, but just really getting in there and incrementally, like winning it one deal at a time and figuring out there's these three gaps to this product.
And I would just say that the teams that have really succeeded. And when I, you know, when I look at our personas product, for instance, which is. Incredibly fast growing over a hundred percent type growth for several years, since it first launched three years ago in the mid double digits, millions of dollars that early team was just insanely focused on their customers.
They understood from that pitch doc exactly what needed to happen and what needed to get done. And then just made crazy incremental progress every month for now, probably the last. 36 months or so, and ensure enough that product we deeply think of as our act two that is really fueling the next several years of growth for the business.
Obviously our core product growing as well, and every personas deal also buys the core product. So they're kind of intertwined at the hip in some sense, but I think it's. It's that iterative motion that we're, you're just always raising the bar and you just have insanely high expectations for this small team that tends to be the project that works out.
And they like, okay, now we have this big funding moment and we're going to go spend a bunch of time hiring and like that kind of pause or. That internal focus just tends to disrupt almost every project and ceases the energy almost immediately as an observer.
Brett Berson: [00:38:30] When I have spent time looking at Dropbox, I feel like this is an area they've struggled with.
Maybe you disagree obviously from years ago, know the business really well. But kind of their consumer and enterprise business. And so it's, it's very different than day one, but mainly their one thing. Is there one thing, do you have a theory as to why that is, or maybe they actually did it really well?
And that's not the case.
Tido Carriero: [00:38:50] My theory of why this is, is some of the anti-patterns of stories I've been telling were stories from Dropbox days. It often was this mega boom kind of apple type, launch moment that we were trying to create, where we had really large teams of engineers sometimes working on.
Really abstract customer problems are ones where we hadn't gone to this level of detail. And I think trying to do that huge apple launch, I don't know how apple does it. It still boggles my mind and clearly they're doing pretty well. So I definitely won't knock their product development style, but I just don't think that works nearly as well for these kinds of staffs.
Software companies that can do this much more iterative development. And I would just say we spent a lot of time over the years. I was there trying to do these big bang launches and actually maybe the counterexample to that. I was one of the first proponents for Dropbox for business. We took a much more iterative approach, getting Dropbox for business off the ground for us, it was just centralized billing.
So that. We could get all of the people within a company that wanted to pay for Dropbox together on a single credit card. The simplest feature ever that was the foundation of Dropbox for teams. And then started just chipping away at the various administrative controls that people wanted SSO ability to run both personal and work Dropbox at once.
Then it was a bunch more advanced sharing features. And I haven't looked recently at Dropbox's revenue statements, but I do know that a meaningful percentage of Dropbox is revenue, is that Dropbox for business Dropbox for enterprise product line. And I think we got there because it was a much more iterative process where we didn't try to boil the ocean.
We just kept climbing over the next hill that was in front of us. Whereas I think some of the bigger bang bets to get into photos say we're just little bit more apple launchy and bigger funding moments where we, you know, we hadn't really. Gotten five customers completely out of their mind, excited to try this thing.
I think that's where Dropbox has fallen short in some of that.
Brett Berson: [00:40:45] So switching gears just a little bit, want to spend a little time talking about engineering management, just sort of broadly, which is something I know that you spent a ton of time thinking about and working on. And the place I wanted to start was if you had a friend and she said, Hey, I'm next week, I start as an engineering manager for the first time.
What advice would you give her to increase the odds that she is really successful in that role? Particularly you assuming that she is already of the mold of somebody who could thrive right. Gets energy from seeing other people be successful, et cetera.
Tido Carriero: [00:41:14] Yeah. I think the most important thing that I've seen corroborate toward success in NG managers is really.
Being able to understand what the business needs from this team, what their product partner needs from this engineering team. And just really diving deep into the business outcomes aspect of things. 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.
And I, I just think. Spending time there is incredibly 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 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 engine manager to go drive that clarity about the different options of what we could do and hopefully get to good clarity there.
So I do think it's that customer product, business focus, and really ramping up on that piece as seriously as you ramp up on the technology platform. So I think that's the first thing I would tell her. I think the other thing, and this is maybe the part that is less fun is just like you go from being the superstar.
I see. To kind of a bad manager and I never tell someone directly that that's, what's going to happen for them, but that's certainly what happened for me is, you know, I went from pretty good at engineering. I see work at Facebook to being like. Pretty mediocre manager. And I think that's a really tough thing cause it's like all of these high achievers are the folks that become managers and get that opportunity.
And then I think just having the patience to reset the skill set and yeah, you're now getting influenced through. Helping others grow, helping see others succeed. It's no longer about, can you crank out a thousand lines of code a day? It's like, can you really unblock your team and make sure that they're connected to the business outcomes that we're trying to achieve?
Make sure that they're feeling heard on the architecture issues or the engineering productivity frustrations that they're finding. Which is just such a different skillset than the actual, like achievement on the IC side. And it's, I just had this like very painful first couple of months as an engine manager where I was like, oh, I find I could probably just build more.
And I could probably build as much as like this, you know, whole team of two or three, you know, fairly junior engineers that I had. Inherited. And so my like instincts were pulling me toward that, which was really the wrong kind of instinctual poll. And so I just wish in the early days someone had like slapped me and told me that I really needed to, uh, to focus in this other area.
And just that it's going to take time. You're, you're starting a skill almost from scratch and it doesn't mean you're not going to be a great manager in a year, but it does mean that there's a lot of. Patience and humility that is required as you enter the role. And if you're trying to learn
Brett Berson: [00:44:17] that skill, are there ways to accelerate that learning or.
Practice.
Tido Carriero: [00:44:23] Right. So if you want to
Brett Berson: [00:44:25] be a concert pianist, you might practice scales on a daily basis to improve your skills. Is there corollaries or, or things that people can be doing as they transition into
Tido Carriero: [00:44:34] this role? I think one of the skills that almost every year. A fast growing startup needs that no one really wants to spend a ton of time on always is actually interviewing and recruiting even a high potential IC.
Who's not sure if they want to get into management, I'll often create a ramp into like, Hey, could you help rewrite this question that we asked that seems a little stale, or is not getting super thoughtful signal or, you know, Hey, can you. Do an extra cell for this high potential engineer that we really want to hire, or can you become an expert at sort of asking a new type of interview question?
Maybe there's an architecture interview. We want to add that we don't have yet. This is both always in demand at almost every company. Cause it is hard to like get people to sign up for recruiting activities. It's also one of the most important jobs. Once you actually become an engine manager, obviously to, to build the team.
It's like a great way to practice. Like, can I sell a team member on a vision? I often pointed to that just general area is basically like an unlimited set of tasks you can go take on and have impact. That'd be one area. You know, I do think there's a frustrating thing, which by the way, like, hi, The achieving ICS hate to hear, which is there is some scenarios that just take time in seat to get to.
And sometimes it takes like a year before you have your sort of first low performance management situation. I still see new things on the like, you know, employee relations side of HR every month in my career. It feels like there's something new I haven't seen before. And I've been doing this for a while now.
So there are aspects that take time in seat, and I know that's like, Quite frustrating to hear for a high achiever, but I do think there's ways to accelerate. I think like getting really involved in recruiting, sometimes getting really involved in mentorship. I think there's always opportunities I've found for really excited folks from the go-to-market org who want to learn to be a PM or want to transition to be a software engineer.
If the org can support that informal or more formal mentorship there. But yeah, I'd be kind of looking for those opportunities around the edges
Brett Berson: [00:46:38] manager or the manager of managers. Were there specific rituals or habits that you formed that you found were
Tido Carriero: [00:46:46] really bad? I'm not a huge rituals or habits person.
The mental model I've had when I have a new report is I really assume that I am starting with. Zero trust or I don't have trust yet. And then I really feel like it is my job to figure out how to go earn trust. So maybe this person has a particular challenge that I can get a quick win with them by helping them through.
Maybe this person has a particular like frustration with the way something has worked. Maybe this person lacks clarity on like what their team is supposed to be doing. And that's something I can help them through. But I think really just not assuming. On day one, that this person who now reports to you is super excited and has infinite trust in you.
I mean, this is particularly challenging when you inherit a new organization, but really building that first trust bridge that first moment where you need to give them some critical feedback. That's like a really, really critical conversation. But I do think of like the relationship much more as how much.
Of this person's trust. Have I earned? And if I'm not there yet, I really think it's my job to go figure out how to get there. I just ask myself that question a lot, and that's a, almost weekly ritual as I start a one-on-one is just thinking about where we're at there and what I can do to advance the ball.
You've touched
Brett Berson: [00:48:02] on this a little bit throughout the conversation, but how do you pragmatically think about building a high trust environment or if I were to watch you and shadow you for a year and listen to the way you're communicating or talking, what's sort of the recipe there. I think it's obviously like if something's not going well, screaming at people, probably not a way to sort of create psychological safety and, or a high trust environment, but is there some nuance or ways that you're behaving or communicating.
With that as something that's top of mind
Tido Carriero: [00:48:33] or really important. I mean, I do think it starts with being a really good listener. It's really often not fine. Like you've had a long day with a bunch of small fires and then someone you haven't talked to in awhile that you thought was super happy. Thinking about leaving or super frustrated with the way something is going.
And, you know, sometimes you're just like not really emotionally in a spot where you want to hear this, but I think it's just really, really important to put on your best listening ears, your best empathy face, and really listened to their concerns that has actually taken me a while to get there from one of my parents.
I won't say which one, I have a little bit of a. A temper that I have worked on over the last decade or so. And I would say it's gotten to a good spot. My old manager at Dropbox used to tell me I wore my heart on my sleeve and I needed to chill out a little bit sometimes, which I think was some of the best career advice I personally had gotten in a long time.
But I think I have to sort of fight against that moment. So I can really be an excellent listener in the moment because if you're not. That trust immediately dissipates. And then I think the other piece is just follow through and then try to turn it into pretty proactive action. That sounds simple, but you'd be surprised how many leaders out there are not doing those things.
And I think if you can do those things, you really set yourself apart. Do you think many leaders don't do those things? I think it's really sometimes. Hard to obviously prioritize this, right? So you have 10 minutes. The business is telling you to do maybe three, come from your boss, four coming from your own internal goal set of like what you think is important.
Three, come from your peers. And so it's just hard when this 11th thing comes in is maybe from like one of the most junior people in the organization to take that as seriously as everything else on your plate. No, I think it is probably the most important thing over the 10 other things, especially if it's a, you know, an urgent piece of feedback.
Um, but I think a lot of leaders just like, don't make that prioritization call and are like, okay, maybe we'll see if this sorts itself out. And then if not, I'll, I'll get to it in a couple of weeks after I finished these first two things for my boss. If one of your huge goals here is to have a really wonderful culture with a lot of psychological safety.
It's the wrong call, not to spend 30 minutes to go sort of the issue. People that
Brett Berson: [00:50:46] know me. One of my favorite topics is always all the things we know we should be doing, but we don't do. And why is that? You know, there's a zillion. We all know what we should be eating to be healthy. We all know that in your personal life.
And there's just so many of these things that we end up doing in recruiting. You know, you ask anybody how important is recruiting. Your visits is the most important thing. And then you say, well, let's walk through your calendar last week. And they spent 90 minutes in totality focused on recruiting, you know, like there's, there's just so many of these things that we intellectually understand.
Tido Carriero: [00:51:17] Yeah. Yeah, absolutely. And this is one of those things where it's like this incremental piece of feedback does not feel like it's the thing that's going to make or break your annual goals, but it's a really slippery slope if it's leading to not the kind of environment. That you want. It's just a very huge longterm detriment and that's really why it's so important to take these things seriously.
The
Brett Berson: [00:51:39] last thing I wanted to hit on was just any frameworks, approaches or lessons learned in the job of managing managers. Or transitioning from seven direct reports. And now you have two or three managers who have their own teams and any trip-ups or things that you tend to find are different about managers of managers versus managers of
Tido Carriero: [00:51:58] ICS.
So I would say going from a manager of ICS to manager managers, the good news is that is the last transition you will need to go through. And then it's all different scopes of managing managers from there. You know, I think the thing I would keep in mind is. The skills you're coaching for are just pretty different, right?
You're no longer coaching for excellence in icy work or excellence in IC architecture or, you know, whatever it is. Uh, you're now coaching for someone who's like a great hire, a great coach. You're making sure that their performance managing their team. Which is not always easy to self-diagnose that you have a performance issue.
Sometimes it takes a little nudge from above to say like, Hey, are you sure things are going okay here? So I would just like, keep in mind is like a pretty different skill set that you're starting to teach people and hold them accountable to. And it's maybe. A subtle shift, but I think it's an important one that you really are driving expectations around excellence of the team and happiness of the team and productivity of the team, as opposed to the thing you were coaching before, which is probably, are you building this PRD fast enough?
Or are you building this PR fast enough? Whatever the domain is, the work product now really is about hiring outcomes, team shipping outcomes, productivity outcomes, happiness outcomes. And so I would just. Switch your lens a little bit and make sure that you're really asking your team the right questions with that new lens.
Brett Berson: [00:53:21] And to wrap up, I want to spend just a few minutes talking about maybe some of the lessons or insights you've gained. From some of the leaders that you've worked most closely with. And, you know, when you think back over the past 10 years, that people that have had the most outsized impact or the people that have given you the most of those light bulbs, step function, growth spurts in your own career.
Maybe the few people that come to mind and what did they do? One thing, you know, you just mentioned was somebody gave you feedback about wearing your heart on your sleeve and how that was an eye opener for you. Are there other sort of moments that sort of come to mind with the folks that you've worked
Tido Carriero: [00:53:56] most closely with?
Yeah. So I have this mental model that I stole, but I call it stealing superpowers. And this was in a biz ops training that Dropbox. He used to run for new Dropbox employees. And I just have found this to be such a powerful concept over the years. I just think everyone around us and it's not just your managers.
It's like your peers is often your direct reports. They all have super powers. And I think it's your job to figure out what those superpowers are and then how you can steal those superpowers. But I would say I learned a ton about. Recruiting for my boss. Decia at Dropbox. Like that was really the superpower that I wanted to steal from him.
My current boss, Peter, I've learned a ton about sort of like broader business thinking and how the functions need to interact with each other. I'll actually some of the stuff I was talking about in terms of thinking of things as a black box is like, Yeah. He gave me some advice at one point, he's like, Hey, you're really like looking at the team.
And you're kind of explaining all of the inner workings and why the team is not doing as well. You should really zoom out and look at this as like a black box. Like, what are the resources you're putting in? What are the outputs? Is that good or bad? And that view is like a even more helpful view sometimes on performance that knowing all of the inner workings of why something's not going quite as well as it should be.
Those are some very random examples, but I'll often say like, oh wow, this person really has this. Skill of giving a public presentation or the skill of storytelling in this way. I want to go get next to them and work with them on a project where I can actually see that happening up close and personal and maybe collaborate.
I think that's really served me well over the years. It's like not having this. Ideal manager. Who's going to coach you on all of the things in the universe that you could learn, but rather just every person has a strength or two, I think, every six months or so. I'm thinking about like, who's around me.
What are my opportunities to learn a ton from them? And it doesn't need to be on all dimensions and they don't need to be my manager. But I, I do think like just finding those opportunities and then learning that skill and then moving on to the next skill has been a lot of how I've thought about this general concept over the years.
And I think it served
Brett Berson: [00:56:01] me well, thread. I wanted to pick up there just cause I've heard from multiple people that Aditya is just. Was truly sensational at recruiting. And I know we haven't really gotten into recruiting and maybe we could pick up that topic in a future conversation, but are there a couple key takeaways, the trailer version of the full length movie that you've learned from him about recruiting that maybe other people might find
Tido Carriero: [00:56:22] helpful?
Yeah, I think he is just incredibly. Focus on the bigger vision and how this thing is this incredible opportunity into the future. If you really want to hire the very best talent in the valley or in the world, a great engineer could go to literally 50 different companies, like probably without lifting a finger.
If they applied on one of these services that lets you apply to a bunch of companies at once, they really have the pick of almost anything. And so. How do you really think through what is that incredible differentiator that, you know, your team offers your company offers? How do you connect to what they're really looking for?
I think it ditches just like really a master at that. And even today I see like hiring managers, especially newer ones who just like, are not thinking super critically about why this particular role is an incredible opportunity. And if they were across the table from an incredible engineer that they wanted to hire.
What they would tell that engineer pre-selling after the fact selling, but just really having that kind of value prop for the candidates ironed out. And I mean, I think it did. Yeah. Also had magic, which I'm still learning to replicate are still trying to figure it out in terms of really the personable sort of selling aspects.
But I think just, yeah, if there was one thing I would say is really what makes this role, this company, this opportunity incredibly unique, and you spend a lot of time. Thinking about that deeply and then evangelizing it for all of us hiring managers. We learned from him. Wonderful. Well,
Brett Berson: [00:57:53] great place to end.
Thank you so much for this conversation.
Tido Carriero: [00:57:56] It was a blast. It was great chatting with you. Thank you for having me. Yeah.