Technical Trailblazers

Are you a high-performing software engineer, or maybe you work with or manage one? We often hear high-performers labeled using terms like "10x developer" or "rockstar.” When thinking about your growth related to these labels, you may think, “if only I do 10x more than I’m doing now, then I’ll be successful.” You might think you need to solve more significant and complex problems and that being a high performer is doing things others can't.

While increasing your output or improving the quality of your work might seem like the best path to being a high performer, I’d like to suggest a better way that doesn’t focus on comparative output or highlight dramatic performances. A high-performing engineer may have significant output (10x) and solve complex problems with elegance and ease (rockstar). Still, if they only adopt these roles, their contributions will not scale as large and may not even endure.

Technical Trailblazer

The highest performers I have seen and learned from are those who don’t simply charge off into the wilderness on their own but know how to lay a trail. I like the metaphor of a trailblazing engineer because the parallels, though often neglected, are practical, simple, and straightforward. Like a real trailblazer, a trailblazing engineer is headed somewhere others will follow. So let’s consider practices that can make you a successful trailblazer.

Plan their journey, not just yours

Setting out to impact your team or add value to the product you work on is a great goal. However, when going somewhere new, you need to know where you hope to end up, how you plan to get there, and how others will follow. Documenting the high-level steps of that plan and outlining how you will get from where you are now to where you are going is the first step of trailblazing. If you skip this step, you leave yourself open to many risks, including not ending up where you wanted to be, leaving no trail, and possibly ending up at your destination alone.

I once attempted to blaze a new trail for migrating from a deprecated frontend framework to a new one. As I tackled the problem, I tried to make it easier for people to follow my work and contribute. However, this first attempt failed, and it did so because it needed to include a plan with well-scoped steps to reach the end. I had only provided a pattern and some tooling but had not spelled out the scopes, milestones, and steps required to do the work.

It is essential to consider your destination and route. Still, even more importantly, remember how those who follow you will get to the same place. This means considering all the required steps and the contexts and abilities of those coming after you.

Prepare for the "dysentery.”

If you are old enough to remember the computer game “Oregon Trail,” you know that someone in your traveling party eventually gets dysentery. This means that trail-blazing work will have challenges outside your control. People change companies, get sick, tragedy strikes, team members get reallocated to other projects, and the list goes on. The reality is that trailblazing can get interrupted; no matter how great an engineer you might be, you cannot blaze the trail if you aren’t on it.

This brings me to some of the best advice I’ve received for maximizing my impact. Once, a manager recommended that I deliver work with the expectation that I might not be doing this tomorrow. The best technical trailblazers leave a clear enough path that even if they are pulled off the trail, someone can pick up the work and do so without much delay.

For example, I once had a co-worker who knew he would leave me in a difficult position by accepting a new role and leaving my team. However, instead of simply walking away, he spent his final weeks documenting a massive backlog of well-specified tickets and laid out a clear plan for his remaining work. This trailblazing and stewardship make him the kind of engineer for whom I’d always write a referral, and I would be glad to have him join my team again. If you are blazing a difficult trail, will it be successful if you are forced to be absent for a time? Would it be successful without you? Those who can answer yes are the kind of engineers I’d want on my team and at my company any day.

Don't go too far ahead of your party

It can be tempting to charge ahead and get stuff done, and sometimes, this type of work is required, but some projects require engagement and adoption from more than just a few engineers. Sometimes you need buy-in from the whole organization, including leadership and individual contributors. Even if you can blaze a new trail, it is essential to consider whether anyone will be able or want to follow, especially if they can’t see you or what you are doing.

I once spent the better part of a year developing and documenting a backend service layer written with a newer technology that was supposed to make everyone’s lives easier and speed up the process of delivering value to our customers. Unfortunately, as I developed this work with a few others, we made the mistake of getting too far ahead of everyone else. We had a plan, the steps, and we had it all laid out, but we lost our party. Those we needed to travel with us were not bought in and were not ready to invest in learning the new technology. As a result, the company wasn’t prepared to adopt the new layer into its product-development lifecycle. Had we considered the current company climate, the readiness for change, and the lack of resources needed to support the successful adoption of new patterns and practices, we may have planned an easier or more gradual route.

When thinking about blazing a trail or making an impact that is bigger than you can accomplish on your own, it is paramount that you know who will be following and that you aren’t blazing a trail that no one is willing to travel, no matter how well groomed it might be.

Be ready to backtrack

As I’ve referenced earlier, sometimes we blaze trails that others are not ready to travel. Other times we hit roadblocks that force us to take a different path. Especially when traveling into unfamiliar technical territory, we need to be ready to backtrack, pivot and chart a new course.

Earlier, I mentioned trying and failing to introduce a pattern for migrating a legacy application from one framework to another. When I realized this path was not gaining adoption or being followed, it forced me to backtrack, regroup and chart a new course. I didn’t do this alone because the key to backtracking is getting back to your traveling party and ensuring you aren’t blazing ahead alone.

I regrouped with others at my company and worked with them to formulate better plans, scopes, milestones, and patterns. This led to much more cooperative progress. While it isn’t always fun, trailblazing requires backtracking because even the best plans cannot account for everything.

Know when to write the map

When learning how to backpack and camp in the wilderness, I was taught to “Leave no trace.” This principle is great for taking good care of natural resources and lands and allowing others to experience the beauty of untarnished nature. However, when blazing a technical trail, the opposite is true. We should leave lots of traces and even “prepare campsites,” “leave lots of pre-gathered firewood,” and give a clear indication of the next steps of the journey.

This metaphor is about documentation and isn’t always something most people are excited about writing. Leaving good traces can easily take the form of writing good, self-documenting code, and helpful code comments are needed in more complex solutions. We should leave clear trail markers that others can follow when the trail gets complicated or could be easily lost. More than that, we need to know when to write the map.

There is a certain point in blazing a trail where you must slow down and write out some documentation. This shouldn’t be a solo process, as writing documentation is almost always not for ourselves but for others. Good documentation should be requested and reviewed often, especially when it involves trailblazing. A good map can make or break a project, mainly because time is limited, and just because you’ve blazed a trail doesn’t mean you can go back and serve as a personal sherpa to everyone that follows. Good documentation and technical writing is a skill that helps technical trailblazers multiply their impact and save time for even more new trails. As I mentioned earlier, some of the most successful engineers I’ve seen can write well-specified technical tickets that they can hand to others. As a result, these “map-makers” multiply themselves by generating huge backlogs of tickets that help blaze new trails.

Bring others with you

This idea is simple and easy to understand; the more people take a trail, the easier it is to follow. Making a trail is easier with many feet, multiple guides, and extra map-makers. This can be seen in most companies around the concept of technical onboarding. These aren’t new trails for anyone; they are usually well-documented and well-trodden. Since everyone onboards, the path is generally well-defined. Numbers are a massive benefit to trailblazing. I have seen this clearly in roles where we have adopted processes around documenting technical decisions and initiatives. If a few people begin to use the process or “trail” and prove its worth, more engineers follow suit, and the trail gets easier to use. This means trailblazing is easier if you don’t do it alone.

When you set out on a new trail, look for traveling companions who can share the load. Some are better map-makers, and some are better at breaking through the brush. Trail-blazing is more manageable and sustainable when we network and work together to establish the route to our destination.

Build trails that multiply

Lastly, you may be a rockstar who can create a fantastic show. You may produce ten times more than your peers. However, as a technical trailblazer, you can deliver value that will scale well beyond yourself. Others will follow not only your footsteps but also your example and blaze new trails of their own.