About Pathfinder Engineer
We like to look at Pathfinder Engineers from three perspectives and meanings.
The first perspective and meaning come from the military. Pathfinders are special units that drop into a territory to set up a drop/operation zone—preparing the ground and territory so that it will best serve a specific need. Like Principal/Staff Engineers, they prepare new projects or territory for the project/initiative. They are thrown into the action in the current context, and they need to work proactively to move forward and look beyond what's known now so that the team/organisation can use the new site to expand its operations in the future.
The second perspective and meaning come from folklore—a person who is finding a path for his tribe. He works closely with scouts, trackers, hunters, and suppliers to understand the tribe's current context so he can proactively propose paths that the tribe can take to evolve or escape annihilation. To achieve this, he must present these ideas to the stakeholders (tribe council), find reasons, and lead the tribe in the proposed direction.
The third perspective and meaning come from us; this is how we see the role of Staff/Principal Engineers in organisations. We are responsible for things like finding a way so that two teams can communicate with each other, finding a way to move an organisation from the current to the desired state, proposing a roadmap and steps to achieve the desired state, getting the buy-in, work in the name of the company so that company can succeed, which also means saying no to ideas coming even from CTO/CEO with a good explanation of why no. To be able to do this, we need to acquire skills that are beyond coding.
This newsletter is for people who are trying to become staff/principals or are facing challenges as staff/principals they have yet to tackle. How do you talk to a CTO about the issue you have detected? How do we tell the VP of Eng that this new product will not solve the issue and instead, we should invest time somewhere else? How to break silos in organisation? Or how to make Junior become Senior and then Staff? And how to do all of this while working on the new architecture of the product or in a squad that is fixing DB performance issues in production that can cause the company to be busted.
