The Technical Track

There’s a common problem in the software industry, especially among companies that have survived rapid growth spurts: the best software engineers have nowhere to go but up.

Up the management chain, that is—away from the code and the details, into the land of meetings, roadmaps, architecture and cost planning. It seems a cruel fate for the best craftspeople in their prime. Would we dare “promote” a world-class painter, a few years into her self-defining work, to the administrative department of a museum? …or a brilliant young author to a copyediting position at a book publisher?

Some people choose the path of managing humans and projects, and that’s great, but it behooves us all to create another path for those who don’t. In software engineering, that second path is often called the “technical track”. Promises of green fields and infinite code beckon from beyond the horizon for those who would rather ply their craft and improve their skills over time. These promises are sometimes empty or poorly explained because most software companies don’t have a technical track that would encourage and define success.

What does progress look like down the technical track?

We have only a few famous examples of unequivocal success on the technical track, like Guido van Rossum and Donald Knuth, but no real guidance on how to set up that track. What if there were a better shared vision for the technical track companies could use and modify to fit their needs? What if both software companies and their engineers could be confident and excited about a future of delivering code and details, not projections and spreadsheets for all? What if, indeed.

The best technical track emphasizes growth, contribution and leadership, all centered on a technical core. Although software engineers need people skills to be successful on a team, and those skills should improve over time with their technical skills, the focus of the technical track should be, well…technical.

What does it mean to be an excellent software engineer?

This question serves as our foundation: what does “well-rounded” mean, technically? I’ll first propose a few dimensions along which excellent software engineers should excel, then in a later article describe how improvements along these dimensions lead to real progress along the technical track.

1. Productivity – Above all else, an excellent software engineer is intensely productive, often creating many times the real business value created by their junior cohorts.
2. Problem solving – Excellence in software engineering can’t be defined without raw technical problem solving power across disciplines and with systems in varying states of repair.
3. Quality – The code, documentation and discussion output of an excellent software engineer are consistently high in quality, serving as examples for more junior developers.
4. Technical knowledge – Engineers should be knowledgeable about a wide range of systems and patterns in software engineering. They use this knowledge to better design new systems and train others.
5. System design – Commonly termed “architecture”, this is important for all software engineers, especially those who function in an organization without dedicated architects.
6. Business/product knowledge – The best software engineers understand their business’s industry and products intimately and work to deliver the best value for the business, not just for the sake of software itself.
7. Data & evidence – Relying on gut evaluations or haphazard debugging are more junior mistakes. The best engineers gather just enough data to prove themselves right and follow the data to a solution.
8. Confidence & communication – All of these attributes will be undersold if the engineer is not a confident, clear, concise and inspiring communicator to both business stakeholders and other engineers.
9. Production support – The best engineers know that their responsibility does not stop at the deployment of their code. They own their successes and mistakes all the way into production systems.
10. Planning & execution – Excellent project execution relies on methodical and consistent planning from all engineers involved. The best should lead these efforts by example.

At Return Path, these dimensions helpe define our technical track and map out what it means to grow into an excellent software engineer. We work closely with our engineers to ensure they are bettering themselves along two to three of these at any given time, and they have a clear view of their future career path in the company.

This is only half the battle, though. We can measure and tune to improve engineers along this spectrum, but how do we recognize or define seniority along the technical track? I’ll leave that question for next time.

Follow up: Software Engineer Leveling & Expectations