The Muselet #28: Time Horizons

I needed a distraction, so a while ago I decided to spend a few hours learning React Native. React Native is an environment to build native mobile applications for multiple platforms at once, based on the popular React.js library. Overall, React Native has become a very smooth experience (I had played with it a few years earlier), but one thing really blew me away:

I could edit some code, save the file and in seconds the app my iPhone would update, retaining a lot of its state, reflecting the changes I made in my editor.

Seconds.

I remember Jeff Bezos once saying that he effectively lives in the future. His time is spent working on where he wants Amazon to be about 2-5 years from now. Whenever he is pulled back into the here and now, it means something went wrong. The majority of his time should be spent on that long-term horizon.

In the mean time, we — mere mortals — probably operate somewhere in the middle, largely determined by the roles we take and the type of companies we’re in. If you’re in a start-up, likely everybody will be operating in the here and now. Maybe you’re thinking at most a few months ahead. The more mature the company, the more at least some people ought to think about the a time horizon farther into the future.

One of the frustrations I often hear from people just jumping into engineering management is the lack of seeing clear output of their work. They’re used to write code, implement tickets, and feel they accomplished something. You (often visually) see the result of your work. What you build today, will be released tomorrow, or next week. That’s your time horizon.

As an engineering manager, your product is no longer code, but a (hopefully productive) team of people. What is the time horizon to measure your impact on people? Some things you do still have short term impact, but many more things will only be visible later. Perhaps based a retrospective you decide to change the code review process, or reduce the number of meetings. You see productivity go up after a few sprints as a result. Perhaps you nudged somebody in your team to look a bit more at AWS and get a certification. After a few months the person completes the certification. That’s a visible result, but how do you measure the actual impact on the team or company on that — and when can you expect it? 

I currently operate at the director level, and we are coming out of budget season. During budgeting you’re effectively planning resources (yay, resources!) that you think you will need next year, and ideally the years thereafter: what does our product roadmap look like for the next year? How many people in what roles and at what seniority levels will we need to achieve it? If those things are known, then do we hire everybody at once, stage the recruitment, what about onboarding? You have to take into account the lead time of a new hire. What is the lead time for recruitment anyway? That long? Wow. Will you have gotten it right? You’ll see in six months to a year.

Most roles involve a mix of time horizons, but the higher level the role, the more indirect your actions become. You need to be more and more patient. On the upside, the impact potential will increase. As an engineering manager you may be happy with the impact you can drive by successfully onboarding a new team member in your team. At the director or VP level you may be planning to add five more teams next year. At the engineering manager level, you may manage to deliver a new feature this month. At the VP level, you may be supporting a full company pivot or getting into a whole new business over the next few years.

One of the things I’ve learned over the past few years is that every level up in an engineering organization changes the job completely. As mentioned, time horizons change, but not just — your expected output changes, as well as the tools you use.

To give you some idea, let me sketch out what this may look like. Note that specifics are likely incomplete, and will differ per organization:

As an engineer, your output is code — working product. The tools you use are programming languages, libraries and an IDE. You can expect to see the results of your work in seconds or minutes, and on production in days or weeks.

As an engineering manager, your output is what your team produces (as well as any other teams you have impact on). This is Andy Grove’s definition. The tools you use may be JIRA, Slack, meetings, and code reviews. You can expect to see the results of your work in weeks or months.

As a head of engineering, your output is what your part of the organization produces (as well as any other parts of the organization you have impact on). The tools you use are meetings, Slack, dashboards with engineering metrics, and slides. You can expect to see the results of your work in months.

As a director of engineering, VP Engineering, CTO, your output is what your (larger) organization produces. The tools you use are meetings, Slack, slides, spreadsheets, dashboards with engineering metrics, org charts and mergers & acquisitions (M&A). You can expect to see the results of your work in months or years.

What I’ve come to realize is that it’s really worth considering what tools, type of work, and time horizons you’re comfortable with, and adjust your ambition accordingly. I, perhaps naively, always thought “I want to be CTO one day — biggest team, biggest impact, fanciest title, yeah!” However, that is worth considering. The job changes quite significantly every step up, and not necessarily in a way that will make you happy.

You may have heard of the Peter Principle:

The Peter Principle is a concept in management developed by Laurence J. Peter, which observes that people in a hierarchy tend to rise to their "level of incompetence": employees are promoted based on their success in previous jobs until they reach a level at which they are no longer competent, as skills in one job do not necessarily translate to another. 

Rising to your level of incompetence is just one way that careers can move into unproductive territory. 

What if competence isn’t the problem, but job satisfaction? Should people keep doing stuff just because they seem capable? 

I will admit it. I’m very tempted to formulate the Zef Principle now based on this idea — naming highly derivative ideas after myself is kind of my schtick. This time I’ll leave this as an exercise to the reader. You’re welcome.

As you climb the management ladder, you will realize that every step is very different than the last. One may be solid, cold and somewhat slippery. The next, thick, wooden, but a bit splintery. Neither is “better” per se, just different. Whether they suit you may depend on who you are, but also what you’re looking for at that particular time. Altitude is just one dimension.

I had an interview some time ago with somebody at least ten years my senior. Most of his career he worked in the engineering manager and equivalent roles. He was perfectly happy with that. He mastered his tools. He knew how where and how to have impact. He was happy with his time horizons.

How about you?