A core role of senior leadership is sometimes overlooked. This role, played by the senior leader of a functional area (the CTO plays it for technology, the CFO plays it for finance, etc.), sets the baseline of what excellence looks like in this function. I call it “True North.”
True North represents the core principles that a person in a functional role must keep in mind as he does his job. For a product leader, True North includes thinking of the users and their needs first and foremost, measuring and experimenting as much as possible, and pushing back on projects that don’t address the stated goals of a team. For a CFO, True North includes looking at the numbers, at the costs of work and at the potential value, and making sure that you’ve considered how to make those numbers work in your company’s favor, that the company isn’t accidentally spending more money than expected, that the team knows when it’s at risk for going over budget.
For a technical leader, True North means making sure that you’ve done your job getting things ready to go into production. It means you have honored your agreed-upon policies for review, operational oversight, and testing. It means that you won’t put something into production that you don’t believe is ready for your users to experience. It means you’re creating software and systems you’re proud of.
Technology leaders must help set the standard for True North in their organizations for different types of projects and exposures. Another way to think of this is through the lens of risk analysis. Risk analysis doesn’t mean that we don’t take risks. Some things that are generally considered “bad” can be OK under certain circumstances. These include:
There are situations and companies in which all of those risks are acceptable to take. That being said, True North helps us understand that all these issues must be carefully considered when we put code into production. Just because these rules have exceptions doesn’t mean we forget that they exist.
I call this concept True North because it’s important to understand it as an underlying pull, as a guiding instinct that we as leaders have developed over time and strive to help our teams as a whole develop as well. When our teams develop this instinct, they can be trusted to independently follow these guidelines without much direction or nudging.
The True North for each functional area is slightly different, so there will be natural tension in the organization. Product managers may care more about the user experience and less about the production support burden. The finance team may care more about the overall cost of infrastructure and less about the risks for availability. This tension is healthy because it forces us to reckon with all of the risks, not just the risks that our particular function cares about.
When you examine your role as a leader, looking at the ways that you set True North can help you understand your strengths and areas of ownership. If you consider yourself a technical leader, part of your job should be setting True North for large facets of the critical technology. As a CTO for a commerce company, I set True North for most fundamental technical decision making around production readiness, scaling, systems design, architecture, testing, and language choice. That doesn’t mean I made all of those decisions, but I guided the standards by which such decisions would be evaluated. I delegated True North for matters of mobile and UI-specific development, but pushed the senior technical staff in those areas to articulate what the standards looked like.
True North leaders rely on the wisdom they’ve developed over time to make fast decisions when they don’t have time to delve into all the details. If you want to become this type of leader, you must spend enough time early in your career to hone these instincts in order to be comfortable making fast judgment calls. That means staying technical; following through with projects, languages, or frameworks long enough to learn more than their basics; and also pushing yourself to keep learning new things even when your day-to-day doesn’t involve writing code.