Leading by Navigation

In The 21 Irrefutable Laws of Leadership, John Maxwell says,

“Anyone can steer the ship, but it takes a leader to chart the course.” What does this course-charting navigation look like for technical leaders? The core is seeing more than others do.

We once had a situation with our class and assignment listing page that required bigger vision to solve properly. Three teams were involved in showing the list: a front-end team (FE) making the request and rendering it; a back-end team (BE1) with responsibility for listing the assignments in the class; and another back-end team (BE2) owning some important display statistics like "user submissions per assignment". One day FE found that the submission statistics were not taking user enrollments into account (owned by BE1), and so they requested BE2 fix it. It would have been possible, but we paused to look at the bigger picture. It took vision to see the fact that BE1 is already responsible for a separate page that combines user and submission data together into a list. If we wanted to save ourselves from future inconsistencies, the logic to list and count those submissions should be in one place.

When working with a team it is so easy and natural to focus our solution space down our team's available options. Navigators take the time to understand what neighboring teams are doing. They ask, "Has this been solved elsewhere? How do this component or feature fit in with our product as a whole? What does our team provide that others should be aware of?"

This occurred once with a service our team had developed. It was a highly-scalable Redis-backed rate-limiting system, used at first for rate-limiting specific actions that could be attempted at many thousands per second. We built it for our need, not over-engineering, but had it use an HTTP API we could build upon. Years later in technical meetings I heard about a team trying to prevent password-cracking attempts on their login page. Typical Captcha-like solutions were looking very expensive. I threw this service into the ring as a candidate for the throttling we needed, and it ended up working well for them.

To many people, knowing where the tech department is going, much less the whole company, feels not worth the time. But being aware of the bigger picture has great value for alignment. Navigators know this.

Some may also say this is someone else's responsibility. That is likely true, for now. But if you want to be that person someday, your effort to grasp the bigger picture has to start now.

Software leaders know that code is read far more than it is written. An engineer may focus on the value that code provides in this moment, by the feature it implements. The leader sees into the future, how that code will support future work, or detract because it is obscure, poorly documented, or error prone. Navigators see far into the future.

We once had a scaling challenge with particular metadata our product team wanted to display. It would be a big lift to make it queryable at the granularity they wanted. When they heard the costs involved, they dropped the request. Years down the road we had a new product need that would have required this metadata. Beyond that I recognized a third more technical use for it: we were relying on unscalable proxying to request it already, and it would simplify our architecture. I wrote a proposal to present to the rest of the architects, gathered buy-in, and we launched the project, which I can say is now essential to our newer products while simplifying our architecture.

Navigation is like looking several moves ahead in a 4D chess game being played by multiple disparate teams. It takes far sight to recognize points of convergence and obstacles, to build systems that will be ready on arrival rather than hold everyone up.

One way this kind of strategic, navigational thinking plays out is in order of delivery.

A common example is rebuilding legacy components. Often the focus is, should this thing be rebuilt or left untouched? I believe it is just as important to ask: How can it be rebuilt in a way that incrementally adds the value along the way?

Joel Spolsky is known for calling rewrites from scratch the "single worst strategic mistake that any software company can make". I think that's often true, if only because software engineers are terribly optimistic at time estimation. But I think the real critical mistake in that kind of rewrite is that until the new version is done and rolled out, there is zero value added for customers. Agility is lost, and any efforts to improve the old thing are wasted. The opportunity lost could be fatal, as it was with Netscape.

But the reality is, software (or hardware, research, whatever you work with) must be revamped eventually. Except for the thumbtack, nothing stays valuable as it is. Everything must change to keep providing value and compete. So how should it be done?

Years ago we had a document similarity viewer service that was core to our business, but was quite old. It was in C++, had no tests, and had to be treated with care. We all hoped to rewrite it. That day came when I recognized some new product requests coming down to us for a new way to view the data this service currently handled. It would have been possible to do in that service, but brittle and somewhat costly. I recognized two things about these requests: 1) they required only a small subset of what the current viewer did; 2) eventually this new way might overtake the old way we view the data. So we started building a fresh viewer in Go, well-tested and with a better API, but able to read the same underlying on-disk data as the old viewer. Because the new product capabilities were still a work in progress with UX, it bought us time to build this new thing. We were able to stay ahead, powering new features with our new viewer even as the old one continued providing value. Eventually it completely replaced the old viewer.

Stories like this make the decision sound obvious. But in reality, building a new thing was going to be quite a bit more work. They key was seeing into the future, knowing where we are going, and recognizing that now is the time to do it in a way that provides incremental value along the way.

Ask yourself: