Juggling Hats…At a Startup
If you have worked at a startup you would know what I am gonna talk about by looking at the title. Juggling many hats at a time but getting recognized and paid for only one. I am a data engineer, a data lead, product/project manager, and recently just got admitted to our management committee pool as an honorary member.
Am I being successful at all of these roles? Hell no.
Am I trying to be successful at all of them? Also no.
So what I am going to talk about here then? I’ll mostly rant and then maybe give you a few pointers as to how to manage without going totally insane and without failing totally miserably.
2 years, 6 months, and 1 day ago I was hired at a startup as a Business Analyst to do “something” with their data. As much as I was perplexed on what to do with it, I still accepted the offer because people looked nice (I know) and it was something different than an average developer job. And so it began, the continuous journey full of hair pulling, crying, sleepless nights, identity crisis, self-doubt…..laughter, impact, results, numbers, teamwork, reward, mentorship, leadership, data (oh lots of it), learnings and so on. A journey that I fell in love with eventually.
I started as a business/data analyst, pivoted to data engineer who was focusing on building infrastructure but was also acting as an analytics engineer who was providing visibility to teams on their products…because that couldn’t wait obviously (it’s a startup, duh). Soon I became the go-to data person for almost everyone in the company. That was the good part actually because people were craving for visibility and I was making dashboards and standardizing the KPIs. BUTTT those dashboards were only partially automated because…wait for it….there was NO data stack. I couldn’t even say no to people because I didn’t want to disappoint them. I was doing the manual labor, making partially working pipelines, and dealing with people and their ever growing data requests….soon some people were expecting me to work on the weekends as well just because I had set such expectations.
Lesson no 1: Learn to say no and set your boundaries.
The velocity of requests coming in and my innate desire to prove myself was faster than the infrastructure development that could have supported those requests. When my health collapsed, my boss came to me and said listen you kinda suck at managing requests. Not everything needs to be catered to right now. Say no and prioritize. Aye Aye Cap’n! I said (duh, it wasn’t that easy)
I introduced a BI tool, started to populate our data lake, and started to migrate dashboards and reports on it. Things were improving but oh wait I also went on to become a core and only developer for a complicated project. In my defense, I was missing to code full time but of course how could I have forgotten there was no one I could have delegated my other work to and if there was any, I didn’t know how (narrator: she was too stubborn to). Here I was trying to pull off a gandalf on all my dying responsibilities, but hey I was smart and hard working who always delivered so I delivered here as well. However, the pace of that delivery slowed down.
Lesson no 2: Forgive yourself for wanting to learn too much.
Yes, the pace was slow, I was juggling a data and software developer role. As I was front-facing that project I had to deal with different stakeholders as well. Naturally, some low priority tasks were dismissed or were assigned to someone else. So I decided to forgive myself for wanting too much and I was happy.
Soon I was given (quite forcefully actually) people to manage. Oh I was so not ready to come out of my individual contributor zone as I already had many projects on my plate. I suffered. They suffered. Initially I was bad at the delegation bit but I was good at making them feel at ease in the company. I was good at giving them space and making sure they felt the culture directly. Soon they figured out what they wanted to do and churning out good quality work. I convinced myself to delegate.
Lesson no 3: Delegate.
I know it sounds cliche but for individual contributors and people who like to control the output that goes out of their desks, it’s hard to trust others. Remember one thing you all, by not delegating you are actually taking a learning opportunity from someone else that you have already mastered, do you really wanna be that person, huh?
Now I was a data engineer, and a data lead. This lead title is heavy, I tell you. Suddenly I was talking to people more than actually working. I was dissatisfied most of the times. When I closed my eyes at night I saw different faces waiting for me to get back to them, as a lead as well as IC. I was haunted, no kidding. There was stuff that I didn’t want to do and there was stuff that I really wanted to do. I was struggling at both hence my annoyance grew. Finally, I raised my voice. I talked to my boss that this is too much (mind you, my ego cried a lot when I did that). It was even too much for the team. So we were heard, I presented a new strategy and we offloaded ourselves from making fancy reports for different departments. Instead, we were responsible for raw data and analytics.
Lesson no 4: Raise. Your. Voice. Ask. For. Help.
Use your position to raise voice otherwise you are just wasting the opportunity given to you.
Things improved a lot and I got too greedy(surprise! surprise!) and accepted to lead a product. Now I was a data engineer, a data lead, and a product manager. Yep, I like to have no life. In the beginning I thought I was supposed to work on this project since another important data project was cancelled because of COVID-19 situation. But soon I started to believe in this product and was owning it. It was difficult to take it off in the beginning. It was supposed to run in beta phase for at least 6 months, but we all wanted to do a good job to make it survive the beta. It’s difficult when you are time constraint and you don’t want to lead by giving orders. In order for everyone to equally own this product, we really had to build consensus on everything that we did. Since, we were a small team, it was pulled off successfully (okay, 93% successfully). Now when the product is relatively stable, my bandwidth goes on and off on it. Sure, it’s kind of embarrassing when 2 of your teams are demanding some answers and you can serve one at a time. I was (still am, honestly) embarrassed not to cater to everyone requirements at priority but hey, remember lesson no 2. Forgive yourself for being greedy. But how come it’s still manageable? Because you have lieutenants and captains in your teams. At the end of the day, it’s the people. You need to identify your lieutenant who would handle things in your place so your absence can be tolerated. And make sure they are motivated.
Lesson on 5: Identify your lieutenant.
This advice was handed to me by my boss, I am still grateful. It’s very important to continuously look at your team and identify lieutenants. It can be multiple people for different skills as well. You need to find people who can step up.
And finally, I was honored to make it to the management committee of my company. Initially (although this is still initially, lol), I was too silent in the meetings. I did not know what to say. I was too conscious. But being silent in meetings and having nothing to contribute was killing me. I wanted to withdraw but held on to it for a little longer for things to improve. As of now, there are topics where I can contribute and I am slowly starting to own this position as well to execute my thinking company wide. Let’s see how that goes!
All in all, just hang in there with all your spirit and by realizing you are a human. I am blessed to be surrounded by great mentors (more on that in another article), great team, competent and good people!