I needed a distraction, so some time ago I started a programming project at the side, after about a year or two of not touching code at all. I realized I had forgotten one aspect of programming: I could edit some code, save the file and _in seconds_ I would see the results of my work.
I remember Jeff Bezos 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 meantime, 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 a few people ought to think about 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 writing 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 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 at getting some sort of certification. After a few months, the person completes it. 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?
At some point I operated at the director level, where budgeting is an important part of the job. During budgeting you’re effectively planning resources (yay, resources!) that you think you will need next year, and ideally the years thereafter. You have to ask yourself: 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 consider 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. Then, 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 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). The tools you use may be JIRA, messengers, meetings, and code reviews. You can expect to see the results of your work in weeks or months.
As a head of engineering — a manager of managers, 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, messengers, 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, messengers, 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 are comfortable with, and adjust your ambition accordingly. Blindly attempting to climb that career ladder indefinitely is very likely not going to make you happier.
No more boundless career growth.
I, perhaps naively, always thought “I want to be CTO one day: the biggest team, the biggest impact, the fanciest title, _yeah_!” However, 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_, 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.
Here is my point: as you climb the management ladder, you will realize that every step is very different from the last. One may be solid, cold and somewhat slippery. The next, thick, wooden, but a bit splintery. Neither is “better” nor worse by themselves, 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 a decade my senior. Most of his career he worked in the engineering manager and equivalent roles. He seemed perfectly happy with that. He mastered his tools. He knew how where and how to have impact. He was happy with his time horizons. He found his spot.