From Engineer to Manager and Back Again

by Daniel Orner, Staff Engineer at Flipp

“Some are born great, some achieve greatness, and some have greatness thrust upon ‘em.”

— Malvolio, Twelfth Night II:5

So what does the term “team lead” mean to you?

Many moons ago, I joined Flipp as a senior software engineer. At the time, Flipp was still a relatively raw startup, with under 40 employees. Coming from an enormous multinational conglomerate, where after five years I was still considered a “junior” employee, the title change was a nice surprise.

I found myself in a small team where I could make a huge difference. We were tasked with improving and adding features to “Fadmin”, the “flyer administration” system which our in-house operations team used. As time went on, I became more confident in my role and started mentoring other, more junior devs. I took part in more conversations with our stakeholders and liaised with other teams, as well as taking on coaching responsibilities. I did more design and architecture work. I tried to make sure we were iterating and improving our sprint and JIRA process. In early 2016, I got another pleasant surprise by having my job title automatically bumped up to “Team Lead, Software Engineering”.

This felt nice.

At the time, our team makeup was as follows:

• A team lead — me;
• Four other devs and two QA developers (as they were called then — we now call them Software Engineers in Test);
• A dedicated Product Owner
• Contacts on our in-house Operations team who acted as stakeholders.

The Product Owner was not only responsible for defining what we should be working on and prioritizing it, but was also in charge of “delivery”. I consider “delivery” to refer to ensuring that the team is working well, that there are no blockers with other teams, that there is no confusion with the requirements, that we do the things we say we’ll do, etc.

My own coach was a Director of Engineering, who was involved in both the technical and the “people” side of things and helped coach me through coaching, among other things.

This was my calendar in February 2016:

And here’s what it looked like later that year:

Part of this was due to the fact that my team and its responsibilities were growing. We had started a brand-new project which was going to demand more of my time. Essentially we broke out a separate sub-team which I was also responsible for. Our company was also expanding rapidly in its size — probably too rapidly.

This trend continued for another year, at which point I was the “architect” for no less than four separate sub-teams, with almost 30 people in total. By late 2017, my schedule was almost entirely meetings and nothing else. This was despite the fact that my original team still did not have a senior dev on it. I was still responsible for making most of the technical choices and mentoring the junior devs. I was sad that I couldn’t give everyone my full attention, but still felt elated that so much responsibility was being trusted to me.

During this time, Flipp had been making an effort to better define its roles. Team Lead was a tricky one. They realized that the benefit of a Product Owner would be better realized by allowing them to take a step back and think bigger-picture and longer-term. The day-to-day duties which the Product Owner used to have were put on the Team Lead and/or a Scrum Master, depending on how many we had and which teams had them.

We also realized we had to get better at coaching and performance management. This became a focus of the Team Lead role as well. This was done without actively reducing the existing expectations of a Team Lead to be the “most senior engineer” on the team, and responsible for all the architecture and technical decisions as well.

Eventually, this definition broke.

We realized that having a single person be responsible for so much simply wasn’t feasible. The Team Lead role transitioned from essentially being a technical lead role in 2016, to an “engineering manager” in 2018. The main focus of the role was now on “people” (performance management, coaching, and growth) and “delivery” (ensuring things weren’t blocked and were delivered on time). We introduced a new “Tech Lead” role which we slowly rolled out to other teams as a way to allow someone other than the team lead to focus on the architecture, design and implementation.

Like the proverbial frog in the kettle, the changes to the role definition happened so slowly that I didn’t quite realize what was going on until I started boiling.

The key event which made me realize that I was no longer what I wanted to be was a negative performance review. We had had a difficult term, and I was shocked to get my first “bad” rating, largely due to delivery issues. Part of this was due to confusion about my responsibilities, but that definitely wasn’t the full picture. I was wearing so many hats that my “team lead” hat, which was my primary role, started falling off.

“Shock” probably doesn’t quite cover the fullness of the reaction. Not only was I sad that I had messed up, I was also angry that I hadn’t seen it coming. It took me several days to be able to think about anything else.

Several weeks later, my coach and the VP of Engineering sat me down in a meeting and said to me that they’d realized they never actually gave me a choice about whether or not to be a Team Lead. They asked me the honest question: “Is this what you want to do?”

I took the question hard, and entirely the wrong way. My response was, “Do you think I’m incapable of doing my job?” I was both scared that I was failing, and insulted that they’d think I was.

At Flipp, we have long had two tracks for career progression. The People track led from Senior Engineer to Team Lead to Director. The Technical track led from Senior Engineer to Staff Engineer to Principal Engineer. However, we had about three times as many Team Leads as Staff Engineers. The idea that Staff was just as achievable and just as important as Team Lead wasn’t something that had sunk in.

We had a lot of resources to help out with things like delivery and coaching. We’d done training seminars and changed our focus. I thought that with help, I probably could be a good Team Lead. But I thought back on the times when I really thought I was making a difference, and when I really enjoyed my work, and those times were not when I was doing performance management, one-on-ones, interviews, or (shudder) performance reviews. I simply couldn’t keep a birds-eye view on the team when I was also knee-deep in the weeds on the technical side.

After much soul-searching, I told my coach that I didn’t want to be a Team Lead any more.

This was a hard decision. There were (and are) a number of things I really enjoy about being a Team Lead. Being responsible for team culture and team health is something I think I was good at — we were a very close-knit group, and I felt my other devs looked up to me and appreciated me. I enjoyed being in meetings with other leadership people, being part of discussions that were basic to how the company functioned and helping to define roles and point to improvements that needed to happen around communication, compensation, policies, etc.

But the fact that I now realized that in order to be effective, I needed to spend all my time in this headspace and leave the technical side to others, made me realize that it simply wasn’t what I wanted to do.

I also had to admit that I was, you know, bad at something. Or at least not as good as I needed to be.

It took months to find a candidate willing to replace me as Team Lead. His leadership style was and is vastly different from my own. One of the first things I realized when my new team lead had established himself is that I had been running the team as my own fiefdom. As both the senior technical dev and the manager, I made all the decisions and, while (I hope) I listened to feedback, I had the final say in everything. Having to make myself accountable to others was something I found I hadn’t been used to doing and was an essential skill I began to put more effort into.

It was also really interesting to work with a team lead instead of as a team lead. Because of the way the role changed over the years, I’d never really had my own team lead at all. Working closely with one allowed me to see not only my shortcomings but also appreciate the things I’d done right and learned well during the role. I was able to both give useful feedback and understand why the decision I made was the right one.

I also realized that many of the things I enjoyed didn’t go away. I still act as a mentor to others on my team and I am still part of conversations which help to define how we as a company think of ourselves. I spearheaded a Tech Lead (now Tech Head) group with other tech leads across the company to drive technical discussions and improvements, and this filled much of the void I was worried would open up as I slowly left the Team Lead space.

Do I regret being a Team Lead? Hell no. I learned an incredible amount in a few years which I’d never have gotten the chance to learn otherwise. Part of that was understanding which of those things appeal to me and which I’m more comfortable leaving behind.

In the end, what I found most important was to ask the question, “Do I enjoy what I’m doing? If so, why? If not, why?” We all must grow in our work, make mistakes, and learn from them. If you find work stressful because you’re not good enough at it yet, the answer there is to get resources and help until you are. But if it’s because the work doesn’t speak to you and isn’t where you want to spend your time, see what you can do to change that.

We work in a creative field, where we are incredibly fortunate to be able to feel fulfilled by what we do. We don’t do manual labour or even professional work like accountancy or law where it’s all about following the rules. We want to make a difference and in today’s market, we have the freedom to choose the kind of work that best fits our strengths and interests.

Go out there and be you.