In January of 2021, I stepped into an interim leadership position. My leader had been asked to interim at the level above her, and so our team needed somebody to steer the ship for the time being. At that point in my five-year tech career, I was fairly intent on heading down the individual contributor (IC) path, but my manager entrusted me with the job, and so I decided to try my hand at leading an engineering team. What better, safer way to try out leadership, after all, than in a temporary position under the guidance of my current leader?
Those first several months were downright exhausting, but absolutely joy-filled, and so when it was offered, I jumped at the opportunity to stay in the position. By May, I was Director of Engineering for the Value Delivery Team at Pluralsight Flow.
I loved so many things about leading that team. Some of the highlights for me were:
Developing strong relationships with each team member. Through the constant exposure provided by weekly one-on-ones and frequent, impromptu video chats, I had innumerable opportunities to get to know everyone on the team on a personal level.
Suggesting and implementing team and process changes. As the team’s leader, this became less angst-filled, as I didn’t fear my suggestions might be perceived as critiques of how someone else was leading the team.
Advocating for my team when we needed time to prepare for a project or initiative by upskilling.
Despite experiencing these joys of leadership, though, in the end I couldn’t figure out how — in 40 hours a week — to manage my engineering team and deliver value to customers at a quality that felt good to me. I knew I could do a good job in that role in 50 hours a week, but I had never been bashful about publicly declaring myself a “40-hour-a-week kind of gal.” And as my relationships with my teammates grew, I felt my commitment to them grow, as well. In the end, I didn’t feel it was the right thing for me or my team to stay in the position.
That, and I missed coding. As a leader, you quickly develop what I call “calendar envy”: that feeling you get when scheduling a meeting and (despondently) coveting the relatively empty calendars of the ICs. I rarely had more than thirty minutes between meetings, and new meetings could pop into my calendar with less than five minutes' notice. Over time, I increasingly craved those three-to-four-hour blocks of focus time to bury myself in a technical problem. I missed creating. In a sense, I missed writing.
As a leader, you quickly develop what I call “calendar envy”: that feeling you get when scheduling a meeting and (despondently) coveting the relatively empty calendars of the ICs.
I’d be lying if I said I hadn’t thought about stress-quitting once or twice, but in the end, I couldn’t face the thought of leaving my team, this group of people that I’d come to adore. And so, in late November of 2021, I asked my leader if I could move back into an IC role. She gracefully honored my request, and in January of 2022 — a year after I first stepped into that interim role — I began the process of onboarding our new leader and dipping back into the codebase.
What I’ve found since transitioning back into a pure engineering role is that because of that year in leadership, I’m a better, more confidant IC than I was before. Following are some of the ways in which I believe leadership has made me a better IC.
I better value my relationships with my teammates
Because I spent a year working closely with each member of my team – getting to know their goals and anxieties, their strengths and their weaknesses, their interests and lives outside of work – I now have a really strong relationship with each of them. I know them and I like them as people. As an introverted IC, I might have developed this deep relationship with one, maybe two of my teammates, or — given that we’re a fully remote team — potentially none at all. But as a leader, we were essentially forced to interact frequently, and I’m so, so grateful for that.
How has this — dare I say? — friendship with my teammates made me a better IC? For starters, I feel a deep sense of camaraderie with them that I’ve never before experienced with colleagues. I know what makes them happy and unhappy at work, because during one-on-ones with them last year, I asked them, “What makes you happy and unhappy at work?” Because I know this about each of them, I know how I can positively influence their workplace happiness, which — yeah — is important to me! And I would argue should be important to all of us.
I’m also a better cheerleader for them as they pursue professional growth because I know what their professional goals are. For example, one of my teammates expressed last year that they do not feel comfortable leading meetings. And so as I’ve seen this teammate successfully lead meetings over the last several months, I’ve offered (sincere!) congratulatory messages to help affirm their growth in this area.
In sum, this closeness I feel to my teammates makes me work harder with them and for them. It makes me less likely to leave this company if the going inevitably gets tough. And it makes creating software products with them feel truly the communal activity that I think coding is at its best.
Takeaways for ICs: Find ways to get to know your teammates on a personal level. Rather than sitting quietly at the beginning of a standup or team meeting, talk to each other. Even better, schedule periodic one-on-ones with your teammates just to chat and catch up. Even if you don’t have anything in common at first glance – and even if you have to engage just a little bit in the small talk that engineers claim to so vehemently abhor – the bonds that grow from these interactions will strengthen the overall team’s bonds, and they might even provide a reason for you to stay on your team through the inevitable challenging times at the company.
I no longer hesitate to suggest team process changes
If there’s anything that leading a team for a year taught me, it’s that a team’s continuous improvement requires continuous change, and teams are healthier when each and every team member takes initiative in driving that change.
Formerly, I felt disempowered to drive this change as an IC. This was primarily due to unfounded anxieties around “stepping on toes.” But as a leader, you know that the team’s processes are not perfect, and you know that bad processes can lead engineers to become frustrated and quit. I’ve been there, myself.
But you also, as a leader, simply do not have the time and bandwidth to constantly poll for changes that the team would like to make, and even less to successfully implement all of those changes. So when the ICs on the team take ownership in identifying and enacting change for the team’s improvement, it doesn’t feel like a critique. It feels like a gift.
One example of how this manifested on my team last year was around the management of our deployment pipeline. For months, I was the only member of the team who deployed code to production. My rationale was that it was rather onerous, and sometimes nerve-wracking, and I simply didn't want to put my engineers through this.
When I asked the team for feedback on how we could improve our team processes, though, a few of them brought up that they didn’t think I should be the only one deploying to production. They (correctly) argued that I was devaluing my own focus time, and that it was actually a detriment to the team that we all not share this responsibility.
This feedback was such a gift. I was actually tired of managing the deployment pipeline, and I knew it was inefficient, and I really just needed someone else to say it out loud. A couple of our team members took the initiative to learn the deployment process, and then taught their teammates how to do it. A few of them even identified and then fixed inefficiencies and redundancies in our deployment pipeline. Today, everyone on my team deploys code to production, and it takes a quarter of the time that it used to. We have one of the highest deployment frequencies of any team at the company. And if those individual contributors hadn’t spoken up about this broken part of our process, we may never have changed for the better.
Takeaways for ICs: Don’t assume that your leader thinks they're running the team perfectly. They are likely in a leadership role partly because of their commitment to continuous improvement, and they need your help in continuously improving the team. When you see opportunities for positive change — especially when those changes have the power to increase the team’s efficiency and developer satisfaction — suggest them! Be tactful about it, of course, but don’t withhold this gift from the team. And perhaps take it a step further and ask your leader what you can do to help implement that change.
I recognize when I need time to up-skill, and I feel comfortable advocating for that time
I think the biggest gift that my year in leadership gave me was understanding that the imposter syndrome I constantly experienced as an IC was unwarranted. As an IC, if I didn’t know how to complete a task, I wanted to hide that fact from as many people as possible, especially my leader. The result was paradoxical: I hesitated to ask for help, lest I should reveal my incompetencies, but because I refused to ask for help, I ended up working overtime - just to have to ask for help in the end. For me, this led to burnout on too many occasions, and my resulting slow delivery times were ultimately a detriment to my team.
As a leader, I never expected any member of my team to know everything about the languages, frameworks, and libraries we use, and I certainly didn’t expect them to know how to complete every task before they actually completed the task. In fact, most projects my team worked on required some amount of technical learning and up-skilling, and not only was I happy to advocate for my team members’ up-skill time as a leader, I was also incredibly grateful to my ICs for setting reasonable expectations around the speed at which something could be done. When engineers are honest about needing time to ramp up before diving into their work, it allows the wider product team to accurately predict and communicate completion timeframes. When they’re afraid to admit what they don’t yet know, however, they tend to underestimate completion times, and the result is missed deadlines and team-wide dissatisfaction.
As an IC, if I didn’t know how to complete a task, I wanted to hide that fact from as many people as possible, especially my leader.
Late last year, an engineer on our team was honest with me about their need to upskill before tackling a complicated and high-stakes project. I was delighted that they were honest about this - it allowed me to set expectations for our product team around what we could communicate to customers. They took several days to read and learn and ask questions of teammates before diving in to code a solution, and guess what? We delivered that project earlier than expected, and with far fewer glitches than expected.
Before I led an engineering team, I would have been embarrassed to ask for a couple days to “study” before starting to code a solution. Now I know that it’s okay to be honest with my leaders about what I don’t know (yet!), and what I think I’ll need in terms of time and resources to up-skill.
Takeaways for ICs: Shed the “fake it till you make it” mentality and be honest with your leader and teammates if you need time to learn before jumping into a task. You’ll avoid over-promising and under-delivering. You’ll protect your personal sanity and better avoid burnout. And perhaps best of all, by the time you complete that task, you will have more deeply acquired the requisite knowledge and skills, which is not only a win for you professionally, but a win for your team, as well.