How to Scale Yourself As a First Time Leader

Cool

first transitioned from the, an engineer to a first-time leader. I was super excited at the opportunity because I would get to have my own team and do the things that maybe I didn't necessarily get to do as an engineer. Then a couple of weeks in, I noticed that I wasn't as excited anymore because reality set in, I was constantly being pulled into meetings.

And when I wasn't in meetings, I was trying to help my teammates solve problems. And this constant context switching made me feel like I was being pulled in so many different drugs. And on top of it all, I just felt really unaccomplished at the end of the day and having been an engineer, it was kind of in my DNA to want to feel that sense of accomplishment, to want to write code and see tangible results at the end of my day.

So I thought about how I could fix this problem. And I came with a little scheme for myself. I woke up early in the mornings, a couple hours earlier than everyone else, and I would write. Then I would go into work, be with my team, be in those meetings as well as help them solve problems throughout the day.

And at the end of the day, I would go back to writing some more code so that I felt that sense of accomplishment. I thought this scheme was great and I would be able to have the best of both worlds until a few weeks in. I noticed that my scheme started to break down. All the code that I had written obviously caused bugs and I couldn't get to fixing them fast enough.

And my team needed to continuously deploy to production. And when they asked me if they could fix it, I became a little bit of a hoarder and a micromanager, and I didn't want them to take it because they would be taking away my sense of accomplishment. And after all of this, I also got some pretty candid feedback that I wasn't being a very good engineer or a leader.

And I needed to either pick one. And if it was to be a leader that I needed to embrace it fully. So I wasn't sure how to do this. And I knew that I needed to get some help from outside. I decided to work with a trusted advisor and just laid my cards on the table and said, I really don't know what I'm doing well, and what I'm doing poorly.

Maybe you could come in and watch me and shadow me. And from that, we developed a bit of a plan. So in my talk today, I want to share some of the strategies with you because maybe you're feeling this way. Wondering how can you scale yourself to build a self-sufficient team as that first time? Hi, I'm horny, Nima, VJ Shanker.

I began as the founding engineer of mint.com. I helped build a prototype, launch it, scale it, and after the acquisition I transitioned and I became the founder of busy beat. And most recently I am the founder of . It's an education company where we help techies like yourselves build products, companies, and level up in your careers, through educational content and training.

I've also been an entrepreneur in residence at 500 startups, as well as at tech stars. And I have written a couple of books. The first one is how to transform your ideas into software products. And the second is present a techies guide to Publix. If you'd like my talk today, then I recommend you check out my web show, build on my YouTube channel.

I usually do weekly episodes on a range of topics. So getting back to the talk, one of the biggest questions I had when I started was like, why is a self-sufficient team important? If I'm a leader, shouldn't I be the linchpin of this team? And I realized quickly that no, I really needed to be working towards building that self-sufficient team for.

The first is when you have a self-sufficient team, you inherently have built a team that trusts each other, which means they can do things like rely on each other and they can do things like get shit up. Now, the other thing about a self-sufficient team, as well as one that has trust is you start to distribute the knowledge because no, one's really hoarding it.

Right? And when you distribute knowledge, you no longer have this bus factor of one, people can help each other. And it's really cool because then when you want to take a vacation or somebody else wants to take a vacation and doesn't want to get into that state of burnout, everyone's got a little piece of that knowledge, right?

No one is stuck. I definitely benefited from this, this past summer when I went on maternity leave, because I had that self-sufficient team who was just plugging along while I got to spend time with my little one. But I've got a few caveats for you. I understand that, you know, your company culture may be different from the ones that I've operated in.

And I know that a lot of the companies are changing where they expect their leaders to write code as well as lead teams for myself. I didn't really find this to be very prudent. And for yourself, if you're in that kind of situation, I think it's valuable to ask two questions to your boss or your mentor.

The first question is what are your goals and your priorities for the upcoming year as you do this transition, and then how do your daily tasks meet those goals and priorities? Because if there's not enough time, then chances are, it may not make. The second is, this is an approach that worked for me and it's worked for people that I've coached.

So it may or may not work for you, or you may have to tweak it depending on the type of company you're in. I know somebody in the back asked about a distributed or remote team. There may be differences based on that, or if you're in a larger team or starting with a team of just one engineer that you have to manage.

So when I began, I had three goals. I got handed over the first was I needed to scale the product because it was starting as a prototype. The second was to scale the product development process because we'd be adding people. And the third was that I needed to scale people issues. And again, I wasn't really sure how to go about doing this.

So I went to my advisor. I'm one of the things my advisor said was you need to lead by influence and not authority. What, what does that mean? I don't know if have any of you heard this like lead by influence? Yeah, I was so baffled. I had no idea what this meant. I was like, can you give me an example, like lay it on the table.

And the feedback I got was, well, you tell people what to do and that's not what you should be doing. You need to let them figure it out. You need to give them sort of the what and the why, but let them decide on how and when. So the only way that I could do this, I realized was to start small and keep my mouth shut and meetings.

And so the first meeting I had after meeting with my advisor, when I learned this lead by influence was to say, okay, here's the deal. As a team, we need to transition this prototype into a product. We need to build a scalable architecture and we need to do this in the next year. I'm going to leave it up to you guys to brainstorm how we're going to do this.

You know, one, we're going to be delivering things and so on. And then I literally shut up and then a couple people started chiming in. They were like, oh, I had this great idea. And I have this great idea. Started moving forward and somebody said, yeah, I've got, I think the issue is that before we can move, we have like a really crappy code base.

It's just a bunch of spaghetti code. We really need to improve the quality of it. So we need to Institute a test suite and moved to a test driven development. I knew a lot about test driven development and a lot about test reads, but I kept my mouth shut and let them continue. At the end of the meeting, I realized that what I needed to make sure was that I had delegated all the work to them.

And so that was the only time I spoke up at the end of the meeting. And I said, okay, here's the deal. You can do all the research. You can do all the implementation and you get to set the deadlines. This was a little new for my team. They're like, do you mean you get to set the deadlines? Well, I wanted them to set the deadlines because they were the ones that were on the front lines.

They would develop their own case. And more importantly, they would probably hold ourselves accountable. If I gave them this ability to do this, my role in this was just to frequently check in with them every week, review the results and act as their guard rails. So anytime somebody had a knowledge gap or needed help or a little motivation, I would be there each week to help coach and to.

So a question I get asked a lot is like, does team composition matter? Like when you're doing this sort of thing, do you need to hire new people? Do you need to transition so on? And I think it does matter. And if you've been working with a team for a while and going and having those consistent one-on-ones, then you get a sense of what people's knowledge gaps are.

And that's when the coaching and the training helps. If you are inheriting a team it's also valuable to dig in before you decide to hand everything. So my team set a goal for themselves of delivering this test suite, the initial version in eight weeks. And I'm happy to report that at the end of the eight weeks they delivered it.

And I thought it was great, but they raised their hand. They're like, you know, this was good to like, get the product going, but there's still a lot of stuff that's broken. There's a lot of process changes that have to happen. You know, how are we going to deal with it? So I made one suggestion, which was to have a quarterly post-mortem and in that post-mortem people could come, they could air all their grievances and they could also talk about the things that they enjoy doing.

And then as. We would pick one to maybe two areas that we would change in terms of process. We set one to two because let's face it, change. Your behavior is really hard and it's even harder when you were trying to scale a team as well as a product. So we developed this cadence and about six months in, we were getting the hang of it.

And I was starting to realize that I had a pretty self-sufficient team and was scaling myself as well. The next thing I needed to work on were those people issues. And the last panel, they talked a lot about people issues and like when to step in and when not to step in. Right. And you get so into the mode of wanting to step in, but I'm going to give you an example of when it's appropriate to not step in.

So I have these two engineers, let's call them Sam and. Salmon Dakota. We're the best of buds. You know, they loved pair programming. They love talking about their coffee at dictions and you know, playing games, et cetera. So one day given how harmonious they are, I was really surprised to walk into the office and see that salmon Dakota were standing on opposite sides of the room and they weren't talking to each other.

I knew something was up and that I needed to get to the bottom of this. So I set up my machine. And then I noticed that Sam approached me first and asked to go into a conference room. So I walked into the conference room. And Sam proceeded to unload what had happened. There had been this nasty book and Sam had this amazing solution for it was going to ask Dakota to code, review it and did Dakota said it wasn't good enough, had a better solution and thwarted Sam's efforts to check in the code.

Sam was so offended that Sam was like, you know what? You got to fire Dakota. This is ridiculous. So I listened fully and I was like, okay, let me, let me get the other side of the story. And so the next thing I did of course, was listened to Dakota side of the story. And again, Dakota and I took a conference room and Dakota, you know, unloaded on me as well saying here's the.

Sam while how to solution. It was not robust enough. It had a few things that needed to be worked out. So obviously my solution was better and I believe that I needed to check in the code. This of course, you know, made may Sam and Dakota, both getting on each other's nerves. And so at this point, Dakota is like, you know what?

You need to fire Sam. I was like, okay, I get it. And this was where I had to decide as a leader. Do I need to step in or do I not. Now, there were a couple of things that I thought about before I made my decision. The first was I had known salmon Dakota, and like I said, they were the best of buds and they'd been working harmoniously for the last six months.

So in my gut, I felt like they could probably work this out as well. Had I not known Sam or Dakota or had they not known each other very well, I probably would have immediately stepped in to mediate the conflict. So instead of doing that, I gave them some structure. I said, you've got one week I recommend taking the first couple of days to just cooling down on your own, then schedule a meeting together, listen to each other's story, fully uninterrupted.

And at the end, if you are truly at an event, And can't mediate it. I will be happy to step in. So a week went by, you know, nothing bad happened during this week, at least. And at the end, when I checked in with them, they had sorted this out. I know this sounds like SOTAL fairytale, right? But here's the thing, what I had given them, the ability to sort their issues out.

They actually came and thanked me. They said, well, we're really glad that you trusted us and gave us autonomy to mediate this on our own and knew that we could patch things up. And yes, we said some things in the heat of the moment, like fire this other person. But we didn't really mean it. Right. So in that moment, I realized there are appropriate times when you don't need to step in as a leader and you can give your teammates the autonomy to figuring out things on their own.

I decided to take it one step further and use salmon Dakota story at the next post. So when we met, I mentioned how there had been this conflict and that let's face it. Conflict is totally normal. It's natural, especially when we're in those stressful situations. There's bugs, there's customers yelling at us.

So I wanted my team to know that it's probably going to happen again. And if it does, it's okay. Here's a process for evaluating whether you want to solve it on your own, or if you think it's out of your hands to come and talk to me so that I can help you. So at this point, we're about a year and a half, almost two years in it, it took me a while to get these three things down.

And what I realized in doing that was a lot of credit, certainly went to my trusted advisor. Those role-playing sessions that a few people talked about were totally helpful. So I highly recommend that you do that. And it's often best to have somebody like an advisor who's outside of your company, because they can bring that sort of objective perspective.

Now as you're thinking about how you're going to scale yourself, think about how you want to influence your team. Do you want to start by building that autonomy rather than authority? And one simple way to do it is to start with your daily to-do list. What are the things that you've got on it today that probably you shouldn't be doing?

And instead someone else could benefit from that learning experience. And for me, that was to not write code anymore. Given how many direct reports I had, but I also needed to make sure that as I was giving them the code, I was coaching and training them through it. And then of course, figuring out when it's appropriate to step in as a leader and when it's okay to give your team that trust and let them decide on their own by not stepping in.

And finally it's super tempting as, you know, an engineer or an individual contributor who has constantly been doing something to then worry about your skills, getting rusty. And I just had to learn to embrace new skills and part of embracing those new skills was having somebody hold me accountable. So for myself, having that advisor was very hard.

Now there are a couple of resources I want to mention. I know Christian already mentioned the thanks for the feedback. So I'll just plus one on that. I think it's a great book for the same reasons that he mentioned, but also because it helps you see when your feedback isn't landing or when you're not taking feedback.

Cause there are some triggers. Cause us to not listen or, you know, to not be able to cut through and give somebody feedback. So I recommend it for that reason. The second is the five dysfunctions of a team. Maybe some of you have already read this. It's a pretty popular book. Yeah. I really like it because it's all about how trust gets broken on a team and then how you have to go about repairing it.

And the kicker is that the person, the leader on this particular team was somebody who was coming into a brand new team and had to deal with this kind of infighting. So it's great for those of you who are thinking about how do I approach maybe a hostile team or a team where there has been some trust.

And the final is this one minute manager series, which is just great for like self-leadership for figuring out how people need to develop competencies. And I've just got a lot of really quick reads. So for those of you who are, time-crunched highly recommend picking this up because you can read it in like a weekend or even sometimes a day.

So my final words to you, as you're thinking about scaling yourself, is that in order for you to scale yourself as a leader, Remember that you do that by learning how to delegate. Thank you.