My Career Path-Finding Algorithm

I don’t have a Computer Science degree and I didn’t start my career in any IT related field. In fact, most of what I know about academic computer theory I’ve learned from interviewing CS students applying for internships or their first jobs. Despite, or perhaps because of this background, I’ve become a successful developer and am looking forward to a positive career tract for years to come!

I’d like to share how I came to work in tech, how I’ve handled fluctuations in my career focus, and movement between individual contributor and management roles.

When I was young, I did have an interest in computers. My first introduction was with Logo in elementary school, then BASIC, Pascal, and some C++ in middle and high schools. I learned a lot on my own and was lucky to be in a school that could support this; still a rarity in the late-80’s. And while small, my school also had a strong international exchange program. As a sophomore, my family hosted a student from the Soviet Union. This was in late 1991 and it was an amazing experience seeing our world through his eyes. This was especially true when the Soviet Union collapsed while he was staying with us. He had left Leningrad, USSR and then returned to St. Petersburg, Russia. The personal connection the exchange program brought to these world-changing events sparked a new interest in myself that won out over programming.

While still in high school, I studied abroad in Finland for a year, briefly in Mexico (once on a two-week school trip and another on my own), and travelled to Russia and Sweden. When it came time to think about college, I decided to study International Relations; this left me with only a handful of schools to choose from--most of them in Washington, DC. I chose to study at American University and studied abroad for one semester in Brazil. I also interned at an amazing non-profit promoting entrepreneurship worldwide, Ashoka.

Toward the end of my undergrad I went to England to look at master's programs there, but ultimately I stumbled into a job in international trade. This was in 1997 and computers were just starting to become commonplace at work. I was in the small US office outside of Washington, DC and our largest office was in Beijing, China. The most efficient method of communication at the time, by time and cost, was to send a batched fax (e-mail was not widely available). Throughout the day as we worked on our contracts, we would type communications to our counterparts in the Beijing office on thin strips of paper. At the end of the day, the secretary gathered up all of these strips of paper and copied and pasted them onto standard size paper (litteral copy and paste, with a Xerox, Scissors, and Tape). We’d typically end up with 20-50 pages of communications, each page representing a dozen or so messages. These were sent by fax to our office in Beijing where someone would take the fax, cut every message into separate strips of paper, and distribute them around the office. This process repeated every day, back and forth.

The US operations were run on a dBase III database that had been built many years previously. The company was planning on commissioning a replacement, but custom programming was very expensive for such a small company. To reduce costs, we had meetings once a week to plan the replacement. Every week a dozen or so people would meet and talk about the fields in the single database table and perhaps move the ball very slightly closer toward a redesign. Keep in mind, this was only a database table - there was no concept of workflow, forms, or even multiple related tables.

These meetings had started before I joined and continued for the first few years I was there until an abrupt change in early 2000. That was when Microsoft released Windows 2000 and the dBase application the company was dependent on stopped working completely. 

I had dabbled with Access before this and suggested I could import the data into a single table as-is, throw up a form to help with editing the data, and a report to print out what we needed on each contract folder. There was some disagreement about whether to incorporate the years worth of work they’d done preparing for a redesign, but we decided it was easier and safer to import as-is. It was also much faster not to make changes right away and it was critical to get up and running again as soon as possible. I proposed that once it was in Access, we could make small improvements and avoid a major redesign.

In a day I went from being an Export Coordinator dealing with managing the purchase, shipment, and export of medical equipment to an Export Coordinator who also happened to have written the database that ran the company. Over time I made incremental improvements, breaking parts up into other forms, refactoring to a more normalized design (which I had just read about myself), and generally making it work better for our then-current needs.

Shortly after this, a coworker recommended me to her husband’s consulting company who was looking for someone with specific experience in Visual Basic for Applications. This was perfect, as it was the only language I knew proficiently! This contract went well and I joined the company full-time a few months later. I was a professional developer now.

So, why did I decide to change careers and give up my job in international trade that I enjoyed immensely? 

In the early days of my developer career, I found that my competing interests in international studies and software development were still there. As an Export Coordinator I could oversee contracts and execute them similarly to everyone else in the role,  but as a developer, I could write software that could help make everyone else more efficient. I felt my own impact was far greater there, plus I enjoyed the work.

Over the next fifteen years I worked in a variety of roles at just three companies. I programmed in a number of different languages, both front and back end, and, as needed, wobbled back and forth between a pure developer, a people manager, and executive. I remember one of my worst days in my executive role was the day I forgot my computer at home and upon arriving at work realized it didn’t matter--practically all I did all day was email.

My interest in a non-management career path peaked when I learned of Capital One’s Individual Contributor track from former colleagues who had since joined Capital One. At every past position I’d been moved into management because it’s what the company needed. Capital One gave me the opportunity to concentrate on the engineering work I wanted to focus on, still spend time mentoring and teaching others, and did not have an artificial “developer ceiling” that only managers could pass through.

There were many additional reasons to come to Capital One. I have 16 former colleagues that are now at Capital One and every one one of them has always had great things to say. I was also looking forward to the opportunity to work with huge volumes of data and in-transit analysis--technologies new to me.

Capital One offers multiple career paths for developers, among them--the management or individual contributor career tracks. All developers start off on the same track, and after someone is promoted beyond principal associates, they can choose either management or individual contribution, with some switching back and forth as they find their preference. 

There are a number of reasons why I personally prefer the individual contributor track. This track allows one to continue their self education and hone their craft and expertise beyond that of the traditional most senior individual contributor levels. In the traditional scenario, once people get to a certain level, they stop focusing on the technical aspects and focus increasingly on people management. Sticking to the individual contribution track allows one to take their  technical skills to the next level.

Within Capital One, the most senior individual contributors are often not assigned to one project as much as they oversee and contribute to many projects. This allows the best use of their skillset, as they can apply higher engineering practices to many projects simultaneously. Having a role where you can be the one that specifically helps with the most complicated problems is very appealing (to some, it’s also appalling to others). 

The individual contributor roles also allows and encourages greater breadth of experience. The traditional career path takes an individual contributor to senior or principal levels before moving them into people management. With a longer or perpetual individual contributor track, developers have more opportunity to move around to vastly different technologies. Personally, I've jumped from (1) database development to (2) desktop application development to (3) page-based web applications to (4) rich internet applications to (5) single page applications and now to (6) streaming data analysis, and I’m sure I’m not done technology hopping.

I joined Capital One as a Lead Software Engineer in May. I have challenging direct work with technologies that are new to me and a joy to learn. As an individual contributor I can teach and mentor others, both in my team as well as generally, and don’t have to worry about the aspects of management I don’t personally like--counseling and performance reviews. There are also many levels I can advance to without switching to management--Distinguished Engineer, Senior Distinguished Engineer, and Executive Distinguished Engineer.

Many people do enjoy management and view that route as the goal of their careers. Traditionally this has been the norm. Personally, it’s not my cup of tea so I’m really excited to have found a company that so highly values individual contributors and look forward to sticking with that role!