Red Green Repeat Adventures of a Spec Driven Junkie

Failure: Trying to Balance Being An Individual Contributor and a Manager

I am sharing learnings from one of my failures: when I was transitioning from being an individual contributor to manager and couldn’t balance out another manager’s request for work.

I share the situation, my thinking, what failures I encountered, and lessons I am taking away from the situation.

If you transitioned from being an individual contributor to managing the team, you will learn one of my experiences where having the individual contributor experience hinder me as a manager.

This article will take you about six minutes to read.

Charles E. Weir - The Wood Sawyer source and more information

Introduction

I was about a year being the manager of the team. Originally, I joined the team as an individual contributor and then promoted to managing the team.

It was my first time being a manager and I approached the new role with the goal of continuing to contribute, as I was one of the biggest contributors to the team and I can balance out that workload with my new role.

I set out to split my time: 50% “managing” and 50% “contributing”. That would mean I have meetings, make decisions on the work, and have responsibilities to deliver stories for the sprint.

Smooth Sailing

This balance worked, I enjoyed having a bigger picture understanding of the work contributed to the organization’s goals by being in planning meetings and seeing how the system worked gave me a clear understanding the effort new features would take.

A product manager started asking me about doing a revamp of an existing part of the system. The current solution worked and was part of the system before I even joined the project.

The product manager asked the design team to draft out work, make screens, and workflows for this revamp. There were new interactions and from my understanding of the system, require using libraries or coding into the framework that none of my team worked with.

Reviewing the new designs, the revamp didn’t blow away the existing work, just added a lot of work onto the team for marginally better result. I couldn’t justify the revamp work, especially with all the other work queued up which the team would be able to deliver better and no alternatives were there.

I said no politely and it would be a lot of work for such little return. I brought up deprioritizing other work in favor of the revamp work. That discussion did not go anywhere, so I kept my original answer.

Pivotal Moment

The product manager was insistent the revamp is essential and kept pulling me into meetings to discuss it, with each new meeting, adding another party. After the third meeting in three days, I hit a breaking point and just said:

NO! This revamp is too much work for replacing existing functionalty. Spending resources on new functionality makes more sense than reworking existing functionality.

After this, the product manager was not pleased and went directly to my boss with my answer. My boss called a meeting with me, the product manager, and their subordinate to clear the air on this revamp request.

My team didn’t take on the revamp work and another team took it later on. The other team was better poised to handle it and my team continued with their queue of work.

What did I Fail at?

As I was still spending 50% of my time contributing, I considered any new work placed on the team to be the same as increasing my individual workload. The amount of time I could contribute work continued to diminish with added managerial responsibilities.

As a new manager, I was still in the mindset of: the best way to get tasks done is to do it yourself, which is true as individual contributor.

Another thing I did not know: to get tasks done as a manager is by getting the best resources in your organization to do the task, not doing it yourself. Hence, the project manager asked for support from the design team on the revamp.

How did I Fail?

First, I didn’t understand how managers really worked, especially when in a pure people role. As a former individual contributor to the team, I expect the transition to be smooth.

Another was overcommiting myself to contributing and managing the team. The frustration of having less time to contribute because I have to dedicate more time to meetings.

Last, conflating my workload with the team’s workload put me on the defense when asked about taking on new work. I saw my workload already overloaded, not being able to alleviate my workload added to my frustration.

Why did I Fail?

Even though my title is a “managerial-level” title, I still had a mindset of a individual contributor that would have less “contribution time” and increasing insight to mountains of upcoming work. I wanted to use my new role and stop this imbalance at the source, with the product manager and the revamp.

At the same time, The product manager was treating me as a manager of a team with resources to get work done. Just like he asked the design team to build out their vision of the revamp. I didn’t have this mindset as I was still thinking about how to do the work myself.

Finally, not understanding how managers work with other managers. This was probably my first time another manager engaged me at a managerial level and not as an individual contributor. Carrying the mindset as an individual contributor hampered my decision making ability as a manager to objectively evaluate work for the team, not looking at my own workload.

What did I Learn?

The team’s workload and my own workload cannot be the same. The organization’s expectations of a manager are different than an individual contributor. From this experience I understand why one cannot manage and contribute.

Another is if I want respect as a manager by other managers, I need to manage the team’s work, not contribute work like the team. (I can’t set the contribution cake and eat it too.)

How will I Integrate these Learnings?

Priority 1: Manage the team.

Seriously, if I have any extra time, manage the team. Even if I can “contribute”, that should be the last resort to ensure the team meets deadlines and deliver great results.

To ensure I contribute less, intentionally not having a fully working version of the application on my computer to prevent me from tinkering with code and force me to pair with team members to try out solutions, even simple ones.

Why won’t this happen again?

Managing the team is my focus as well as building relationships with others in the company, especially those that work closely, like this product manager.

I believe if I answered their request for a revamp with:

Yes, this is a good idea.

The following meetings would have a different tone.

If I Could Do It All Again?

I would tell myself that even though you got promoted from being an individual contributor on the team to managing the team, continuing to act like an individual contributor only hurts the team.

“What got you here, won’t get you there”

Also, even though there is conflict with others, they are trying to help you and the organization. They probably work and communicate differently than what you’re used it.

When conflicts happen, step back, slow down, think about the bigger picture. Be open to differences in communication and work styles.

Conclusion

Conflating my workload with the team’s workload caused me frustration when the product manager asked me repeatedly to take on revamp work.

I learned the work style of a manager is not the same as an individual contributor, no matter how much the manager knows about the work.

At the same time, a manager should focus their efforts managing instead of trying to contribute - those are different skills and don’t always align well.

The project manager help me realize this and how to work with other managers to get work done.

Most importantly, I learned to focus my efforts to being a manager and let my team do what they do best: contribute great results.