After two years working at Mailchimp as a software engineer, Soyo Awosika-Olumo recently became a tech lead for the first time on Mailchimp’s Campaign Builder team. Here, she reflects upon her new responsibilities and experiences:

My journey to becoming a tech lead started when I was still an individual contributor (IC) on one of Mailchimp’s website squads. I enjoyed it, but after about a year and a half I wanted a new challenge—and then I saw a position had opened up for a tech lead role on a new project. From speaking to the engineering manager, it sounded like what I wanted to do next with my career. I knew that I didn’t want to become a manager myself, but I did want to be more visible and keep growing as an IC. That’s how I came to join the Campaign Builder team.

Our goal as a team is to build a product that allows our customers to plan, organize, and track their marketing assets and goals in a single place. Mailchimp is like any other tech company in that you start to see the same patterns everywhere in terms of taking data and transferring it, visualizing it, cleaning it up, and using it. Having spent so much time building out services and UI, I wanted to be on the other side—to be the person defining what those services should look like, while also being part of a cross-functional team that I could like and respect, and which supported me in turn.

I also had this long-standing desire to do what I call “closing the loop”—that is, finishing the projects that I start. I’d worked on campaigns before on an entirely separate project. That got shelved, I was moved elsewhere, and there was something of a full-circle moment to be able to come back to a similar project again. While I wish I could be someone who gets to close all their loops, I’ve come to learn that there’s immense value (and satisfaction) in leaving a project in a state where other people can then pick it up and get it over the finish line.

Implementing your own vision

I’ve found that the ideal size for an engineering team is four to seven people (although seven is pushing it), with five as the ideal because then everyone has the same closeness to the work, and you always have cover if someone’s off. There’s no point throwing 20 engineers at a problem when what most teams need more than anything is good research and planning—not to mention realistic expectations.

And now that I’m architecting projects, I have a particular philosophy: I’m not only making sure that tasks get done, but also making sure I understand why we’re doing what we’re doing. My job is to be the one who asks, “Wait, why are we doing this?” I don’t want to be six months into a project just to find out that we don’t have any data to back up our approach. There’s a lot of trust that I, as a tech lead, need to earn. It doesn’t come just because someone gave me the title of “tech lead”. You have to show that you are a tech lead, that you can do it, and you can do it well.

I feel this way partly from previously working in teams with mixed levels of technical understanding, under a manager who would flatly reject proposals from engineers to implement new features. I prefer to be solutions-oriented, and it taught me that you have to give people space to process why something is happening or might need to change, and let them make their own decisions in response. It gives you a middle ground for making compromises as a team.

That brings with it the push and pull of being a partner, not just a stakeholder. Every member of a cross-functional team like ours has differences in technical understanding. It can be fun hearing Product talk about nice-to-haves, but at some point someone like me has to come in and bring everyone back to reality. (No, you can’t just let people type in free text!) 

At the same time, since I’m one of the full-stack engineers on the team, I’m aware of how often Engineering can feel like problems are just dumped on its shoulders. It’s been good to flex my muscles both explaining to non-engineers what can and can’t be done, and also explaining to Engineering that we can’t just quit because then nothing’s getting done. 

If Design decides something new is in scope, then we have to raise that as an issue. If Product tells us that we’re going to have to work with the Creative Assistant team for example, then we need to talk to them and find out if it’s actually possible. I refuse to leave any conversation feeling like I didn’t do what I needed to do—but it’s not about throwing anyone else under a bus, either. I have to be able to say I put in my best efforts. There’s satisfaction in knowing how much influence that can have on a final product. Having space to have these kinds of conversations is vital.

In a sense, it’s an advantage that Product relies so heavily on Engineering, because it feels like it gives me more of a level playing field when I make my case for changing course. But, sometimes you just have to relent. That’s how you want to do it? It’s not going to end well, but OK!

Doing by delegating

There was a point where I realized that I needed to stop pulling tickets myself. The only tickets coming in were the kind that should have been left for someone in a more junior position, starting out in their career. When I’m pulling tickets and working on an API endpoint, I’m not learning anything new, while also ruining a learning experience for someone else.

For example: we were getting the Google Cloud Platform service up and running, and building a new developer workflow for it. I realized it was more helpful—if I was going to pull tickets—to at least record myself, and share those videos with the rest of my team as a resource. I also like to take the product roadmap and make an accompanying technical roadmap, since product roadmaps can get so overwhelming in a feature sense without being clear about what we need to do, when, and why. With our project we had plans to organize, track, and analyze, so I made my own framework alongside: when to spike, track, develop, implement. It makes that key information digestible, plus I don’t have to be involved in every little detail because everyone’s empowered to make decisions. 

But I also always leave my calendar open, so I can meet with every engineer on the team at least once every other week for pulse checks. (Plus, Slack’s always there too.) Some people just need someone to talk to for 30 minutes, and I’m happy to be that person. 

I hate to see junior engineers starting to burn out. There’s pressure in your early career to keep pushing things out there, and I used to be like that too. (I even had my own existential crisis last year, where I’d ask myself, “If I’m not pushing out code, then what am I even doing here? Should I be an IC? Should I even still be a coder at all?”) But I tell them that life happens, and we’ll be OK if we slow down. Empathy is the key thing—you have to be able to give other people grace.

Something I tell junior engineers is to ask as many questions as they can, no matter how stupid, because at some point in their career they’re going to have to be the person with the answers. Realizing recently that I’m that person now was a huge moment, as was hearing from someone that it was my leadership that was helping my team be productive and happy. It’s allowed me to quiet that noise in the back of my head—I can stop focusing so much on the PRs and give people the space and tools they need to get their work done instead.

After all, there are only so many hours in a day, and I can’t be pulling every ticket, helping my team do their work, and advocating for engineers, all at the same time. And reorienting myself to think in terms of my team instead of just myself applies to my career goals just as much as it does to my productivity and happiness.

Developing yourself

If you’re a good tech lead, you can expect to be handed more responsibility—but there’s a balance between wanting to do more, and recognizing that it can take time to reap the benefits of that choice. Manage your expectations, but also set boundaries.

One thing that’s surprised me is realizing that tech leads don’t actually get a lot of time to talk to other tech leads. We have lots of meetings—across Mailchimp and within smaller departments—but there’s very rarely time to just ask someone, “Hey, what’s it like?” That makes it difficult to assess my version of being a tech lead. That said, getting group feedback on tech specs is perhaps my favorite part of the job, when everyone’s reading your work, commenting and clarifying. It’s the closest thing we have to peer review.

I’d argue that there should be an extra title after “tech lead” if someone’s been one for less than a year, because everyone has a different career beforehand and it directly influences what kind of mindset you bring to the role. I know the way I’ve been able to operate, and I’d like to do more of it, but one person’s version of being a tech lead won’t always mesh with another organization’s existing direction, in the same way that it doesn’t mesh when a React developer joins an Angular shop. And if someone asks me what’s next, I don’t know—but I do know that I wouldn’t enjoy this as much if I was just coding, and not able to also strategize and architect.

There’s more to being a tech lead than can be quantified in just the code you put out. You have to prove that your leadership has impact—that you’re closing your loops. Otherwise, what’s the point?