It has been an interesting two years for me. In early 2021, the VP of onboard (on-the-car) infrastructure suddenly and unexpectedly departed from Argo, AI where I was working. In the ensuing re-org, I was placed as lead of a key infrastructural team. Before the end of my tenure in doing this, I had 10 people under me. The team itself was actually multiple teams with independent projects and work streams spread across multiple time zones and was half of a larger team, with the other half being in Munich, Germany. The German half of the team was managed by the senior manager who technically owned both halves of the team, but he had left driving the U.S. side of he team entirely to me. Functionally, I was operating independently.
I was in that role for about 10 months, in addition to my prior 8 months managing a different team. We got a lot done in that time. We had inherited staggering amounts of technical debt. We also inherited a plan to fix all of it, but the plan essentially was to create a new infrastructural framework. The senior manager and his team took ownership of building the new framework and getting teams to port to it, which seemed to be a trick akin to running alongside an airplane rolling down the air strip that’s about to take off, in order to board it. My teams were charged with maintaining, fixing, and building the fault monitoring and management system, general onboard infrastructural cleanup to aid in porting to the new framework and keeping the legacy framework afloat, and heavy data logging.
In hindsight, each of those individually was appropriate to keep a line manager busy. But as time went on, it became clear that the heavy data logger was going to require most or all of my attention. The logging team was situated under the “onboard infrastructure” org, but the scope was vastly larger than that. Every single engineering workflow for the end product flowed through the team of 2 engineers. The team was poorly staffed, under tremendous pressure, and we discovered about 3 months in to my leadership that design choices combining both hardware and software dating back to two years before most of us joined the company had severe problems that threatened the entire business.
While we worked to develop a plan around this, I grew tremendously as a leader. I had a lot on my plate, and I had to find ways to get the work done without stepping in to guide teams each time. The logging problems in the company needed almost all of my attention, and I wouldn’t have the time to be directly involved on my other efforts with the same time commitment.
I identified an individual who didn’t imagine himself as a tech lead manager, and who had only recently been promoted to senior engineer and been placed on the fault monitor team (before I managed him). I saw that he had tremendous potential, but he clearly wasn’t yet ready to run the team on his own. While I devoted most of my time to the logging effort, I steadily offloaded more of the fault management work to this individual over the course of 3 quarters. At first, I gave him both technical guidance on his designs (anybody would need this, given the nature of the project and the fact that it was essentially a distributed state machine) as well as explicitly managing planning and cross-team expectations for him, and also handled all reporting for him. As each month passed, we steadily placed more on to this person as the lead of the fault managing effort, with him taking over more in each of those areas. In the early fall, I had a conversation with him outlining the areas I saw as his strengths, and areas where more growth would be necessary in order for him to take the reigns entirely.
Looking back, I can say that this was perhaps my personal highlight of my time managing. About 6 months after our conversation, this engineer was promoted to staff level, and took ownership of the project for good. These types of situations were the entire reason I became a manager—to help people identify their role in a company, and to enjoy doing it, to the benefit of everyone.
I also had people under me who were either multi-decade veterans of software development, or else experts in their domains. Each person brought their own management challenges, and I worked tirelessly to earn their trust and to help them align their skills and proclivities with the company needs. Some had the reputation of being difficult to manage. I can say that some definitely required more direct time investment than others, especially with a growing level of cynicism over how their teams were managed from above and after an unexpected re-org, but none of them were particularly difficult to manage. It required learning how each person gives feedback, and how to learn what they individually perceived as important to the company and their career, to slot them in well and get work done to their satisfaction. I no longer work with most of these engineers (the company doesn’t exist anymore), but they still have my great esteem and I feel as though it was a situation that I navigated uniquely well.
That fall, I received a very impressive performance review score, with multiple other managers commenting that I had been the best person to have lead the team. They also commented that I had addressed several key technical and communication problems.
During the time leading up to this, the logging project was increasingly becoming almost my sole focus. But as important as it was, the project itself was a death march. The team had unrealistic expectations placed upon it from upper management. The self-driving technology was quite impressive, but to prove that it was safe required us to collect a tremendous volume of data that the company hadn’t prepared for years in advance. To the company leads, this didn’t matter. We were required to do what was logically and arithmetically impossible, but with no agency to change the problem space in a workable way. This was eventually solved 2 managers after me—the upper leadership took to heart that managing the team was a full-time effort, and that we required a data workflow architect who was well-established and who had been working across teams for some time, who had intimate knowledge of each team’s data needs to push back when they were asking for something they didn’t fundamentally need.
I had an outstanding TPM working with me. He did a great job of communicating the technical issues that caused very difficult limitations and constraints on customer teams, what our possible mitigations were, and how they each affected both short-term and longer-term initiatives. In the end, the transparency we strove for had a curious effect. The message we intended to help teams inform their roadmaps against fundamental technical constraints came back to us in conversations with upper management to merely repeat problems back to us that we knew were problems, and telling us to “fix” issues that we could not fix without direct input from company leads about which company-critical initiatives we had to support at the cost of others. That is, we needed feedback that addressed the reality that we were facing decisions that would affect company strategy, not merely technical issues that affected multiple teams. The conversations became increasingly difficult, with the top management coming to terms with the decisions they were required to make.
In November of 2021, I decided that I enjoyed working with the people and technology in the company, but that I no longer wanted to be in charge of these efforts. My manager had insisted that I opt in to promotion that cycle, but I was quite concerned that I had met my personal limits and wasn’t ready to be judged against the level of Manager II/Staff Engineer without more support from the company, which seemed difficult to receive. So I withdrew from the process, and asked my leads not to defend me in committee.
It was a difficult decision because I really found my stride in being a personnel manager, but I had clearly joined at a poor time. In this one-year period, 8 managers in my area had either stepped down or quit the company entirely. I asked for and was granted to become an I.C. again. My successor was a manager who had a great track record. This person decided to quit the company 6 weeks into the role of logging TLM, citing the impossibility of position itself as the reason, a move that validated my thoughts on it.
I spent the next year writing firmware in a safety-critical context. I worked hard as an I.C. to bring order to development plans, and to raise the bar in my group for code quality and testing expectations in a safety-critical product. Through my effort, we also reestablished a technical strategy on the project to transform the rigid plans that were putting us months behind into more fluid ones that gave us multiple stages of progress, with options all along the way to take an easier path while still having something that works. We made more progress under the first 3 months of the newer plan than we had in the prior 6 under the old plan. The key was simply to recognize that we were head-of-line blocking on technologies rather than preparing an architecture that could be used under different technologies. We had to re-focus most of the team on the work we were able to accomplish that had to be done in any event, and to defer the choice of specific enabling technologies until we had the capacity to do so.
During these activities, I also had the honor of mentoring two junior engineers, who quickly grew into engineers who punched above their weight class. This is always one of my favorite professional activities, and it helped me to retain a bit of the reason I got into people management originally, even though I was simply a Senior Engineer I.C.
And then, after nearly 12 months of doing this, Argo closed. It was no more. The end came rather suddenly.
In the subsequent acquisition by Ford, I now work for Latitude, AI, a Ford company. This has also been a very interesting year, with tumult and drama that accompany an acquisition. I have been through 3 acquisitions prior to this, both large and small. They never go easy! But in this time, I have had leeway to work on the projects that I deem necessary for our company to thrive.
I moved out of my comfortable understanding of low-level software and infrastructure, and began to fill a gap I saw in our testing methodologies. It is becoming a bit of a passion of mine, keeping developers moving fast and giving them the tools that are required to test everything sufficiently to avoid killing a release, but to do so in a time frame that makes it possible to iterate.
Quite the change from two years ago, my effort and thought leadership have been recognized formally with my promotion to Staff Software Engineer. The promotion is nice and was desired, but even better is that I am excited to go to work, and it feels good to be in the position of not wanting to stop when the time comes each day.
With the past behind me, I look forward to recounting some of the lessons either learned or reinforced during my time in Argo, AI.
Trevor Kemp 