Scaling yourself ‘down’ as an engineering leader w/ James Everingham #155

Here's the truth. Hiring remote engineers doesn't have to be expensive and time consuming. Our friends at Revello can help you find and hire top engineers based in Latin America in a matter of days. Just tell them what skills and experience you're looking for. They'll come through their network of over 400,000 pre-vetted engineers and give you a short list of curated candidates that meet your specific hiring requirements. You interview

and hire on your terms and only pay for as long as you keep the engineer. To learn more, visit revello.com forward slash ELC today and save $2,500 off your first hire. So, like, we had a great story in our head of like, if we can simply make money flow or value flow fast and free frictionlessly around the world, like a lot of goods going to happen, but then, you know, that's the ending. That's the happy ending. Like, what are

the chapters that we're going to write in between to get there? The first one was, well, we're going to build this new infrastructure. Let's start getting it out there and getting it quickened in an area where it's already accepted. And that's what we did. You know, that was the first one and we worked backwards from that. They're trying to make the story happen. They're not trying to make a list of tasks happen. And I think that's a really important distinction.

Hello and welcome to the Engineering Leadership Podcast brought to you by ELC, the Engineering Leadership Community. I'm Jerry Lee, founder of ELC, and I'm Patrick Gallagher and we're your host. Our show shares the most critical perspectives, habits and examples of great software engineering leaders to help evolve leadership in the tech industry. When you go from leading an engineering work of 1400 people to 12, how do your leadership

principles need to change? How do you have to operate differently as a leader? How do you actually scale yourself down? In this episode, James Eberingham, VP of engineering at Lightsbar, returns to the show to share his best tools for scaling yourself down, not up as an engineering leader. And in this conversation, we cover how scaling down impacts your risk tolerance. We talk about leveraging the Socratic method to scale your leadership

and decision making across all stages of the company. We talk about creating narratives as a product and engineering goal setting tool. This one rock my world. We also talk about how to balance the right amount of process. You know, the existential question whenever you jump into a startup, we also get into how to change your communication for smaller

organizations and more. Let me introduce you to James James. Every ham is co founder and VP of engineering at Lightsbarck where they're building core infrastructure on the lightning

network. Previously, he was VP of engineering for no V at meta and co creator of DM. He also served as head of engineering at Instagram, vice president of engineering for Yahoo Media properties, CTO and founding team member of live ops, senior director of engineering at Tell me acquired by Microsoft and senior director of engineering at Netscape Communications, or he spearheaded the flagship Netscape browser. And before joining Netscape, James held

engineering and management positions at Oracle and Borland International. This is James turning to the show. He's a long time friend of ELC enjoy our conversation with James every ham. Welcome James to the show. It's going to be reconnected. I think there's been some fun things to note. You've helped kick off ELC conferences in the past are first in person one in 2019 and our first virtual one the year after. So this is a fun special

moment. It's sort of a reconnecting and a catch up in a lot of ways. I think to introduce and frame our conversation, we spent a lot of time talking to folks about, you know, scaling up and building the organization, building their leadership capacity. But we are hardly ever talk about the inverse of that and the shift down from my understanding that seems to be the headline for one of the things that you've experienced in the last year or

so let's catch up. So talk to us about that shift and where you're at right now. What has that been like? I've done this a few times in my career. So I wasn't completely unprepared for it. But I do think it's important when you're going from a large environment to a small environment, technology that they're very different skills. I write a lot of bikes. So I use a lot of biking analogies and it's like ascending skills versus descending skills.

Going up a mountain is completely different than going down. So you can't rely on what gets you up there on getting you down and it's completely different muscles is completely different set of skills. And I think that this is super like relevant to the work environment when you're going from a large company to a startup or a smaller company is you have

to be conscious about what those changes are. And it's very different muscles. And if you get hung up on what you were doing in the larger environment, it cannot turn out well in the smaller environments or not be useful. And can you share like how different are we talking here? Like for what you're doing it like the context in which you're building at light spark and then the context you were operating before. How different are we

talking about? I think they're almost complete opposite. They're not slight changes. You have to go in a completely different direction back at meta when I was working there. It was a very large team. I was running. It was over a thousand people. Then you go down to a few people. But the environment is really different. What you did in the large company, it's not the same in a small company at all. In a large company, you likely have product

market fit. You have an established customer base and you have to move very carefully and thoughtfully in order not to disrupt your business. In a small company or a startup, you don't have that. You have to move quickly and you have to make crazy decisions and do things wrong when you're trained to do things right. Moving to doing things wrong is like a hard mental shift to make. And then also in a large company, you have a lot of resources.

You're relying on so many things that are available to you. In a small company, you don't have those. You can't expect things to be done for you. You have to go and do them yourself. And managers tend to rely on process a lot. Here's a problem. How we can fix it with process? That's also something that doesn't serve well in a small company. You have to make conscious decisions to counteract this. What has that been like for you going from

meta to light spark? How did you approach being able to make that mental shift as an engineering leader there? Sure. Well, it certainly wasn't natural at first. It's kind of uncomfortable whenever you have years and years of working on doing things well and making sure they're crafted well and thought through to going down to this environment where you need to do the opposite thing. And the way that I do it is I always ask myself in my mind, what am

I optimizing for? And so like if you can figure out what you're optimizing for, you can anchor a lot of your actions on that. So in a large company, you're optimizing for stability, keeping your customers happy, reliability. But in a small company, you have to realize that you're optimizing for innovation and product market fit. And if you deconstruct that in your mind, you come to a very different conclusion than you would in a large company. And so that's

where I sort of tee it off of. Did you ever find yourself maybe stuck in the previous pattern of thinking and had to like spend extra attention to sort of get over that? Yeah, I mean, I'm constantly even now still catching myself when I see a problem. Like I'm like, okay, what process can we go and it's and I have to keep reminding myself, it's a struggle.

I'd like to say that there's an instant easy fix for this. But like I think the best thing is to just keep reminding yourself that like what are better ways to do it, keep questioning your underlying assumptions, get your team to help you, like call you out. Every time I ask my team, I tell them, I'm like, look, this is going to happen because this is the muscles that I built. So you're going to have to like call me out when I do

this. And so I get the help from my team as well. I think it's so powerful that you have extended the invitation to your team to call you out in those moments. I think the the ability and the awareness that you have to share like here are the sort of default patterns that I have. Like please help me transcend those like I think that's a really powerful practice. It's very helpful and it's it's very helpful when everyone feels

empowered too. And it just creates a better culture. Going back to what you mentioned about the differences in resources and the necessity to do things yourself, going from you know, 1000 plus people to then operating in a different leaner context from what you shared. Like you have to do a lot more things yourself. How did you make that switch to be able to and I guess what areas did you find were surprising that you were getting your

hands into when you go down to a non hierarchical environment. It's not really clear first where decisions are going to be made. In a large organization, you can kind of look at it and understand how decisions are made and where they're going to be made. You don't have that luxury and a small company. So the first thing you have to do is just start making decisions and you can't ask permission. You just have to sort of do it. It's a luxury

because like you also don't need the coordination, right? You know, you can you can cut all the overhead in that. You can go straight to making decisions. So I found myself, you know, I would still get caught up in and I think, you know, I work for my boss now is the same boss I had it met us. So that even makes it harder because like, how do I pull myself out of the pattern? I was in a big company because I'm working for the same person and now

I'm going to change behavior. But I just started making decisions that I felt that he would make in the company and you know, he appreciated it. And then he sort of kept that feedback loop and you know, empowered me more to go do things. But I started building process and things for even like HR and areas outside of engineering that I would have done in the large company down to how the physical space looks. You know, all these different things

that you wouldn't do in in the large company. There's one story that you have about decision making that I think is is it really exemplifies the power of speed and decision making. The one about making the senior higher. Can you share more about like that story and how that felt different in the moment from operating in the previous larger context? Yeah, sure. Absolutely. So when you're making a senior higher in a really large company,

there's a process involved, right? I mean, it's it's complicated and it can take a long time. It takes a lot of approval mechanisms. You have to go through a lot of conversations. You have to get a lot of buy in from other senior executives across the company. I think that David and I were just casually talking and we're like, Hey, you know, where I would have just kicked off the process in a big company. Like, what do you think about making

this higher? And David cut right to the chase and said, let's just do it. And I'm like, OK. And you know, and then we both had a moment of like joy where David reminded me, like, you know, that would have taken like a year or so in the large company. And we did that in like under 10 minutes. And I'm like, yeah, that's great. You know, let's enjoy that in a small company. That's what allows you to move faster. And you know, in

a small company, that's one of the advantages is your speed. I love the fact that you recognize that moment to be a look because it also almost seems like you could be like, yes, we are making decisions faster. And this is that moment. And we are here and we are doing it. And it's great. I think the power of that recognition then is a pretty cool conscious thing to do. Yeah, it definitely it felt great. And we've had many more moments

like that since and looking forward to many more. So outside of decision making, one of the things that I think is interesting is some of the things that you've mentioned about what you optimize for with your communication and your communication patterns within your team are different, being focusing on getting inner team communication versus broadcast

and aligning the entire organization. I was wondering if you talk a little bit about how that's different, large to small and share a little bit more about what that might look like at light spark when you're making that shift down in leadership. Yeah, sure. Like well, the first thing to acknowledge, I think communication in a large organization is

very complicated. You've got a lot of layers. You have different teams. You have to put a lot of thought into how you message that you have to acknowledge that the equivalent of telephone game happens so that like if you tell something that gets passed down, there's a pretty good chance that what you said is not going to be what makes it down to the lowest levels. So you have to be very repetitive. You know, you have to keep focusing and communicating

to the company and repeating and repeating and repeating. And that sort of drills the message down. And then on top of that, like, you know, you have to make sure that your message is crafted to land right with each group because it's a complicated machine. And there's a lot of information happening. People are probably an information overload. Now, a small company doesn't have any of that. Like, you know, this one team, likely the

same messaging works for the entire company. And you're not really broadcasting as much as you are trying to facilitate conversations. So what you're trying to do is get people talking with each other more than talk at them, especially when you're optimizing for innovation. You're trying to do things and invent things. You have no idea what you really want. You

just know what you're trying to accomplish. You want to get everyone talking. I think that the tools that you use for facilitating communication are very different than the ones that you use for broadcasting communication in a large company. Are there certain structures that you've introduced with the team or like what have been some of those conversations that have existed? Who are the people that you're trying to get together to have the higher fidelity conversation together?

One is, I think, the whole company tries to connect people cross functionally a lot more than you would see in a large company. So we end up having groups of people that are in all different functions in conversations, right? And I think what we do is we have a lot of more problems that need to be solved than rather having existing solutions to be able to recommend. So we find ourselves bringing problems to the company more than we have

solutions to get them engaged in solving them. And I think this is super important in building your culture early because you want your team to be invested into the solutions. And this gives an opportunity to build those for later, but like have everyone invested in the thought

process of bringing them. So like I think that I would say that the main difference is the cross functionality, the types of things that we bring to the company, the level of involvement that we're trying to get from people in these conversations to get them to participate and not just listen. One of my favorite quotes is authorship, breed

ownership. And so the practice that you're introducing there bringing more problems and solutions like that resonates so much because I think that truly shifts the mindset for how people within the organization operates. I think that's so powerful. Yeah. And to build

on to that, you know, I'm a big fan of the Socratic approach. I think one of the key notes I did got into that is like, even with yourself, if you're trying to transfer an idea, if you do that with the right questions to get the person to come up with the same idea that you have, you get the benefit of maybe being wrong and then coming up with a better idea. But if they think through it, there is a more ownership in there because

they've come to the solution themselves and their minds through the questioning. And that also helps foster ownership. I want to talk about the Socratic questioning method a little bit more specifically, wondering if there's like maybe a context or an example recently where where that's unlocked a new solution because the power of questions for as a leader has come up a couple times. But what's so hard is to understand where does this context

come up and where does it unlock these powerful opportunities? Because I think it's a really hard practice and have it to build as a leader. We're supposed to have the answers or that's sort of the maybe contradictory perspective for what people should have. Tell us more about how this is like this. Cratic questioning has shown up. Yeah, sure. Well, I think the first misconception is that as a manager, a leader, you're expected to have all the answers. A lot of senior and junior

managers have that. And I think it's it's not right. I think that like the best managers are the ones that basically are out to get the best answer and acknowledge that the way to find that is to enable group think. So I think like, you know, any time that I have a preconceived idea, I try my best to present it to the team as what solution I'm trying to solve first and ask how they might solve it. Recent examples without going into too many specifics are probably like

the way that we deal with customers. Like, you know, hey, we have customers coming in and this is how they interact with us. This is what we're trying to achieve. What do you recommend or how do you want to handle it? And then, you know, if you start there and then ask the right questions and make it a game, like, I'm going to thoughtfully not try to say anything, but, you know, present

everything via a question. Usually you can get pretty good results. And often I find that the ideas are way better than what my original was or they're like dramatically improved or I was completely wrong. So I mean, that's sort of the general process that I go through. Fantastic. Diving in deeper to secratic questioning. And if this is a practice that you're going to employ, are there certain

questions that you found to be helpful to kind of open up that dialogue? Like, when you're going to begin this, this dialogue with a group or with an individual, like, what are some of the questions that you rely on to move through this and help unlock these ideas? Well, I think that the first thing is not the question, but how you frame the problem. Whenever you're about to engage your team is to focus them on what outcome you're hoping to achieve. And so being really clear about what

you want to happen and not what your opinions are on how it happens, I think is important. So I kick one off usually, like, saying, Hey, here's where we need, here's where we need to get to, you know, whatever the topic is. This is what we want. Winning, this is what winning looks like. And open up the floor for discussion on how we can get there. And depending on, you know, if it's technical or not, you're going to start with a whole different set of questions, you know, like,

what stack do we want to use for this? Well, why? Why are you making that choice? You think it's more secure? Why do you think that? You know, like, just just keep going in the form of engaging in conversation and in questions. And to you get to the end result that you were hoping for.

This brings up when we're talking about questions and the types of questions that you introduce, one of the practices that you've shared that I find really interesting is the one about anchoring decision making principles, like creating your anchoring decision making principles. And some of the questions that you use to not just make a decision, but to rather generate

the principles behind a decision. And so I was wondering, can you can you share a little bit more about that and how that plays a role in some of these types of conversations? Yeah, absolutely. And in fact, I think this is probably one of the most important things to get right. And it's the one thing that I think operates almost identically in a small company as in a large company. This is the one thing I haven't changed. And it's a skill that like will carry

all the way through scaling up to a large team. And basically, the muscle is like you want to make sure decisions are well made. And a well made decision, you should be able to describe very well. Like you should be able to explain why the decision was made and how. And I think the way to do that is with principle principles are, you know, small algorithms that sort of control their guide, how things happen. But when you define them, there are also things that like an engineer can use to

or anyone in the company can use to guide or defend their actions. And they're completely scalable so we're systemizing things like and I can give you an example of one of my favorite ones. Okay, like when we came down to the the beginning of this company, we're like, how are we going to staff it? You know, and it's like, okay, well, let's start with this one simple principle. If something's important, put somebody in charge of it. Okay, so now if you practically translate that, you know,

you sort of come up with an architectural diagram of what you want to build. Here's some big meaningful areas. Those are important. Let's hire people to come in and own those and that's their area. And so like that's one way of doing it. So that's a principle. Other wins are things like winning should

be measurable or goals should be measurable. And you know, that suggests that like you shouldn't take on things that you can't measure or we're going to solve customer problems before business problems is one I like, you know, it's like, especially in a startup, you sort of can get stuck in the well, how will we make money? And while that's important, that also can sort of defocus you from building customer value. Revenue is a company problem, solving a company problem, but it's not a customer

problem. And if you don't focus on solving customer problems, especially early on, it may not be a very long run for you. I want to dive into the a little bit more into that because I think that the mindset you have as as co founder or like key executive business leader and somebody maybe is coming at a different level, like may approach those with different understandings of how important approaching those principles are. How does you develop the customer before business problem

principle? And how is that driven decisions for certain things that you focus on or don't focus on? I think that principle also can be equally dangerous in a large company and that's sort of where I learned this was in a large company. When I was at Instagram, Kevin Sistrom, who was the head of product and you know, CEO of the company at the time, he would always call us out on this. And like he was very, very focused on building the best customer experience and it showed in the product.

And anytime and during a product review, if someone brought something up that the only reason for it was to make more money, he would call us out. He was like, look, you know, you're solving a company problem, not a customer problem. And he had a deep rooted belief that like if we went down that road, it would it would get out of control and pretty soon you have a product that was built to optimize for revenue and not for a great customer experience and you'll lose your customers.

This happened also back in my career, back at Yahoo, I was running engineering for their homepage and they got really good at monetizing the homepage. Revenue was king and you needed to keep trying to get more revenue. I mean, companies have a responsibility to make revenue and we learned that like looking over time, we were getting increasingly better at monetizing fewer and fewer people. So like the fact that we were putting more ads was making more money, but we were also losing people

because we were making more ads. So you have to be conscious of those two things. And that suggests that you have to make hard decisions and prioritize. In a startup, I think it's super

important that you're building the right thing for your customers at first. Both those examples are iconic because I think about Yahoo, like the Yahoo homepage to me, like there's sort of this image burnt in my head of like landing on that for like a long, long time and seeing it evolve over time and then plus you know, the Instagram example takes up a lot of people's experience for sure. I can also give you an example of how like these principles equally work in a large company,

you know, in a different way. The other thing that I think super valuable about when you when you focus on principle decision making and you know, once again, this is systemizing decisions, you're giving people the tools and the algorithms on how to make decisions. These are basically frameworks. They're simple frameworks that if you get your team to agree on, suddenly you gain a lot of transparency because there's no mystery behind how a decision was made. They can

simply look at the principles and figure it out themselves. So that's really important and things get a lot less political because if they don't know why you're disagreeing with them or why you're not supporting their decision without principles, they can take it personally. And one example of this was also Instagram. We had some remote offices and so we were like, how do we build teams in these remote offices? And of course, my first instinct was, well, let's figure out

what the principles are that would enable us to build a team in a different location. So we came up with, look, you know, career growth is important. So there should be director level scope and whatever we put there. There was other Facebook resources there. So they should have local adjacencies with the resources in Facebook. They should have an adjacency with a talent pool that that area has, you know, there's like a lot of machine learning in New York because of the finance and all of that.

So we had a New York office and maybe that's what we could use. We came up with these principles and then like one manager had come to me and he wanted to build the mobile friend and the web friend and for Instagram. And he's like, I want to spin up a team. They could have putting it in New York. And I was like, okay, well, let's go over the principles and like, how big will the team get? And he was like, it's never going to get above about 20 people. Like I can do this pretty

efficiently. And I was like, all right, there's a lot of front end talent in New York. And he was like, well, no, not particularly. And by the time we got through the conversation, I like audited the principles with him. I'm like, so what do you think we should do now that we've, it was like, yeah, you're right. We probably shouldn't do that. Like, okay, great. So if I would have just said without that, no, you can't do that. He would have been like,

he's not enabling me. He's not allowing me to go do this. He has something against me. And you just sort of remove the politics. You get to transparency and you give people the tools to be able to go make these decisions. It's super scalable. It's something you can do in a startup. You should start doing it on day one. It's a muscle that will like completely carry you all the way through small

to incredibly large. Seeing the layering of two approaches we've talked about here so far, both the decision making and like how like the secratic questioning and the principle-based decisions, how they layer together in a way that creates more empowered decision. I think is really interesting to see how those sort of combined for a great outcome. Yeah. And even with those principles, like I didn't come up with those principles, my team came up with those principles. They were better

than ones I would have done in a vacuum by myself. With these being essential to any team, large small, especially small in starting out and how they can scale up, what does like that day one creation look like? Like, how do you create some of these these early decision making principles with your team? Like, what's the shift that needs to happen or what's the conversation that needs to

happen? Either one off or ongoing to help generate these and anchor these? Yeah. I don't think that there's like a starting point that is obvious, but I would say that you need early on to start evangelizing what they are and how they're used. And then anytime a decision comes up, you have to ask yourself, how am I going to make this decision? How do I show my work to the company? How do I explain how this decision is going to be made? Is this a decision that's going to happen again?

Or is this a one off? What's the frequency of this type of decision? And then, you know, market as a candidate for principle thinking? Now, I do think that there are some things that are just going to happen. Like, hiring, you're going to be staffing what's your staffing plan going to be with type of people? Are you going to be hiring? You know, there are some things that you can like start thinking about before you get in that are you're probably going to want to have

principle thinking around. As a US company, hiring remote engineers can be time consuming, expensive, and frustrating. You could hire freelancers, but you don't know how much they'll focus on your business. Out sourcing to dev shops, risks, control over who works on your projects, and expensive long-term contracts. Or you could look overseas, but working across lots of time

zones can really slow things down. Enter Revello, your gateway to a talent network of over 400,000 pre-vetted engineers in Latin America who are proficient in English, work in your time zone, and are dedicated exclusively to your business. Revello simplifies the hiring process, enables quick payroll in local currencies, and provides expert staffing support. There are no big up front contracts. You only pay for each month that you decide to keep

your developers employed. With Revello, you're in complete control. You get to decide who to hire, what to offer, and you get to decide how long to keep them on your team. To learn more, visit Revello.com forward slash ELC today and save $2,500 off your first hire. Another area I wanted to explore here, and you'd brought this up as a possible trap for folks

making that shift down, is this element of process. This is an area that you're talking about, like some of the self-talk you have to remind yourself is what to optimize for and getting your team to help provide a check and balance there. How do you balance or think about where to introduce process? You shouldn't be afraid of process, and I think that it's a mistake. I've even done this in the past myself, is one of my startups. I'm so tired of corporate process. I'm not going to do

any. That didn't end well. Eventually, if you're going to be a successful company, and I hope you're planning on being one, if you're starting a company, you're going to need some coordination. The key is you have to know where to put it and how much. The things that probably are candidates for process are not that different than what I said for the principles, is do you need to solve a problem that's a one-off or is it something that you're going to see happen again? If it's going to

be something that's going to happen frequently, what is the frequency? Then the next would be, is it something complicated or simple? Like a simple thing, likely your team will just handle organically. You want to be really thoughtful on those things. The final question is how does the team feel about it? You don't want to push this on your team if they're not buying into it, and I think that's important for your culture, is to not push process on your team that they don't

want. I don't think if you can explain the value of it to your team even early on, you may want to reconsider doing it. Whenever I try to suggest process that our size, one of the advantages that I have is I've been in a large company and a small company, so I can kind of see where it's going to go and what you're going to need in a couple of years. If you can explain this is where

we need to end up, this is what it's going to look like. Do you agree? Then ask the question, do you think you want to do that when you're large and try to build that muscle, or should we try to start doing that now and grow it over time? I think that there are thoughtful ways of putting in process. There's two types of people that I'm sort of afraid of bringing into a startup environment, and one are people that just love process, and then the other one is people who hate

process. I like people with a healthy or a spectra process, and I think that there's somewhere in the middle that you need to be. Both of them have certain perspectives and would likely try to over optimize for those different areas. For somebody who say loves process or leans towards that on that spectrum, before you introduce or recreate a process, what should you do? Are there certain questions or principles that you can introduce to help evaluate or assess if this process

will fit? The important thing is that you build the process with your company. Everyone's going to be different. Your team are going to have different needs. Your culture is going to be different, and I think that you need to involve them. I think what we do is we bring our experience in, and we make recommendations, and we try to shine a spotlight on the future of how the company will land and work with the team to thoughtfully put it in. But I've honestly come and said,

here's process, I think we should put in, and my team said, let's not do that. I'm not going to force it. It's right for the time, and it's been the right decision. I don't think there's a lot of principles that I would think of beyond what I've stated on candidates for areas of process. On the other side, to avoid overcorrecting and shirking all process to be in with, how do you avoid that overcorrection beyond maybe not hiring the person who is anti-process,

anarchy full checklist on autonomy? How do you avoid that overcorrection and shirking all of process? There's a couple of areas. One is that you have to be thoughtful on how you put process in yourself. And then I think that what you want to do is, as you expand and you do hire people, you have to make sure you're aligned with them. And you have to find people that are like minded here. You have to sort of dig in and find out how they've handled large and small teams.

When they've used process, and it failed, and what they've learned from it, so you have to hire the right people as well as use your own experience and common sense into where you want to put this stuff. There are two specific applications of process here that I think your approach has been really interesting. One is been around like what product planning looks like at Lightspark. The other is the story behind creating like a functional or placeholder review process for

for team members. So, I was wondering if you can kind of deconstruct how you arrived at those process elements for those specific areas? One thing that if we go back to the original question about like what's different in a large company and a small company, one of the things is that I mentioned is you're optimizing for two different things, right? You have stability versus innovation. One of the things that is really different is your product planning. You have no

idea what you're going to be building. You have to be very narrow sighted, right? Like you don't have visibility past a few weeks down to level of detail. How do you plan longer? And the thing that I've found useful is like putting a narrative out there. So like in a large company where you're telling and communicating product plans, in a small company, I think you're doing a lot more storytelling. You're basically giving a narrative out there that's flexible and it may change,

you know, and a narrative is kind of like a book. And then you're breaking that book up into chapters. Hopefully your book has a good ending and a happy ending. And you want to work through your narrative and be flexible along the way. And the way to do that is to try to get detailed as you get closer to what you're doing and be more vague and put a waypoint out there for your team. Maybe a rough example would be, hey, let's say you're building a newsfeed product. It's like,

okay, we want to build a newsfeed product that is making a certain amount of revenue. It's going to be profitable making this much money by the end of the year. Okay. So chapter one, we have to get enough inventory. So we have to build the user experience to get it engaged enough to build enough inventory. Chapter two, now that we have the inventory, we have to buy it, find advertisers

and sell into that feed. Chapter three, now that we have the ads running into the feed, we have to work on the effectiveness and get the cost per click or CPM up to hit those goals. Chapter four and the story, we have a profitable newsfeed. Then you take that first one, we have to get inventory. And then now you start zooming in and you can get maybe two weeks or two weeks of

very specific detail because it's important to put some detail out there for your team. Like teams that sort of set goals, even if they're short-term, outperform teams that don't hands down. And this is also something that does a little bit of process that if you don't put in early, it's pretty painful to put in later. I've made the mistake of having a team come in and running it for six, seven months and without setting goals and saying, okay, we're going to get in the

process of setting goals. And that was painful. They didn't want to do it. And once they got over and did it, it worked out well and we built that muscle, but starting early and getting in, but not focusing on the long-term, focusing on the short-term. A long-term product plan in a large company, it can also be limiting, right? Because you're focused on a very long road, you have blinders on. But if you were only planning for a week or two, then you're open.

And you can move faster. You can move in different directions. So that acknowledgement, through this type of a process, I think, is super valuable. And the template I think you're referring to was sort of my attempt at saying, at our stage, your product plan should never have to fit on more than a single page, right? It's like a one-page thing. I can give you a really quick story on Yahoo, too. When I first went in there, I sat in a product review and there were 52

areas and we had to go through 52 product reviews. And they all had different, and I'm like, this was crazy. And I took out my startup spreadsheet from my previous company, which was this. I said, we're going to manage this all on one spreadsheet. And they thought it was insanity. But in three months, they loved it. It was so simple. They could go to one spot. They were

innovating and moving fast, again, all from this one template. So getting the right information, focusing on short-term, acknowledging that things are going to change fast, being open to things changing fast can be reflected in this process. And the template I use, I think, sort of supports and enables that. I told you this before, so recording the narrative goal-setting tool.

I haven't resonated with a goal-setting approach. I've been on a quest for 15 years or so to find one that fits that dynamic that you need both the clarity for where you want to go with the flexibility in the short term to get there. And so I want to talk about the introduction of that to the team at Lights Park. So what did that conversation look like? How did you align on that 12 month? What is winning it look like? And then begin to start to shape chapter one together. Like, what did that

conversation look like to form those? Yeah, sure. Well, this conversation probably started a long time ago, even before we started the company, honestly. Like David, Marcus, who we work for, he's an amazing storyteller. The reason I'm here is because he told me an amazing story I couldn't get out of my head. I was bought in. And you're focusing on the vision and the mission when you tell a story. You're not focusing on like a list of items. And when you can get people bought into that vision,

they're going to perform a lot better. They're like really invested in it. So like, it's super important in a startup, especially when you don't know what the list of tasks is. You should try to inspire your team and get them excited about it. So we sort of like we're already bought in on the mission here that we set out to do a long time ago, which was, you know, building open protocol

for money. Like we think it's important. We see the advantages of it. I was lucky enough to go through the early net scape era and the beginning of the internet to see how what this did for information. And the thought of that happening was super inspiring. So like we had a great story in our head of like if we can simply make money flow or value flow fast and free frictionlessly around the world, like a lot of goods going to happen. So, you know, we were bought in on that. But

then, you know, that's the ending. That's the happy ending. Like what are the chapters that we're going to write in between to get there? The first one was, well, we're going to build this new infrastructure. Let's let's start getting it out there and getting a quick end in an area where it's already accepted. And that's what we did. You know, that was the first one. And we worked backwards from that. But, you know, we do have a narrative internally. We do have a story.

This is the thing that the teams are teeing off of. They're trying to make the story happen. They're not trying to make a list of tasks happen. And I think that's a really important distinction. You know, people, especially when you don't know what the tasks are that are going to make it happen, you want to provoke, you want them to be autonomous and you want them to like be able to solve these problems themselves. And this is what we're doing as a team right now. Everyone's focused on

the same narrative. We know the chapters of the book. We know how we want the story to end. And we're writing it in day at a time. Here's the list. We're working through it. We're going to get to the end. And, you know, for lack of a better way of describing it, that's sort of the process that we're doing. For anybody who's applying this framework for the first time or early in their experience, are there final pieces of advice that you would give people as they as they apply

this framework? Saying that as somebody who just rolled this out with their team yesterday, thinking through how we can do it better, like when you're thinking about creating the narrative and being able to build this story together, any final pieces of advice to execute on that well. I do think it's important like, you know, when you're moving from management to sort of leadership and sort of storytelling and being visionary that like you believe deeply in the story that you're

telling people will pick up if you're not buying your own story. So the first thing is, you know, make sure the story you're telling you're inspired by. And if not, get it there and figure out what does sort of drive you because like the way that you present that to your team is important, you know, you want it to be infectious with there and you want them to be inspired. You want them to really understand what the vision and mission is and be bought into it. And if you're not,

it's going to be hard to get others to and be creative. You know, like years ago, one of my colleagues who I still work with came and said, you know, we have the best jobs, you know, we get to be science fiction authors and go write science fiction stories about how the future is. But we actually get to go try to make it happen. That's kind of true. So like be creative, build a great narrative, break it up into digestible chapters that are actionable. Make sure the chapter delineations

make sense. Have an ending to each one that's measurable that makes sense to get you to the next chapter. And for folks listening to this, James has some incredible examples of what this looks like. I'm going to share a link to that article so you can see that structure because what I did was I read his passage, took the template and put it into the notion. And that was that's how we developed this framework and applied it ourselves. So if you're like, I want to apply this and make

it work immediately, we'll have that in the in the show notes. James, we have a couple rapid fire questions. Are you ready to jump in? Sure. Let's do it. What are you reading or listening to right now? Boy, a few things. I read a lot with my ears. So it means I mostly listen. But like currently, I'd say the top of my list that I'm enjoying right now is Adam Grant's think again.

And I think it's really relevant to this conversation, right? And it's basically the power of knowing what you don't know is sort of the sub title of it, but like always questioning your underlying assumptions, you know, the fact that you learned something and came to a conclusion, don't take it

for granted. That it's going to stay that way. So always be reflective. I love books that give me tools that allow me to look at things differently and rethink things, get out of process, out of practice, things like that. So that's the one I'm reading now. And I think it's so interesting about you sharing that is we can see some of those approaches at play in like the earliest parts of our conversation. We're talking about how to work with your teams. And so it's interesting to see that line of

question of how you're asking your team to challenge your assumptions. It is so rare to see how people are applying the things that they learned live within their teams. And so I think that's just an observation, I think is really special. Love doing science experiments on my team. I bet you they they appreciate it also. No. Next question. You shared a ton of great different approaches tools methodologies with us. Is there a tool or methodology that's had a big impact on you?

Yeah, I mean, we've talked a lot about it already. It's hands down principle thinking, not just in work, but in all aspects of my life is like thinking about how you make decisions and building the muscle of describing how you make decision and why over the value of the actual decision itself. That is hands down. The one thing that doesn't change under scale. It's a muscle that you build and it will carry you through large teams or small teams, especially large teams. You need to build

rules for your when you're in large teams. It's very important. And that's the one thing that's benefited me the most. Two more final questions. Next one. What is a trend that you're seeing or following that's been interesting or hasn't hit the mainstream yet? Oh, well, you know, I don't really think of myself as a futurist. I will sort of just say it's probably the one that I've been chasing now for like five years that I still deeply believe is one that hasn't hit mainstream.

And when it will be a big impact and that's just blockchain in general, I think that what we're starting to see though, and it hasn't hit mainstream is looking at these things like cryptocurrencies, like Bitcoin is a protocol and not as like a currency. You have to look at like the fact that it's a pretty amazing like decentralized tool if you want a ledger, if you want things that are mathematically provable, visible and auditable that nobody can change. It's a pretty powerful tool.

So we're seeing things now happen in Bitcoin like ordinals where it's like things are moving across more like a protocol than they are of value. And I think that this is something that we're going to see more and more of. I love it. Last question, James. Is there a quote or a mantra that you live by or a quote that's been really resonating with you right now? That's a fantastic question and there's a lot of them, but I've had the really good fortune of working for some amazing leaders.

And like the thing that rolls around in my head or quotes from all these leaders and the two that have been like sort of going back and forth in my head right now being back into startup situation because depending on my situations, different when sort of come to the front of mind is like back at Netscape, Jim Barclayl, he was like the most quotable guy, but like the one that comes to mind, he would always, and it wasn't his, he was rephrasing, it was an old cowboy quote that was like never

confuse a clear view for a short distance. You have to remind myself that, you know, like these are long term, especially when you're doing something that's a really long term project, it's a big goal, big mission. And even though it's clear and like you see it crystal clear in your head, acknowledging that this is going to work and take a while is like valuable. So there's

that one. And I'll add the second one too, which is like another barc stale, which wasn't his either, but it was like a Stephen Carvee quote, I think was like the main thing is to keep the main thing, the main thing. And that was basically, hey, you know, don't get distracted. You know, there's a lot of things to chase, especially in a startup. You see all these crazy opportunities, like, but keep

focused on the mission, make sure you're focused on the most important things. And you know, the main things to keep the main thing, the main thing. So those are probably the two that are in my head right now. As somebody who's in an early, small stage company, I can tell you right now, I feel seen, I feel heard, I feel like you just described my early stage journey. And so I think people listening in who are in that shifted down scale of leadership or really in that earlier phase, James,

this has been incredible. Thank you so much for your time. The reason why I was so excited for this conversation and what we were talking about earlier is when we think about like ELC and the idea of empowering engineering leaders, the practices that you introduced here in terms of engaging your team by bringing them problems and involving them and talking about socratic questions as a way to arrive at decisions and developing principles like all of these things, like, I feel like embody

what it means to be an engineering leader who can empower other people. So thank you for helping everybody listening in. I do a little bit better on that quest. Thank you so much for having me on. It's been a genuine pleasure. If you enjoyed the episode, make sure that you click subscribe. If you're listening on Apple podcasts or follow, if you're listening on Spotify. And if you love the show, we also have a ton of other ways to stay involved with the engineering leadership community.

To stay up to date and learn more about all of our upcoming events, our peer groups and other programs that are going on head to sfelc.com. That's sfelc.com. See you next time on the engineering leadership podcast.