Levels of war and technical leadership
Levels of war are usually listed as 3 but sometimes as 4:
- political
- strategic
- operational
- tactical
A quick tour
Most software engineers (and affiliated professionals such as infrastructure, QA, ...) will have overall only an experience of the "tactical" level. The tactical level is where we do the work: write code to build a feature, fix a bug, make an interface, set up a database cluster, ...
As you grow into seniority, you will most likely start to do some operational-level work. In practical terms, it involves developing plans and gathering a series of actions to solve an operational objective. An example would be to devise a plan to add a chat interface to a web application. To power that chat, several bricks need to be in place: the user interface part, the storage part, the notifications part, etc ... Putting together the plan to ensure all those parts come together is the operational part of the work.
Then, as you become Technical Lead, Principal or Staff engineer, and CTO, you will get to be involved or even decide the strategic level of work. That has to do with sketching up the direction and aim your organization will take. It also encompasses how your organization will get there. Reusing our previous example would mean drawing up the plan to add "direct communication lines with customers" in your product, defining what those communication lines are, assigning resources to that effort, and entrusting someone with operational leadership.
As an early technical lead or CTO in a small structure, you won't have to work much with politics, but be aware that the bigger your team and company will get, the more likely you are to consider that level too. This will have to do a lot with taking part in the defining of the vision for the company and the policies in and around it. This also has to do with working with all factions within the leadership, what they want, how they interact, and how they work.
So?
Having names for things allows us to sort and interact with them rather than be overwhelmed by them.
As a leader in your organization, your role will move you up through those levels so that as time passes, you will be less involved with tactical things and more and more with operational and strategic items.
In all practicality, you will have to learn to guide others to do the tactical things rather than doing them yourself. As you still gather pace and experience, you will, in turn, teach others to do the operational stuff rather than doing them yourself. Etc ...
That's why knowing those levels is exciting and valuable. By sorting activities under those labels, you will be able to quickly decide if that's something for your desk or someone else.
What if I don't like it?
You are always free to change gears, move back or move to something else. One of the best decisions I made around 2015 was to request to be a technical lead inside the engineering team rather than the CTO. The CEO accepted and made a great hire (in my opinion) for the CTO role. I was happier in the Tech Lead role and did better work there while the new CTO was able to establish a strategy. At the time, I was not experienced enough to be a CTO; I needed to learn quite a few things before taking on that role and being good at it.
Be honest, communicate with your colleagues, and figure out something.