My Story
The California Years
Period 1: New Grad
A long long time ago I was going grad school in LA. Specifically, Northrup University. Graduate classes were mostly at night, and the professors were aerospace engineers in industry by day. Since school was at night and I needed a job I talked to one of my professors and got a part time job at a little 3rd tier engineering company called Eidetics. After a few months there I decided I would work full time and finish up my masters part time. My first day on the job they gave me a mostly finished simulation written in FORTRAN, a compiler, and told me to make it work. I had only taken a couple of programming classes, but I didn’t let that deter me. I worked with the other engineers and sys-admin and got it working.
Period 2: Leaving Eidetics
Over the next 5 years at Eidetics I ended up among other things, writing a graphing package, building a local ethernet network, cobbling together a manned flight simulator, and building and installing (in a different country) a test environment for a new mission computer that was being built be a major avionics company. By the time I left I was helping the other aerospace engineers write better code, automating manual testing, and keeping the network running.
Period 3: Joining Fingertip Technologies
When I started at Fingertip there were some big changes. Fingertip wasn’t an aerospace firm. Fingertip was software company focusing on the Apple Newton. Instead of writing Fortran and C simulations for Unix based machines, I was suddenly writing a baseball scorekeeping app. Needless to say my efficiency and execution speed went down at first.
Period 4: Leaving Fingertip
Actually, I didn’t leave Fingertip. Like many software startups based on new hardware, when the hardware doesn’t do well the software companies that depend on it don’t do well. But during the year that I was there I learned a lot about UI development, working with customers and end users, and building architectures that enabled growth rather than prevented it. By the time Fingertip closed I was performing at L2.
Period 5: Microprose as Lead Developer
After leaving Fingertip, but before joining Spectrum/Microprose, I spent a few months working as a contractor. I didn’t grow much as an engineer at that time, but I did learn a lot about the business side of things. Especially about making sure to provide value to my customer. When I got to Microprose things changed again. Another system/language switch. This time to Windows/DirectX and C++. I still know how to decompose problems, but my execution slowed because I needed to learn the new ways of doing things. I became a manager and I didn’t know anyone at the company. At first I couldn’t collaborate because I didn’t know what anyone was doing or what to collaborate on. Microprose was a bigger company than I had worked for before. It had processes. It had multiple offices across the country. I didn’t know how to deal with remote teams. I started out being less effective than I was at Fingertip.
Period 6: Leaving Microprose
Over time I figured out the differences, got back to where I was, and beyond. I helped the company hire and led the team through an acquistion. I led the team through shipping a box product (Falcon 4) and multiple patches. I learned how to build for multiple versions and expansion. I helped other teams at the company on gameplay, software and tool design, and set up a shared pipeline for getting game assets (mostly 3D models and images) into the final product. Microprose didn’t have a formal engineering ladder, but at that point I was performing at L3, but hadn’t been recognized for it.
The Microsoft Years
Period 7: Joining the CFS team as Dev Lead
Another company switch, but this time no change in language or platform. That meant that my ability to execute and my software engineering and archtecture skills were completely transferable. On the other hand, because the tools, systems, and company processes the Combat Flight Simulator (CFS) team was using were all different I was less efficient, didn’t know who to collaborate with, and had to learn what was needed to be involved with Microsoft at a brader level.
Period 8: Leaving the CFS Team
After 5 years on the greater Simulations group, I had figured out the way Microsoft did things. I knew the peopple to talk to and collaborate with across the Simulations group. I was developing the shared build system for Flight Simulator (FS) and CFS. I helped bootstrap new projects, like the interal tools team, Train Simulator and code name Platypus. I made sure that both internal and 3rd party games assets could be used with FS and CFS. I also was doing interviews for Microsoft. Lots of interviews. Not just for the Simulation group, but also 100s of campus interviews for new grad and intern hires.
Period 9: Moving to Virtual Earth as Dev Lead
The Virtual Earth (VE) team was an easy transition. Microsoft wanted to build the real 3D world in the browser, and who better than folks from the FS team, who were already doing that outside the browser? So a handful of folks from the FS and CFS teams moved over to VE to do that. There were some new folks around, and the management changed, but I already new many of them, so the only real change was switching from C/C++ to C#. That meant that for the first time the transition was pretty easy. I was a little less efficient at the start, but that was it.
Period 10: Leaving Seattle
I quickly came up to speed on C# and was back to L3 performance. At the same time we had acquired a small company in Boulder, CO that needed to be on-boarded to the Microsoft way so that it could deliver more content for Virtual Earth. So I started traveling back and forth between Seattle and Boulder to help with the transition. At that point my work at L3 was acknowledged and I was promoted.
The Colorado Years
Period 11: VE Boulder as Manager of Managers
This was another big transition. My direct reports were now managers. As anyone who’s made that transition will tell you, it’s a big change. Instead of directly influencing code architecture, you’re working on organizational architecture. You need to help others work together themselves, not do the colaborating for them. I was working in a new space again (3D reconstruction and photogrametry). I certainly felt I wasn’t doing as good a job as I did before. The bright spot for me as hiring and building the new organization. I was able to build out the developer org and was the “As Appropriate” for most of the hiring in Boulder.
Period 12: Streetside 3D Dev Lead
One of the things I realized as a manager of managers was that it really wasn’t for me. I felt too far removed from the code. I wasn’t happy with the extra level of indirection I had with what and how things were being done. So as I came back up to speed on things I found an opportunity and went back to being a dev lead.
Period 13: Leaving Microsoft
I was happier as a dev lead, but not as happy as I wanted to be. I took another step sideways to Tech Lead on the Boulder infrastructure team. This gave me the opportunity to stretch and grow my software engineering and collaboration skills. I was working with multiple teams to help them make more efficient use of our platforms and collaborating with multiple development and research teams at Microsoft to raise the bar for image processing and delivery across the VE organization.
Period 14: Joining Uber Maps
After 15 years at Microsoft, our business unit was sold to Uber. We were going to be doing the same job, with the same people, so that didn’t change. What did change was the corporate culture and wider software environment. Whereas Microsoft, unsurprisingly, used Microsoft tools and technology (Office, Windows, Windows Server, MS SQL, Team Foundation, etc) Uber was Google/Open Source, so I suddenly had to learn Linux, Cassandra, Mesos, Kubernetes, Aurora (the scheduler), and of course all of the internal tools and processes Uber had developed in 4 years hyper-growth. That meant a step back again in collaboartion, citizenship, and execution.
Period 15: Leaving Uber Maps
Of course, I had used Unix before, and the basics of schedulers and orchestrators does’t change much, so I was quickly able to come back up to speed on the spcific tools. A lot of what we did with map making was making things more efficient. Using hardware better. Making it easier for devlepers to adapt to changing requirements. I worked with the larger Uber infrastructure team to give offline processing first class tooling and capabilities, not just for map making, but any offline processing. Leading this cross-team project gave others the visibility into what I was doing and I was promoted to L4.
Period 16: Joining ATG
Meanwhile, after a few years of map making for Uber I got the chance to work on self-driving vehicles. I was able to use my background in multiple differnt fields to help the researchers and engineers work together. I helped them build systems that were easy for the researchers to use, but were efficient in terms of hardware used so we could do more together. But again some things changed. We were back to C++ for some things, but also now doing a lot of Python on Machine Learning. Whole new areas of technology for me to learn. Fun, but again, I wasn’t as productive initially.
Period 17: Leaving ATG
After a year at ATG I was working not only with the Infrastructure teams, guiding the development of platforms and tools that our internal customers, the devlopers and researchers, used to do everything from making maps to training ML models to running simulations to generating videos, but also working with our Developer Experience teams to ensure that our low level capabilities, like building, source control, code reviews, deployment to datacenters and vehicles, and how people responded to outages was capable of handling our current size and growing with the company. After I had been doing this for about 6 months I was promoted again, to L5. And in the middle of all that a pandemic hit, and we all started working from home.
Period 18: Joining to Aurora
Of course, the only constant in life is that things always change. Right after that promotion came another transition. This time to another self-driving vehicle company focused on Class 8 trucks (tractor-trailers). This brought in a new set of constraints, a new set of company tools and processes, and the overall robot framework changed. And as usual, the expectd drop in what I was able to do.
Period 19: Growing at Aurora
Once at Aurora though, I was able to quickly dig in. I helped build the systems that let us transition ~1000 developers from ATG to Aurora. I helped define the Zero-Trust security architecture that Aurora began to implement. I worked with both classic Aurorans and new Aurorans to build bridges so that they could work together. I helped define the rubrics used to decide which platforms and systems would be used by the new combined company. At that point I was working to define direction and tooling for the entire software organization.
Period 20: Leaving Aurora
After a little over a year at Aurora I had figured things out. I was working across the software org to ensure the entire org was (mostly) using a single set of tools and processes. I worked with the recruiting team to define the campus hiring program. I led the cross-org development of the core security libraries and made sure that our tools and platforms, internal and external, had security built in, not bolted on. Just before leaving Aurora I was part of a team that was defining the core culture and tenets for the entire software org.
Period 21: Joining Amazon
This was the first time in almost 25 years that I changed companies of my own volition. Since starting at Microsoft, while I’ve moved around inside companies as I wanted, all of my company changes have been through acquisitions. And this was a big one. Amazon has been around for almost 28 years and has internal tools and processes that reflect that fact. There’s a pretty steep learning curve to using them. This is reflected in how my ability to perform in that environment dipped in some areas when I started. I was able to maintain my performance in other areas, like archtecture, collaboration, and efficiency, because the things I’ve learned along the way about how things should be architected, finding efficiency, and working well with others, are very tranferable, regardless of the company or technology being used.
What’s next?
The future is unwritten. I get to create it as I go. I’m looking forward to seeing what it brings.
Visualize my career progression on my Eng-Stories page
