How to scale yourself as a first-time leader | Poornima Vijayashanker | #LeadDevAustinOn November 15, 2019 by Raul Dinwiddie
good morning, everyone. I have the honor, the privilege, of being the first speaker
and maybe even a little bit of a curse, so I remember when I was transitioning from being
an engineer into a first-time leader. I was super excited. I was like power-posing all
the time. How many of you are transitioning to being a first-time leader? Go ahead and
do a quick power pose in your seats. All right. How many of you are supporting these folks?
All right. And how many of you are hoping to become a first-time leader, maybe next
year? OK. Good. So I was super-excited, because I would get the opportunity to do things that
I didn’t get to do as an individual contributor. I would pick projects, I would get to lead
people through them, and overall, I was feeling pretty excited.
Then a couple weeks in, reality set in. And I noticed that I was constantly in meetings
with my teammates, with stakeholders, with other teams, and when I wasn’t in meetings,
I was helping out my direct reports as well as my other teammates, solve problems. And
all of this left me kind of feeling like I was being pulled by a number of directions,
just the constant context-switching. And I really felt unaccomplished at the end of the
day, because as an engineer it was kind of in my DNA to write code, ship product, and
have some tangible results at the end of every single day.
So I thought about how I could concoct a scheme where I would get to benefit from being a
leader, as well as an engineer. And I came up with a scheme where I would
wake up a couple hours early in the mornings, I would write some code, and then I would
go into the office and be present in all of the meetings with my teammates and with others.
And then at the end of the day, I would return to writing a couple of hours of code.
And all of this was working out pretty well for, you know, a couple weeks.
[laughter] Until again, reality set in and in time, the
reality was that I had become a bottleneck. I had become a bottleneck because I didn’t
have the time to fix my bugs in the middle of the day, the bugs that I had written from
the code that I had written and people were just like continuous deployment. And instead
of giving my code to somebody else on the team and sort of delegating, I became a little
bit of a hoarder, because I wanted to feel that sense of accomplishment, and to make
matters worse I got some pretty harsh feedback and that was that I wasn’t doing a good job
at either an engineer or as a leader and I had to pick one of the two roles and kind
of see it through if I was going to stay at this company. I wasn’t sure how to proceed.
And I decided that the best course of action would be to solicit some help from outside.
I reached out to a trusted advisor to ask how I could go about managing myself as a
leader, doing the things that I was doing well, but also figuring out what my blind
spots were. So they came in and they shadowed me for a few days and afterwards they said
what I really needed to learn was how to scale myself better as that first-time leader. I
was doing too much. I know I’m not alone in this, and I’m sure
a not of you have either faced this in the past or hopefully — or unfortunately you’re
dealing with it right now, but what I want to share with you today are some of the things
that I did to scale myself as a first-time leader.
Hi, I’m Poornina Vijayashanker and as Meri kindly introduced me, I was previously the
founding engineer mint.com, after the acquisition I decided to transition
to becoming a founder. I first led BizeeBee and eventually I shut it down to start Femgineer,
I transitioned it from a blog to a business. I’ve also been an entrepreneur in residence
at startups, a lead mentor at Tech Stars. I’m also the host of Build,
so if you like today’s talk and you want to get a little more content on product development,
entrepreneurship, I highly recommend you check it out on my YouTube channel.
So with that, let’s get back to the topic at happened. And one of the things that my
advisor, as they sat me down, told me was that I needed to build a self-sufficient team
and as they were telling me this, I was wondering, why is a self-sufficient team important? Shouldn’t
I be the linchpin? I guide people, I need to be really involved, right? And what I realized
was that doing that actually wasn’t helping anybody, because I was again becoming a bottleneck,
what I really needed to do was first learn how to trust other people. In a number of
ways. I needed to learn to trust them when it came
to making decisions, I needed to learn to trust them to getting things done and I needed
to learn to trust them to spout any knowledge gaps they had or come to me when they were
ready to seek some help. The other thing I needed to learn is that a bus factor of 1
doesn’t help anybody. In fact, it makes things worse. Nobody can take a vacation, nobody
feels like they’re learning from one another. And so these were two things that I needed
to take stock of. And I realized as I did this there would be
a number of benefits. People could actually go on a vacation and actually take a vacation,
not like check their email from the beach, and they could also transfer their knowledge
from one person to the other, to help each other level up.
I personally felt this benefit last year when I went on parental leave and my business could
continue without me being there, and I could spend time with my little one. So I have some
caveats, though, because this is my story and some of it may apply to you, some of it
may not and a lot of it is going to depend on your particular company’s culture. So if
you have a culture where you’re expected as a first-time leader to write code, kind of
deliver, as well as lead people, that might be a little challenging. I know for me it
wasn’t prudent. I found that context-switching not helpful. But if it’s part of your company
culture, it might make sense to talk to your manager about how that day to day is going
to roll up into a team or a company goal. The other is if you’re on a remote team, you
might find that you need to invest a little more heavily into developing some communication
skills or some best practices and a process for development so that you candistribute
across your team. So what I’m going to today is certainly not the gospel. These are things
that helped me in my situation of leading a team of about 5 to 7 people. Eventually
everyone was together and eventually we became a distributed team. And as I took on the leadership
role, I was tasked with three goals. The first was to scale the product. We were moving from
a prototype into a scaled architecture. The second was to scale the product development
process and the third was to scale people issues. And as I sat down with my advisor,
I was like, OK, what do I need to do first? And my advisor said, well, you really need
to lead by influence, and not authority. How many of you have heard this phrase? Like,
lead by influence? Yeah, so maybe some of you know what that means. But I honestly didn’t.
And I was like, what does that mean? And I gave my advisor the benefit of the doubt thinking
that OK, it wasn’t some like management mantra, maybe they knew a thing or two and certainly
they’d been a veteran in the industry and they will they told me, well, you need to
stop telling people what to do and you need to learn when it’s appropriate to step into
situations, and when it’s appropriate to not step into situations.
And part of that is giving people the what and the why, and then letting them figure
out the how. I knew this was going to be a challenge for
me. I was a recovering micromanager and again, a recovering engineer, who loved problem solving,
who loved fire-fighting. I was like, OK, how do I start?
So I started very small. And I started small by doing just one thing. I called a meeting,
I kind of laid out what we wanted to do, and then I just shut up. I literally like sealed
my mouth shut. I explained the what and the why, and the
what was we needed to scale our architecture from a prototype into this service-oriented
architecture, and the why, because we were growing as a company, we had a lot of customers
and we wanted to deliver a positive experience to them. And then I just kept my mouth shut
and let me engineering team run and people started to chime in. You know one engineer
raised their hand and said, so if we’re going to move in this direction, I really think
it’s important that we have another test suite, because our code is really brittle and on
top of that we have a lot of tech debt and it’s unclear which tech debt we should close
down first. I thought this was brilliant and I also knew
a lot about test-driven development so I really wanted to speak up. But I kept my mouth shut
and I let them continue to brainstorm and by the end of the meeting they had kind of
created a scheme for themselves where they would build out the test infrastructure that
could then support our transition. And as a result, what I had done is I had
delegated like all of the work that I had been doing, and I was starting to build a
team that was autonomous. They would be responsible for doing all of the research, all of the
implementation, and just to add a little bit more to their list, I also let them set their
own deadlines, and this was kind of novel, but the reason I did it is because they were
on the front lines. And so I figured they would know best whether
they had any knowledge gaps, whether when they experienced scope creep, and I really
needed them to get into the habit of doing this, even if they made mistakes, even if
their initial estimates were off. Because over time, they would learn how to course-correct,
instead of me imposing some artificial deadline on them.
And of course they turned to me and they were like, well, what are you gonna do? They’re
not gonna do anything. And that wasn’t necessarily true. I still had a lot of work to do. I needed
to check in with them. I needed to coach and mentor people who were new to the company,
and to fill in any of those knowledge gaps they had, help them level up, and coach them.
And of course I needed to review the results to make sure people were on track, I really
just served as kind of guardrails for the team.
So one question that comes up, and I certainly have this, was does team composition matter
when you are doing this transition? Does it matter if you have a junior team versus senior
team? It I have to be honest, it actually doesn’t matter, because junior engineers can
level up very quickly if given the right guidance and coaching and senior engineers can certainly
mess things up thinking they’re know it alls or not being very communicative. So at the
end of the day it’s making sure you understand people’s knowledge gaps, and that people have
complementary skills. Really what that means is you need to spend about 6 to 12 months
getting to know the people on your team so that you can then coach and mentor them, or
sometimes you might have to hire people from the outside to come in if you need more expertise.
And I’m happy to report that about 8 weeks into this project, I discovered that my team
was functioning pretty well, and that my day-to-days were spent helping with those knowledge gaps,
helping coach people and helping them level up.
And by the end of the 8wise weeks, they felt pretty good, they deliver their initial solution,
but there were still things that came up. They were concerned that this was like a great
first pass, but what would they do in the future? How would they continue to iterate
on the process. So I made one suggestion which was to have a post-mortem every quarter and
what that would look like is everyone would come into a room, kind of air their grievances,
and then we would decide as a team to pick one to two process changes, and the reason
I limited it to one to two, is because change of behavior is hard, because when you’re scaling
a team and the organization is constantly in flux.
The other reason was to make sure that we were headed down the right path, that these
process changes were actually making an impact. So about 12 months in, I was feeling good.
I had started to scale the product development. I had started to scale the process. And it
was time to turn my attention to scaling people issues. And I’ve been pretty fortunate to
be on teams where the people have been fantastic. You know, I’ve never really had a situation
where I couldn’t work through it. I have had to fire some people, but in general, overall,
people have been pretty competent and they have, you know, been there to help me as I’ve
made transitions. And in particular, when I first transitioned,
I had two engineers. Let’s call them Sam and Dakota, they were the best of buds, maybe
there are some people on your team that are like this. You know, they loved getting coffee
together, they loved paired programming and even when they weren’t at work, they would
go to hackathons on the weekend or just do fun stuff together. So I knew that they were
like this dynamic duo, and I was really surprised one day when I walked in and I saw that they
were seated on the opposite sides of the room. Or standing sometimes.
I didn’t know what was going on. So I thought, you know, I’ll just let them come to me, I’ll
set up my machine, I’ll get my day started and soon enough, Sam approached me and ask
to go into a conference room. So we took a conference room, and Sam proceeded to explain
what had happened. There had been a nasty customer bug, and Sam
had come up with a solution, had asked Dakota to code review it and after Dakota had code
reviewed t sort of dismissed Sam, said that the solution wasn’t robust enough, and came
up with a different solution and wanted to deploy the solution. Well, Sam was pretty
irate at Dakota’s behavior and told me that I needed to fire Dakota.
[laughter] And I took it under guidance and said, all
right, I’m happy to hear your side of the story, let me go and find out what happened
with Dakota and I said I would get back to Sam.
So what do you think happened next? Heh-heh-heh-heh I walked out of the conference room and of
course, Dakota had been watching what happened because we have glass doors and windows.
And Dakota asked to speak to me, as well. So I took Dakota into another conference room,
and Dakota proceeded to unload what had happened. Dakota had said, yes, Sam had asked for a
code review, but Dakota noticed that it was not very robust and needed to come up with
more corner cases, you know, more conditions, and you know, Dakota just had a really robust
solution and wanted to deploy it and gosh, Sam was being so self-centered in thinking
their solution was best instead of thinking what was best for the company. Perhaps I should
also fire Sam. I was like, OK, this is going to be a fun, fun day. So in that moment, I
was summoning what my advisor had told me about stepping in and not stepping in. And
I thought, OK, it’s really tempting to want to sit these two people down and be like,
I’m not going to fire either one of you, and need to resolve the situation. But I decided
that in my gut, this was just a minor squabble. I mean it seemed like it was major, since
they both wanted me to fire each other, but I knew them, I knew they were the best of
buds, they had been working together pretty harmoniously for at least as long as I knew,
about six months. So instead of stepping in and telling them what to do, I just acted
again as guardrails and I told them that they would have one week, I decided and I would
give them a chance to kind of spend the first couple of days just like cooling down, collecting
their thoughts and then I suggested that they have a meeting, talk to one another, uninterrupted,
hear the other person’s side of the story and if at the end of the week if they couldn’t
resolve their situation, then they could come to me and I’d be happy to step in.
So, a week went by. We didn’t have any major customer issues, thankfully, and at the end
of the week, I know this is going to seem like a fairytale ending, but Sam and Dakota
sorted things out. I was actually shocked at their response,
which was they thanked me for letting them sort things out. They were like, oh, I’m so
glad you didn’t play, like, parent and tell us what to do. got a chance to see not only
what we were doing wrong, but came up with a paradigm of working together better. And
figuring out how to proceed when one person thinks that their decision is earlier.
I decided to take it a step further and explain to the team that that conflict is just normal.
It’s going to happen a lot, it’s going to happen in stressful situations, it’s going
to happen in peace time, as well. We need to embrace it. We also kind of need to have
levels where I want you all to sort of resolve things on your own and if that doesn’t help,
you can certainly come and talk to me, but I didn’t want to be that first line of defense,
because then all I would be doing is being in conference rooms all day and hearing people
explain that they wanted me to fire people. So this was really helpful in terms of laying
out the people issues and I was happy to report that two years in, I started to see that all
of my goals related to product and process and people were paying off.
And as I talked to my advisor, I was really helpful — and I was really thankful that
I had had some outside per speculative, especially someone who was a bit more objective. They
could come in and shadow me and see how I was reacting to things and I had learned how
to lead by influence, instead of by authority. Now, as you are all thinking about being a
first-time leader and how you’re going to scale yourself, I know it’s going to seem
like a lot. It’s just like so much to bite off and you’re thinking like, wow, if I had
those three goals, I don’t know what I would do. So one really simple thing to start with
is just take stock of your to-do list. What do you see that you’re doing on a day-to-day
basis that maybe you don’t need to be doing and somebody else on your team could do? And
if they’re not ready to do it, like if they’re not ready to take over your code, what do
you need to do to get them there? Do you need to maybe pair program or mod program and help
them out and kind of coach them over time? And then what are the things that you need
to focus your attention on and do more of and if you don’t know how to do it, how can
you get outside help, as well? So in taking stock, I realized that some of
my skills were getting rusty, definitely my coding skills and I didn’t have that instant
gratification that I had craved in the past, but over time I was learning new skills and
I was starting to feel a lot more accomplished over time.
So if nothing else, I hope that from this talk, you’ll at least leave with this mantra
of trying to figure out when it’s appropriate to step into situations, and you need to be
there for your team or more others, and when you want to trust your gut and say that you’re
not going to step in because you need to scale yourself as a leader. If you’d like to stay
in touch, you can contact me on Twitter, and check out my website. Thank you.