Adapting to your changing role as an early startup employee
Early startup employee lessons learned: part 4/4
In Part 3 of this series, I wrote about strategies to build a team with a positive organizational culture. That post was about the team; this post is about you: as an early employee, how does your role change with the changing company and how can you gracefully ride that wave? When I joined my company as the fifth person, I knew that if all went well and our company succeeded, I’d have a very interesting path within the organization. What I didn’t know was any of the details of what that meant, and importantly what skills I’d need to gracefully walk that path. This post is about the things I’ve learned over the past two years as we’ve grown from 5 to 100 employees, and as my role has undergone countless transformations in the process of growing our team and responding to the company’s needs.
In the past two years, I’ve done some aspect of almost every job that we currently have full-time employees for at my company, except for some of the sales and finance roles. Software engineering, data science, operations, customer success, people management, strategy, marketing - you name it, I probably touched on it at some point in our period of hypergrowth. It’s been an amazing experience, but also a big challenge to grow and adapt my own role in the company as its needs have changed and as we’ve hired people to fill those needs on a full-time basis. One of the most important aspects of being an early employee is recognizing your place within the company and adapting gracefully as that changes.
Letting go of your legos
A blog post about scaling a startup wouldn’t be complete without linking to the famous “Letting go of your legos” article. But seriously, hiring people to take over work that you can no longer sustain doing isn’t enough – it’s critical to be intentional about giving those people you hire the space to take over the things that used to be your job.
When I first read that “give away your legos” article, I thought it’d be a piece of cake because of course I wanted people to take my jobs, I was doing way too many of them! But actually, I’ve learned that there’s more to it than that. In my mind, there’s two parts to giving away your legos: the first is giving them away, which is fairly easy to do if you’re experiencing burnout or you’re not a high ego person. The second is to let them make it their own, which is harder as an early employee because it means they might do a “worse” job of it than you. They won’t have the full context you do or the years of experience you have building the processes or projects from scratch. But you have to let them take your legos, and also give them space to make it their own.
One thing that helps here is realizing that there is often no “best” way to do something. It’s possible that the way they decide to do something is worse, or maybe it’s just different from how you’d do it. It’s also possible that they take your hacked-together solution and make it better, since it’s now their actual job to do this thing that used to be one of your millions of jobs. Second, even if they do end up doing a “less good” job of something than you were doing, the company will still experience a net gain simply by having an improved bus factor. For example, in my case, it was way worth having a slightly less accurate QC process because it meant that we could hire junior data analysts to do it instead of having multiple scientific PhDs spending hours of their time going through relatively rote QC.
Don’t grow too fast
One of the benefits of joining a startup as an early employee is that it’s a great opportunity to supercharge your career growth and quickly get promoted. If you’re the first data scientist like I was, it’s really enticing to shoot for growing into the head of your department quickly. But it might be more complicated than that: you might find yourself, as I did, in dire need of someone with more experience than you to help guide your work, so that you’re no longer learning by doing (and making mistakes) but instead having some seasoned perspective guiding your team. You might also find out that managing teams isn’t what you want to do: the diplomacy and people management might not be your thing, and you might prefer to stay on an IC track and focus on technical problems. That’s why it’s important to give yourself space to discover what you actually like, rather than rushing into a director-type role.
In my experience, I discovered that I actually don’t really like the internal diplomacy and relationship-leveraging needed to be an effective team lead. I found myself much preferring wielding influence in my sphere, focusing on how my team can better work together rather than addressing broader strategy issues that require a lot of negotiation and mind-changing across teams. I did end up in a team lead and management role for a lot of the past two years, but because I wasn’t ever officially promoted into a “Head of Data Science” or formal team lead role, I still had the flexibility to figure out where I wanted to end up. I’m really grateful that my founder and various managers took this approach, because it made it really easy to end up where I am now: as a technical lead, wielding influence as a high-level IC but not as a people manager. The other benefit is that we got to hire a great VP of Data Science who I’ve gotten to learn a lot from!
Common inflection points
If I look back on the past two years of growth and change in my role, I can identify a handful of inflection points.
First, I was alone: I was the only full-time data scientist and data engineer. We hired interns and contractors and full-time junior folks to support me, but I was still alone. There was no one to bounce ideas off of, nobody to review my architecture decisions, no one at my level to commiserate with about the growing pains we were experiencing. It was exciting because I had so much influence, but it was also really lonely.
Then, we started building out our team: I wasn’t alone anymore, but I was in charge of everyone so I was still basically alone. Our interns and contractors evolved into full-time folks, but I was the one managing them all, the only point between our data scientists and our founder. This was less lonely, because I had other people to help do the work with me. But there were still a lot of things I couldn’t engage with these colleagues on because I was their manager, and it was still up to me to listen to their concerns and try to figure out something to do about them even if I was struggling with similar issues.
The third inflection point came when we hired even more people and re-organized our team – suddenly I had peers! In our case, two of the three senior folks I had been managing were promoted into management roles at my level and the third moved out of my reporting line. This was the biggest inflection point for me: suddenly, I had peers who I wasn’t managing on both technical IC and leadership work. I also finally had people I could commiserate with without censorship - my fellow group leads. At this point, maybe you’ll have hired a boss or maybe not. For us, we didn’t have a boss yet and that was fine - we were in constant communication and were able to present a solidified front to our leadership when needed. But the inflection point wasn’t about having a boss or not, it was really about about finally having peers.
Finally, the fourth inflection point is when I become just another employee (which is still ongoing). Now, my team is getting to the point where it’s larger than what I can directly control or even have influence over, there are people at the company who I don’t know, and there are multiple layers between me and the executives or primary decision-makers. I think that if you had told me about this inflection point three years ago when I joined, I would have feared it or been bummed about the idea of getting here. But now that I’m living through it, I love it. The fact that there are people at our company who don’t know me means that we are successfully growing and scaling, as I discussed in part 2 of this series.
Remaining a leader
Even after this fourth inflection point when you’re finally just another employee, you’re not really just another employee. There’s nothing that will change the fact that you were there when it started: you know the context, you have a lot of the scoops, you see the big picture in a way that many others may not. Many folks will be excited to learn from you regardless of your actual role.
Your opinion will probably still matter a lot, at least to some people. You should be careful with it. Interestingly, as our company has grown, I’ve made much more use of DM’s rather than public messages, despite being the queen of surfacing! But as my role has changed, knowing that my words and actions carry a certain amount of weight is important. So I’ll go to private messages first to share feedback, strategize responses to tricky situations, and make sure I’m not overstepping on somebody else’s work or opportunity to respond.
Additionally, even when you do become another employee and most new hires have no idea who you are, the people who were there when you were central to the company will still view you that way, even if you no longer are. So even as you grow and the majority of new folks don’t know who you are, you still have to recognize your potential impact, especially on folks from other teams who haven’t followed along with your changing role as closely - they have no idea what your job is now, but they still remember what your job was back then. One concrete way this manifests is that you may still get tagged into questions and issues by those folks randomly here and there, since they may not know that entire teams have been hired to fulfill the role that you used to play. When that happens, it’s your job to redirect them to the people and teams whose job it is to actually do those things now.
Finally, it’s important to recognize when it does make sense for you to step back up a play a larger part of issues than your new role may call for. For me, this has come up in two ways: first, stepping up to coordinate large cross-functional or high-risk projects that need someone with a big picture view of the many different components of the business. Second, when meeting new hires who have been brought on to tackle technical debt-related projects or other cross-functional work like program management, I find it important to make myself available to them and very explicitly offer up sharing the scoops. Like my boss says, I know where the bodies are buried and that can be really useful to make sure we’re not making the same mistakes we’ve made in the past. Most new hires don’t need to know about the bodies, but some do - and I make sure that they know I will happily give them the scoop any time they ask. Equally important is that I put the ball in their court - if they think that knowing the historical context will help them with their job, then they’ll reach out. But it’s possible that the historical context actually isn’t all that helpful to or wanted by them, in which case it’s important to respect that and let them do things their own way. Like many things about growing and changing with your company, it’s all about balance.
If you liked this post, check out Parts 1-3 of the rest of the series on being an early startup employee:
