Adventures in the Life of an Engineering Manager: From Developer to Software Manager

Throughout my career, I’ve developed a number of interesting engineering solutions that would be worth discussing. One in particular that stands out is the solution to “how would you structure a system where shared content (with a relational structure) can be created by users across their multiple devices in addition to supporting both an online and offline capacity?” While this would show engineering innovation and communications skills, it was quite a while back and doesn’t reflect my current career trajectory. What is more recent and more relevant is the management principles I’ve reflected upon that comprises the basis for my management style. Another factor in choosing this concept is that while it helps guide my daily decision making, this isn’t something that really fits on a resume.

Into the Fire

I had been a programmer for a while and would usually be the go-to guy for questions in many situations. I was ready for the next step and wanted to see how I would do managing a team. Being a developer is rewarding and something I never want to completely be away from, but keeping on top of the latest trends and always being at the top of my game required a lot of energy. What's attractive about management was that the promotion path is both easier and better paid. But would I like it. Was that who I was? Well, I wanted to find out and was able to convince enough folks at one particular company that they were willing to give me a shot at a tech-lead position. A tech-lead position is being responsible for the timelines of a project, and maybe also for developers (or more) but without having any actual HR (Human Resources) authority. Basically, it's having the responsibility of a manager without being in control of the traditional HR part (reviews/hiring/pay rates/etc.). Usually, you'll have the influence, but not the actual authority. If something goes wrong though, you'll certainly hear about it.

Background

Midway through the first year of managing a team at Comcast, I had received feedback from one of my employees that I wasn’t consistent in my decision making. There’s a lot of incoming requests to sort through on a daily basis and maybe one day a particular project might seem more important than another. Consistency is important because it helps to provide psychological safety which is an important component to being happy at work. So, I started to think about who I wanted to be as a manager. My goal was to come up with my five most important values so I could make better and more consistent decisions, communicate these values with employees, and hope these values could provide direction for their decisions in cases where I wasn’t available.

A bonus for having these values in a priority order was that it could provide a foundation for making decisions throughout the day. I could use it to cut out cruft and perhaps provide order to the chaos of daily managerial life at Comcast. By choosing five, I could focus on a different one each weekday.

Themes

What would be the most important theme? Well, at the end of the day, any engineering solution needs to serve a customer, and without a customer, there is no functioning business, so this one was easy. The first value would be Customer Experience. What can I do each day to serve the customer? This could be to help with a customer issue, review customer feedback, resolve a coding problem, contribute to a meaningful feature, etc.

To serve customers, you need employees. Due to preferential treatment for other teams and a tight department budget, the Android team had a history of turnover that I wanted to address. We didn’t want to have to rotate in new employees to replace existing unhappy employees. A better solution would be to keep those employees we already had from wanting to leave. Developers that have growth opportunities or like what they do, don’t want to leave. Growth and Developer Experience would be the second value. Growth for those that want to improve their skills and get promoted and make the day-to-day experience better for those that may already be high performers that are happy where they are and don’t want to change. For growth, I would focus on making sure employees had clear path for the next step in the career that I and they would advance. Examples: working on critical projects, putting in positions to be noticed by senior leadership, having a clear list of measurable goals for the year in line with company principles. For developer experience, some things I would focus on would be: efficient meetings and processes; an open environment for regular feedback; ensuring the tools developers needed were available, effective, and efficient; and that the teammates worked well with each other.

One of my personal goals is to lead a world class engineering team. Now that we’ve established customer and employees, one important component of a world class team is doing great work that you are proud of. The way to do that is to focus on Excellence. The team would be made aware that they are expected to deliver excellent work. Measuring would be a little tricky but one simple method is to track and limit defects that are released into testing or production. Another would be keeping track of code-health in terms of how easy it is to understand and change the code after six months.

In the mobile world and Comcast in general, things move pretty fast. We need to have a good architecture base to handle new product requests in a timely manner. Team members would need to think about Vision and how they can prepare the product for change or better position the team for future needs. Team members would be challenged to demonstrate solutions for large scale features, innovate with new technologies, develop reusable modules, and help make future solutions easier.

Finally, if we’re doing well with all the above items, then we should be able to be trusted to provide features when we say we can have them ready. We want our commitments to matter, so Delivery would be the last value. Team members are expected to compare their expectations with what actually happens so that we can have a predictable and feasible workload.

I've Got So Much Work To Do, Where Do I Start?

Now that we've identified our management themes, we'll be able to look at incoming work and requests to see if it aligns with our themes (and subsequently is important), or whether it doesn't align and maybe is even just a distraction and can be done later.

This brings us to part 2 which is to build a daily routine and triage process for incoming requests that allows us to meet the most important needs and ignore others. Management doesn't have to be an anxiety driven free-for-all with sleepless nights. It's a job that can be rewarding and enjoyable. The simple fact is you can't please everyone and if you try, you'll likely end up needing counselling and anti-anxiety drugs. No one is superman and that's not sustainable over a long period of time. If you're in a place where that's expected of you all the time, my advice is to either change that expectation or find a new place to work for your long-term survival and happiness as a manager. Accept that you have to pick and choose who gets the team's precious attention. Not every request is going to make the cut and that's OK.

Part 2: Let's look at how to apply the Eisenhower Principal using these themes