Ad
LinearB - Free Dev Tool

Start tracking team-based engineering metrics like Cycle Time, Deployment Frequency, PR Size, and more with LinearB’s free forever dev tool.

Try it today at LinearB.io

Hello! What's your background and what do you do?

I started out doing desktop support and network administration about 13 years ago. I became a systems administrator and engineer as a result of wanting to automate a lot of my work, and ended up writing software for macOS and iOS while I was at FedEx Services. When I came to Uber in 2014, I was responsible for building and deploying our driver mobile application and administering the CI build infrastructure for all of our iOS applications. After several years as technical lead for our iOS CI system, I moved to the self-driving division to work on CI infrastructure there as well. I became a manager in early 2017 and built an infrastructure team. I recently joined Aurora as part of the acquisition of Uber ATG and manage the Infrastructure and Developer Experience teams.

I currently work at Aurora Innovation, previously Uber and FedEx Services. I did not study CS, and was self-taught with much of the scripting or programming work I've done.

I can't really say that I've written software for any period of time. Typically when I end up working with depth in software, I'm tackling a problem directly and going deep in that area. I've been managing systems for almost a decade though, using configuration management and automating with scripts and other tools. My focus in CI systems was primarily centered around iOS mobile application development, but is now focused largely on supporting ML training and inference workflows for teams like Perception and Simulation at Aurora.

I've been a part of the logistics and transportation industry for most of my career, mostly accidentally 😅, but I would say I've been a back-and-forth part of the iOS developer community for a few years, and consider myself a MacAdmin in that community as well.

How was your transition from software development to management like?

I can't say that I've had a traditional path related to technical work, but I feel that engineers who transition to managers typically do so out of two common pathways:

  1. They excel at technical architecture and work and are asked to manage their colleagues to scale the team or,

  2. They are naturally organized and tend to look after other engineers while doing technical work, and often pick up project management or similar coordination skills along the way.

There might be other situations where this has occurred, but these are the ones I've found most prevalent.

In the two occasions I've been asked to become a manager, my transition took place under the second factor above. I tended to be interested in organized project work, and was able to knock out technical work quickly or rally others to help make that happen. Naturally the transition was overwhelming especially to my calendar, and took me away from technical tasks that required deeper focus. When transitioning to manager, I had a few important realizations. About a few weeks into my management change, I realized I now had colleagues who were depending on me to advocate for their work. Related, those same folks were also depending on me to facilitate their growth, whether that was promotion, coaching, or other opportunities to lead or have impact. It became important for me to develop my management personality along the way, and because I valued authenticity and transparency, those became a big part of how I show up every day. Another transition experience that many folks have is learning to delegate and empower as opposed to doing and directing — this remains the hardest challenge for me today.

The second time I became a manager was during Uber's hardest year in 2017. It was a difficult year to become a manager and came with a lot of growth in understanding the cultural issues the company was having at the time. In addition I needed to learn a lot about my diverse colleagues and their experiences as engineers in that environment. At the time we had very little training for managers, but having experienced unfortunate results of that lack of training myself over the previous years, I felt uniquely positioned to help drive cultural change and find positivity during the difficulty. This helped me develop personal resilience and learn to be adaptable, which is a learning experience I often share with my teams today.

My transition was mostly organic. I had a hands-off manager who was very selfless and supported my transition into leadership. He was also pulled in a lot of different directions due to the ridiculous growth curve of the business at Uber. Because of these factors, much of the execution of our team's work was left to my coordination, as well as meeting with customers and stakeholders and being involved in strategic technical projects.

I would say I've spent about 60% of my career over 14 years as an IC, and about 40% as manager. In both cases, my transition to manager took about 6 months, which I think is good so you can learn from other managers and have the positive experiences and realizations I mentioned above.

Both times I became a manager there were organizational leaders who were looking to fill gaps in both our management scope and areas of technical need. In the second case, I was thrown into the role a bit more than the first case, and this was out of stronger necessity and large gaps in ownership in our organization at the time. In 2017, we had no infrastructure team focused on the needs of my organization, and this was slowing everyone down across the group. I had strong direction from good leaders that helped coach me into building a small organization, not just a team. I had 2 engineers on the team when we started, and for that group we have about 30 today.

What does your day-to-day work look like, and what motivates you to do it every day?

I don't currently write code on a regular basis (outside of personal projects), but I do find myself getting into the monorepo and some systems to dig deeper into metrics and/or areas I have questions about that I think are fairly easy for me to answer myself. Otherwise, my days are pretty involved with meetings; I try to invest heavily in 1-1s with both direct report managers and senior ICs. One important aspect of these investments is making sure that everyone feels comfortable giving feedback, communicates clearly together, and is aware of what's going on around them. These meetings are also spent helping with personal growth goals and areas that my team members are concentrated on for their own development.

Because of the size of our team, I find that I am a very mechanical operator and like to review the outcome of our 2 weeks "sprints" with the team as well as have organizational health round-tables with leads on the off weeks. In those meetings we talk about hiring, recruiting, gap areas, resource planning, and team building. We also use these syncs to talk about stakeholder meetings and make sure to share internal customer feedback and learnings with the broader group. These are pretty unlike the tactics I used as an IC because I had far less scope to manage and fewer teams to interact with in those days. A large part of this cadence serves the purpose of scaling myself as much as it is also benefiting the team as well.

I also spend a fair amount of time with stakeholders; either internal customers using our team's systems or other leads in our organization who need my help solving related challenges of generally running the company. This is typically our finance team in my role and happens because of the role we play as a platform team—wherein we are tasked to provide tools or solutions to our organization's engineers. Providing tools or solutions can sometimes land on a build vs. buy decision process, and in the case of buy we have some work to do to evaluate options, document our rationale, and close the procurement of the tools. As a manager, you tend to have to help your team with these decisions on where to expend resources or money, and the choice to spend money typically comes with a justification or other process to acquire the artifact of expenditure in question.

What are the biggest challenges you've faced so far? What did you do to overcome them?

During my time as a manager, I've been through 3 layoffs and an acquisition. Uber has been an awesome place to learn and grow my career, but suffered from somewhat untempered staffing bloat through the years. In an effort to get the company profitable, the leadership team enacted a few downsizing events to address headcount spending, and our team was very unfortunately impacted by this several times. I learned a few things through these processes:

  • The lead-up (rumor stage) to layoff events is the most detrimental to team culture and sense of belonging. Incorrect information is shared as speculation, and team members are left wondering if they will be included in the event.

  • The actions being taken are often not transparent, and typically take place above the middle management decision-making bracket in the organization hierarchy. You typically receive guidance and on-the-spot training on the day of the event being announced.

  • Everyone usually has the best intentions, but are relatively powerless as to how layoff exercises are executed. There are definitely right and wrong ways to handle these events, but to protect the company there are often specific ways of handling these staffing changes that are unfortunately impersonal. It is challenging to conform to what's expected when people you care about are impacted.

As far as what I did to cope with these learnings and situations, I mainly stuck to the values I hold important as a manager: authenticity and transparency. Through the process, I shared my feelings with the team on how we were impacted and held listening sessions for the entire organization to comment on how they were feeling after our team members had departed. Feedback I received noted that the team appreciated that they were able to comment on the situation and share the emotions they felt during the difficult times, which helped me articulate how folks were feeling to HR and my leadership as well.

On a less situational note, another challenge I can say that I've faced as a manager are feelings of anxiety and being overwhelmed with the difference between the more tangible outcomes of engineering, and the less tangible outcomes of management. It took me a long time to actually articulate what I was feeling and how the differences were reflected in my experiences. In preparing for a career planning seminar at a team offsite we held in early 2020, I stumbled upon this article from FirstRound about the experience of Raylene Yung. The image below and the accompanying narrative really stood out to me and helped articulate the pressures of both success and failure I was experiencing. Realizing that life as a manager will have its ups and downs has helped me come to terms with navigating organizational uncertainty, team change, being supportive and addressing social injustice issues, and other challenges.

The Productivity Journey of Engineering Life - IC v/s EM

What has been the biggest surprise so far? Something you didn't expect?

Haha, there have lots of surprises. How quickly the team grew, what the team has achieved beyond expectations, how certain additions or changes impact the team's progress or culture. I've been wrong quite a few times too, even when it feels obvious what the right answer is. Those are positive moments of learning that help me recognize when to take a back seat and let the team lead where they are very capable.

I'd say another aspect of surprise that occurred early on in the manager conversion is learning just how much work goes into being a manager, and I've had a lot of ICs on my team who have gone through the transition share that with me. Some of them reflect with "I never had any clue it was that much work" and others feel more natural in the transition.

The importance of an organization's focus on manager training is also a major influencing factor in your success as a manager, which is multi-faceted in itself. This shouldn't have been a major surprise, but it has been to some degree. Early in Uber's growth we weren't investing in manager training and having direction set from the organization leadership was immensely helpful in giving our teams confidence and direction. Often times employees don't really care what direction something is taking, but just want to know solid answers to be able to plan for themselves. Having those answers helps more than I realized, even for myself.

What's the best advice you've received about being a manager?

The best advice is still something I struggle with, but essentially learning to delegate. It feels unnatural to not step in and create wins for yourself or the team when you have a great idea or experience of how a particular milestone can be achieved. Delegation is a big part of how you grow your team and create opportunities for others around you. If you're unable to do this, lots of things get blocked on you individually and the team isn't given a chance to exercise their brains — which is what you hired them for in the first place.

What do you tell developers who are considering making the switch or new to the role?

I'm having this discussion right now with one of our team members. She is interested in making the switch to EM from a technical lead role. These discussions have to cover a few concrete points, some of which come from the developer.

  1. As the leader, you need to have a solid understanding of where Engineering Manager fits as a career path in your organization, and be able to articulate how that person will grow and transition into the role based on those variables.

  2. You'll also need to be able to articulate the expectations of the new EM role to the team member, and how they will be judged once they have fully transitioned to the position. Some companies prefer apprentice EM roles at first and if there are skills gaps, you will need to set appropriate expectations about how the apprentice period will help them acquire or practice those skills. Some companies also have Tech Lead Manager roles, which differ mainly from EM by placing a larger portion of technical architecture and execution on the TLM, while the EM performs more strategic planning and team/organizational health activities. It is good to qualify these differences with your developer if your organization has these roles.

  3. A question many team members don't ask in these transitions is how they will be supported by their existing/current management chain through the process. I often hear questions from team members after they have transitioned like "What training should I be doing?", or "Do we have training about X? (situational)". In situational experiences, it's often surprising to realize there is coaching or OJT (On the Job Training) that will occur, so it's good to be prepared for this ahead of time and articulate that expectation. A good exercise here is to ask questions of the developer around what scenarios they expect to encounter as a manager that might create uncertainty or needs for support to get them thinking about the challenges they might face as a manager.

  4. In addition to addressing these areas, I try to get concrete timeline expectations from the developer on when they want to begin and complete this transition. This is important because it helps set expectations with your HR partners and your manager on how you're developing and building your team and supporting the individual making the transition. I also make sure they understand the implications for any possible upcoming performance measures, such as promotions, so their expectations are clear (see example below).

Relevant example: I received a promotion to Manager II after a year split between developer and manager roles officially. My manager at the time articulated that I was receiving the promotion "largely for my efforts during the 6 months I was a developer", which was pretty confusing. I now had new, higher expectations as a more senior manager that I was not really prepared for but was being rewarded because of past successes prior to my manager role. While I'm glad the organization was focused on rewarding successful work, in my opinion it would have been better to give me more readiness for new expectations and to focus feedback on my go-forward career path than on my work as a developer in those first 6 months of the performance cycle.

Final call to action! Where can we go to learn more about you?

I'm in the usual places, LinkedIn being the primary place to find me for networking and opportunities or just to reach out and connect. I'm currently refactoring a ton of the Cobbservations content so it is more relevant to where I focus my energy today. I'm always open to direct emails also via loyaltyarm@gmail.com as well.

Join thousands of other subscribers receiving updates every 2 weeks!

© Developer to Manager 2018 - 2021
Crafted with ♥️ in Munich