Thoughts on Creating a Technical Track

I have thought about how and why a company might put in place a technical career path on and off for many years. It's been on my mind more lately, so I thought I would try to document some of my thoughts and hopefully solicit some feedback.

I've worked at a lot of different companies over the last 20 years and without exception, the reward for technical excellence and sustained positive technical contributions were promotions into the ranks of management. There is nothing inherently wrong with that if it matches your career goals. However, I think it was more often the case that a management position was the only path forward in the very traditional corporate environments where I worked. They were the only tool available to provide increased salary, benefits and responsibility for employees that outgrew their technical positions.

Recognizing and wanting to reward technical employees is great. However, I don't think moving an employee away from a role where he or she excelled (technology) and into a role they may be ill-suited for (management) benefits anyone. The company no longer receives the same volume of technical work from an admittedly superior employee and the employee may be less happy doing more non-technical work. In spite of that, it's very easy, as an employee, to smile and accept such an arrangement.

Being a good manager requires a different set of skills than being a good developer. I don't mean to suggest that developers can't also be good managers or successfully develop the skills required for them to make that transition with confidence. If that's a path that interests you, then you should go for it. I'm more interested exploring the best ways to lay out a growth path for developers that want to remain technical.

It seems to me that finding ways to grow beyond being an individual contributor requires finding new ways to add value. I think there are several ways you can do that. I'll try personify them in the following roles. I should say up front that I don't believe these roles to be mutually exclusive or comprehensive.

The Multiplier

The Multiplier is a teacher. He or she actively teaches and mentors other developers with the goal of raising technical skills across the entire company. This can happen in one-on-one mentoring/peer coding scenarios as well as in larger classroom-type environments where his or her knowledge can be shared with many people at once.

The Jump-Starter

Breakfast is the most important meal of the day, right? I think something similar could be said about large software projects:

The first five sprints are the most important of the entire project.

Substitute "five" with "X" and "sprints" with "days/weeks/months" if you like. The point is that the beginning of a large project is critical to its overall success. That is the time when architectures are formalized, coding patterns and standards are established, tools and languagues are selected. The Jump-Starter adds value beyond the individual contributor by helping large, new projects get started on the right path.

Once the technical foundation is firmly established, the Jump-Starter can gradually reduce his or her involvement and help get another new project started as the rest of the team builds on the solid foundation he or she created.

The Pioneer

The Pioneer is the person experimenting with bleeding-edge technologies and guaging their appropriateness for the company. This position requires high technical acumen, the ability to learn fast and the experience to place any particular new technology in the context of what has come before and the particular environment at their company. Making the wrong bet on a new technology can be very costly. Similarly, taking an ultra-conservative approach can be just as costly as your environment begins to lag others and your best developers become bored.

The Pioneer provides considerable value beyond that of the individual contributor by forging a safe and calculated path through the rapidly changing maze of technology.

Recognizing the Value

The first step toward defining a technical career path for your company is to recognize that the roles I've described (and perhaps others) have value that exceeds that provided by the average software developer. How much additional value is likely very dependent on details specific to your environment.

What is the value of The Multiplier teaching 30 developers new techniques to make them each 10% more efficient? Demonstrating testing processes that reduce bugs by 50%?

What is the cost of a 5-person project that is cancelled after 8 months because of unstable code, architectural disagreements, and technical assumptions that were proven incorrect. The Jump-Starter saves that money and more by making sure the project gets off to a successful start and lives to provide value to actual customers.

What is the value of successfully balancing stability and innovation? Either is easily achieved given enough obstinance in the first case or boundless energy in the second. However, one without the other will certainly prove costly in the long run. The Pioneer works to keep the scales balanced - carefully planning and building innovative solutions in the context of the larger business need for stability.

Titles

I have always been frustrated by standard corporate titles. They attempt to describe what a person does and their position in the hierarchy all in three words or less. In spite of seeing the same word used at different companies ("Director", "Lead", "Senior") they always seem to mean something a bit different. I would rather see the two split and the title replaced with something more like a Twitter bio. Tell me what you actually do in 160 characters or less. If your relative position in the company matters, have an easy way to link me to an org chart.

However, since I don't think the standard corporate title will be replaced with a Twitter bio any time soon, creating a new path for technical employees will probably require creating some new titles. I could propose a few here, but I think they ultimately need to be created in the context of the titles already in place at your company. Be creative!

Quantifying the Path

One way to define a technical path and clearly articulate how someone would follow it is to quantify requirements for advancing to the next position. This can, admittedly, be tricky. It's easy to observe someone lead a certification exam study group or hold weekly office hours for junior developers 100 weeks in a row. It's much harder to quantify money saved from the establishment of a sound architecture or the revenue increase that follows the quality jump a few months after the establishment of unit testing standards.

I don't believe there has to be an objective measure used when deciding to promote someone on a technical track, but if those are the kinds of hard numbers that help the non-geeks recognize the value, then take some time to define the requirements for the progression. Stick to it and eventually I think people will learn to spot a rising star without having to get out their yardstick.

I obviously don't have all of the answers, but I hope that more companies will start to recognize and reward the additional value provided by their technical high achievers. Remote work arrangements continue to gain acceptance and that breaks down a significant barrier that has prevented some techies from finding their dream company. Competition for smart people is stiff. Do what you can at your own company to raise the ceiling and let the best people grow to be as awesome as their skill and ambition allow. If you don't, you might lose them.

Author image
About Brice Wilson