The Exchanges

Q Maybe an interesting place to start would be, I I'm really interested in now that you've worked across so many different companies and so many different engineering organizations, How have you picked apart sort of global rules or frameworks that tend to work across engineering teams versus context, uh, specific ways of running a high functioning engineering org, if those two things are at all different?

A The number one way that I see new engineering leaders struggle when they come to a company is they just assume the context from their previous company applies as is. And if you've got new leaders who come in and really make a mess of things, It's always because they assume the previous context from their earlier company, maybe a much larger company like a Google that has, you know, tens of thousands of engineers, or maybe a much smaller company with like a startup with only 10. They just assume that context actually applies to their new environment. And what I try to do is just test the ideas and just see what the reaction is before I actually implement them, right? You know, when I was at Calm, Calm when I joined about 25 engineers, about a hundred when I left, And when I joined, we were going through a migration from our monolith to a number of services, and I canceled that migration. I was like, hey, this isn't working. When I came into Carta, going through a similar kind of migration, and you know, my first urge is like, hey, I should cancel this here too. It worked, it worked great at Calm, but instead of doing that, I just like tested that idea. I talked to different folks, particularly folks who thought it was an exceptionally good idea to be migrating out. You just tested the idea with them, like kind of mining for conflict. And so that's the biggest thing I'd say there…

AI assessment note: “Things are not the same across companies, but you can figure out pretty quickly”

Q Sort of as, as you were sharing some of these insights, I think you mentioned this idea of writing down engineering principles or the way that you think about these decisions. Can you talk a little bit more about the role of, of writing these things down?

A Every company you go to, engineers will say things like, uh, there's no product strategy. Like how come we don't even have a product strategy? And then you go to like, you know, product managers, they'll say things like there's no business strategy. Like how, how do we even function without a written business strategy? And then you go back to the engineers and they're like, there's not even a technology strategy written. Like what sort of company are we? And so there's this like pervasive belief that there's no strategy anywhere, but I've really come to believe that strategies everywhere. It's just like rarely written. Right. And so the, the challenge is that unwritten strategy can be really effective, but, but it's hard to use. It's hard to refine. Like you'll, you'll update the strategy, but people have different understandings about how it was updated. It's really hard to bring new hires on. So you have these senior leaders who come in and just assume their last company strategy is your strategy because you don't have your strategy written down anywhere. It's hard to explain confusing points where people get interpret different nuances differently, but it's, you can't improve the clarity of it because it's not written down anywhere. You have to go have like a bunch of one-on-one conversations or kind of do case law where it's kind of like, oh, well, in this case we did this,…

AI assessment note: “one of the biggest things we can do... is just committing to write it down”

Q What's the advice you tend to give to your friends who are CTOs who are coming to you and sort of saying exactly that?

A So I think there's two different problems. There's how do you improve execution? And then there's how do you address your CEO who's telling you to improve execution? I think these should be the same problem, but I find they're a little bit different. And so often with starting with the second one first, in terms of like engaging with the CEO who wants to drive like engineering velocity, I think you just have to start measuring something and giving it to them. And so often when people start measuring, there's always a concern, which is like, hey, this measurement is imperfect. This measurement is flawed. And that's true for all measurements. So let's talk about, like, story points in a sprint. And everyone you talk to about story points in a sprint is going to say, this is a terrible way to measure velocity. This is a waste of time. And that's true. But if your CEO disagrees with that, that's actually interesting, right? Because it means that they haven't built an intuition about how these things work. And so you can help them build an intuition by actually measuring story points, reporting to them, and then getting into the details and showing how it's not a very good, useful, good measure to actually show velocity. So I think people want metrics to show reality. They want to show the truth, but half of metrics is showing the truth. The other half is educating people to inform …

AI assessment note: “I think you just have to start measuring something and giving it to them.”

Q CEO of, I don't know, a 500 person software business came to you and said, I'm trying to build my own intuition around whether our CTO is good or great, you know, you might sort of explain sort of these three sub dimensions. What else might you tell them that would help them sort of figure out, uh, the performance of this person or sort of how to benchmark them?

A So good question. I, I mean, really where I would start would be talking to like the peers, the senior managers, and like the senior engineers separately. And I think you'll get very different signal from each of those groups. But stepping back to think about the CEO's problem, typically when a CEO of a 500 person company feels their CTO is, is struggling, they're probably running into like one of, one of two different things. Um, either the, the individual CTO is like causing friction with other people on the team. For, for some reason, like their peers, or two, just like the, the shipping velocity, like the way that they're able to ship work is just not at their expectations. And the first ones are pretty easy to debug just as like a general manager. Like there's nothing special there for the CTO versus the others. Shipping goes back to some of the, you know, the engineering velocity metrics we've talked about before, which is you can immediately tell shipping is not happening at the pace you expect, but you can't quite figure out why that's true until you dig deeper. And so my advice in that case would be like actually drilling in to get a sense of like why people think shipping is not going quickly and coming up with the conviction on, on why that is. And so as you dig into shipping at most startups, if you go to engineering, engineering is going to start with like one of t…

AI assessment note: “where I would start would be talking to like the peers, the senior managers”

Q When you're getting feedback on whatever you're presenting, do you generally find it's ideal to debate those points in the meeting, or is there sort of a range of situations? One is you just write down the feedback and loop back on it, and the other is you kind of could spend 20 or 30 minutes kind of debating or prosecuting it in real time.

A I think there's, like, two different types of, kind of, like, feedback. There's feedback that makes no sense, and then you need to, like, extract the kernel. In those cases, I think asking some questions, but then, like, taking some time to, like, think it through and come back. There's also feedback where, like, people do have shared context, they just disagree. And so I think that the second case is really valuable to spend time on, because then you have the context in the room, you just don't agree on, like, what you should do, and that's where talking through it live is incredibly valuable. But in cases where people are introducing new context and don't really have A lot of shared understanding. It's just like you don't actually have enough information across the group to make a good decision there. So I think those are kind of come back with the context and then try to have the decision. The latter, I do think talking things through live when people do have the shared like context, they just disagree is incredibly valuable and it's almost impossible to kind of like get to the end of these things on like a chat on Slack or something. You, you really do have to like talk it out live for at least important decisions.

AI assessment note: “I think that the second case is really valuable to spend time on”

Q Maybe a place we could end with is, where have you found the most inspiration on these topics? Are there specific people who have Shaped your worldviews and what are the specific things they imparted on you?

A I'm a big learner by doing sort of person. I think advice is always just so abstract and it's in the details that you really learn. So I'd say the biggest lessons for me are really from the places where I have done things poorly and that has forced me to kind of introspect a little bit and understand the gaps in, in my work. But as I've gotten further, um, I've also gotten better at being able to like learn the lessons from others who have made similar mistakes before me and learn. And so my, my network, um, I have a learning circle of kind of CTO and VP of engineering that meets every other week and kind of does like a shared learning format, which has been super, super valuable for me. But there's no, there's no one book. There's no one like blog or one person. To me, it's like consuming widely and comprehensively. Like I've read You know, many different management and, and engineering books. I, you know, read many blogs. I, you know, listen to, to many folks speak and it's kind of triangulating through and just building like a, an encyclopedic set of data points about how it's been addressed elsewhere. That for me, I've been able to kind of go forward, merge in my experience and kind of learn from, from that. And, you know, earlier you mentioned that like the, the details matter and, and, and that is like, unfortunately true. The details do matter. But for me, it's having co…

AI assessment note: “there's no one book. There's no one like blog or one person.”