A reflection on leadership values and perpetual learning

The Engineer/Manager Pendulum is a concept that Charity Majors popularized in 2017 and has since become a pillar of many career development philosophies in tech. It recognizes the immense breadth and depth required to achieve excellence at being an engineer and a manager. It also posits that we can build competency in both by going back and forth between them throughout our careers without sacrificing development.

This year, I took time to reflect on how I ended up swinging on this pendulum and why I chose to follow my current arc with Upbound. While there is already a lot of excellent writing on these topics that I’ll reference throughout, I hope sharing my experience sheds some light on Upbound’s leadership values through authentic introspection.

I wanted to be an engineer forever

Let’s get this out of the way: I’m relatively early in my engineering management journey. One of the first things I told my manager at Upbound was that I was riding the E/M pendulum, and wanted to give this management thing a fair shake because I feel I’d only scratched the surface. He knew exactly what I meant.

Like many others, I was at a fork in the road as a technical lead a few years ago. I loved what I was doing and wanted to find the limits of my learning ability in a deeply specialized field. I also had some incredible role models of leadership that created the space for me to grow in the first place, and I wanted to learn how to pay that forward.

The more I expanded my network, the more I found myself increasingly far from being the smartest person in the room (I already never was to begin with). I noticed we succeeded as a team less when I made the right decision individually, but more when I entrusted the decision to the right individual.

This mode of operation clicked quickly:  I could scale it effectively by building our teams to work together instead of becoming heroes, becoming self-regulating over time. It was one of the first times I had to embrace impostor syndrome rather than fight it, beginning my first arc on the pendulum from Engineer to Manager. Simultaneously I jumped into a foreign land called the cloud-native ecosystem during one of the peaks of my career.

One of the first images I thought of when switching my career path to cloud computing.

Learning to engage as a manager

“Should managers be in the codebase?”

This question shouldn’t get asked as often as it does because it focuses on the wrong thing.

A common rationale is that healthy, well-composed engineering teams have enough aggregate experience to become autonomous. It creates space for managers to focus on execution, process, and career coaching and naturally makes them more in tune with the team’s core needs. You avoid the failure mode of overly-opinionated managers that risk disempowering engineers by controlling technical decisions, which can make or break teams.

The converse argument says that one of the most effective ways to build empathy for your team is through technical fluency. When engineers make difficult things look easy, we need to recognize it. We wouldn’t be able to do that if our skills were monotonically decaying.

Trying to process both lines of reasoning can be paralyzing to a new manager as they both have merit in theory. Did I choose the wrong path? Have I “frozen” my pendulum?

What if we changed the question to “how should managers engage with engineers?”

We would have to look at each engineer’s personal preferences, the things they value most, and what growth means to them as an individual. Fortunately, we have some excellent resources to equip us. We can develop their careers or partner with them meaningfully without resorting to arbitrary changes in the scope of their role or their preferred mode of operation. In our case, it was curating self-reflection exercises to determine what sponsorship opportunities we could create for them. Other times, it was joining the production on-call rotation when a team member was overextended. Perhaps my most memorable time seeing this in practice was watching a Twitch live stream where I learned about some of Crossplane’s build machinery and then applied that new knowledge to help onboard some community repositories to our Upbound Marketplace.

Engaging with engineers means immersing yourself in the culture, and sharing in both the joy and the pain. It doesn't capture the full scope of what we do and isn't terribly precise, but it provides intuition enough about how to build genuine relationships, and for some of us, how to keep our pendulums in motion.

The engineering manager at Upbound is a partner

Without avoiding the original question, every engineering manager at Upbound so far has contributed or reviewed code. These contributions:

1. Made something better for the team without the team relying on it happening.
2. Reduced stress for a team member.
3. Go through the same lens of scrutiny just like any other contribution.
   

This doesn’t mean Upbound will now create a policy that engineering managers must be involved this way— you won’t see this in a job description. It just means that we chose to engage the team in that capacity and did so in specific situations where we were in a unique position to help. The path to doing that work began with a question: “Would this be helpful to you / the team?” “Yes! I was actually pretty stressed out about that.” - that’s a clear response. Sometimes, the answer is a simple no. We learn to adjust to this stream of observations over time and as team membership fluctuates.

Engineering managers at Upbound are partners. The relationship we strive to have with others requires decisive collaboration founded on trust but expects us to challenge each other candidly. Engineers are not our implementers, and product managers are not our backlog prioritizers. We learn from them just as they learn from us, and learning happens when we can assume a default position that our perspective may be wrong.

Learning creates the perpetual motion of the pendulum

The concept of the pendulum I share most with others at a similar crossroads is that it isn’t an irreversible decision, even in exceptional cases. That’s part of the beauty of leadership roles: there’s no universal recipe to succeed at them. Even reflecting on our leaders here at Upbound with similar roles and job levels, no two are alike. Yet, they are all incredibly effective at what they do. From my manager, I’ve learned how to strengthen my frameworks on team composition and how to develop market intelligence. From our principal engineers and OSS maintainers, I’ve learned to be a better writer and gained a new appreciation for formal specifications and community dynamics. From the squads I am a member of, I’ve seen how each new perspective could be the next catalyst for innovation. All these experiences don’t tell me where I’ll hop off the pendulum next, but they keep it in motion through constant exposure to learning opportunities.

If I’m honest, I don’t have many original facets in my management philosophy - it is a mashup of role models that I have been fortunate enough to know both past and present. Will I get off the pendulum after this Manager arc, or swing back to Engineer? Only time will tell, but I no longer need to manipulate its path.

Interested in Upbound?

If my experiences resonate with you, consider joining our team. Not only do we uphold the values we hold all of our members to, but we go past them to build a cohesive environment— even while fully remote. We have various roles open for you to explore.