Building vs. managing: Why I took a step “back” into a builder role

The shift into engineering management was slow and subtle, but through the process, I became more aware of the differences between being a builder and a manager.

My journey into engineering management started back in 2012 when I began working on an internal product to monitor customer feedback at Amazon. I worked on this project for two years, and it grew to a point where a team of two engineers wasn’t enough. We started hiring. I began mentoring one intern, then another, and six months later, my title changed to Software Engineering Manager. At that time, my work shifted from day-to-day coding to recruiting, galvanizing the team, convincing people to follow the vision, and holding weekly one-on-ones. 

While it was an exciting ride, after four years in the role, I felt more and more burned out by managerial tasks by the end of the day. Perhaps some of you can relate, but as an introvert, working solo on challenging complex problems would recharge my battery. Meanwhile people management tasks depleted my energy. As I wrestled with balancing energy-charging vs. energy-depleting activities, I found myself yearning for the early stages of a product. That’s where my journey took me “back” into a builder role. More on that later, but today I wanted to cover some of the differences between working a manager’s schedule and a builder’s schedule.

Inspired in part by Maker’s Schedule, Manager’s Schedule by Paul Graham, here are my takeaways from working in each role.  

• A Manager’s Schedule

• The Switch to Builder

• Final Thoughts

A Manager’s Schedule

Rallying people

One of the top priorities in a manager’s role is to rally people behind a mission. My training in that regard came from participating in hackathons. As a hackathon team leader, I practiced pitching ideas and learned to rally people behind an idea that I was passionate about. Those skills came in handy when the product we were building showed early signs of traction. I realized that the only way to deliver on our expanding vision was to hire more engineers. That vision motivated me to get out of my comfort zone and relentlessly sell the opportunity to my future teammates and stakeholders.

Always learning, but topics change

Similar to how software engineers are always learning, the management journey provides plenty of learning opportunities — the topics are just different. There’s a general shift away from learning technical subjects to management topics. It’s simply too difficult to keep up with new technologies and technical stacks; it's more worth your time to learn how to best support your team.

Amazon is famous for its written culture — eschewing PowerPoint presentations in favor of dense 6-pager documents — and the bulk of my time as a manager was spent writing and rewriting documents. I learned how to draft a roadmap, a promotion document, or an effective email. I discovered what "weasel words" were and trained myself to spot them in my prose and replace them with metrics and specific commitments. I also learned how to advocate for headcount to be funded on the team, plan multi-year projects, and coordinate cross-team projects.

As with any new learnings, there are bumps along the way, so I highly recommend finding peers with whom you can hold conversations during the transition into management.

Don’t be a hero

There came the point where I had to shift away from coding to better support my team. It became my number one priority to make sure my team felt supported in their personal growth and development in their role. I would make sure my team aligned with the mission, progressed in their technical skills, understood their work, and stayed engaged. 

My time was better spent on management tasks. If I were not advocating for team impact, my team would suffer. Likewise, I had to be ready to help someone who might be blocked rather than dive deep into a coding task. I had to adapt to become reactive at a moment’s notice, while my work as a builder required long uninterrupted days to solve complex problems.

When you relinquish your role as a manager to be a builder, you cause other things to break. Your team misses out on learning opportunities, they become exposed to external pressures, and overall trust is broken. It’s a challenge to stop yourself as a manager to try and solve a problem you know the answer to, but it’s worth it to give your team space to do things right. 

The Switch to Builder

Knocking down imposter syndrome

After working several years in a managerial position, I found myself missing some of the excitement behind learning new technologies and languages. While I once felt strong about my technical skills, I noticed my skills were beginning to get rusty. Coupled with my growing sense of burnout, the imposter syndrome started to settle in. 

Call it a perfect storm or the stars aligning, but I found myself with the opportunity to work at a small five-person startup. Filled with a growing sense of nostalgia for technical work and an urge to get back to the early stages of a project, I took the chance and joined as a founding engineer. 

I openly shared that my skills were a bit rusty and needed some time to get back in the saddle. There’s something different when your survival as a company depends on what you build and what you don’t. I stayed there for about a year, practicing code, and really enjoying the team. I then decided to move to a later stage startup, AngelList, to get a broader perspective.

A step back to move forward

As previously mentioned, I typically draw my energy from working solo on hard complex problems for days at a time, while managerial duties deplete my energy levels. To break that cycle, I had to relinquish my managerial responsibilities and go on a builder sabbatical. 

With five days a week dedicated to managerial tasks, I couldn’t get deep hands-on experience in the technologies that people were using and learn the architecture for a technical stack. I became more curious as I noticed some features took significantly less time to build. Now that I can dedicate 2-3 days a week to deep engineering work, I’m amazed at how fast the development landscape has changed over just a few years.

I’ve participated in over a dozen hackathons, and I’m always drawn back by the excitement behind building something from the ground up. Being a software developer puts me in a position to use my hands to be at the root of innovation. From there, I hope to continue to expand my skill sets and apply them to projects I’m passionate about. Who knows, these projects could show early signs of traction as well!

A 90 degree turn

As much as I made the switch to work as a builder to code, working at a startup allows me to flex my managerial skills. Having led teams in the past prepared me to fill the gaps I notice as a team member. When a meeting gets derailed, I volunteer to bring it back on track. I share and implement processes that served me well as a manager. I also continue to mentor and onboard people. No matter your title, it’s always essential to help support the team’s growth by helping others grow in their role and being a part of their progress of learning on the team.

On another note, I like to think that I have more empathy for my current managers, having walked in their shoes. I tap my previous experience and play the role of a sounding board to help them navigate their management priorities.

Final Thoughts

For those exploring engineering management, look for opportunities to learn and mentor. It’s these two things that have made my journey interesting. 

For engineering managers looking to sharpen their technical skills, there are other ways to keep your skills up to date aside from jumping back into the “builder” role. Participating in hackathons, doing code reviews, and mentoring can be great opportunities to keep your technical skills sharp while balancing your managerial tasks. 

Since joining AngelList as a senior engineer, I’ve stepped back into the role of management as an engineering lead. While my new role leans more towards “A Manager’s Schedule,” my journey in stepping “back” into a builder role helped me lean into what I loved and what gave me energy for this next step. In doing so, I’ve also picked up new skills that would make me a better manager and allow me to pursue projects I’m most passionate about.