Petro Podrezo Software Engineer

Here’s a chart I put together that highlights an example of what the roles and progressions look like for engineer-type positions at a hypothetical software company. This chart is informed by my previous jobs and is somewhat an amalagamation of several companies rather than example of any one particular company. Every company is going to modify their structure to fit their needs and culture, but this is a good starting point for understanding the general progression of a software engineer.

The rows in the chart represent different streams like architecture and management. The horizontal position loosely represents the seniority in the company.

Team Lead

Let’s get the odd one out of the way first - you’ll see in the above chart that team lead is not a separate role that has a specific box for it. The reasons for this could be that the team lead role is a temporary one and is more of a responsibility than a role. It’s not uncommon for a company to have a team lead for a project, and then for that person to go back to being a regular engineer once the project is complete. Secondly this role can be thought of being “in addition to” rather than a “replacement for” the other roles on this chart. That is, you might still be a senior software engineer but just happen to be the team lead for a project - it is an additional designation. That being said, some companies may opt to make this a separate role depending on the need.

The responsibilities of a team lead are often to coordinate the efforts of the team, to be the point of contact for the team to other engineering teams and departments, and sometimes to be the person who is responsible for the success of the project. This is a role that is often given to a senior engineer, but not always. It could be given to someone who is not a senior engineer but who has shown leadership qualities or who wants to get a taste of what it’s like to be a manager since there is some (though minimal) overlap between the two roles.

Engineering Stream

The engineering stream (software engineer, senior, staff, principal, etc.) is an independent contributor (IC) role meaning that you do not have any reports (any people who report to you, like a manager would). Your responsibilities are essentially to deliver on projects which entails not only writing the code but designing the solution, testing it, and sometimes even deploying it. The higher you go in the engineering stream, the more responsibility you have in terms of the complexity of the projects you work on, the impact of the projects, and the mentorship you provide to other engineers. The higher you go, the more you are expected to be a leader in the technical sense, meaning that you are the go-to person for technical questions and that you are the person who is responsible for the technical success of the project.

Senior Engineer: They’re like the experienced players in a team. They’ve got solid coding skills and understand the ins and outs of projects. Senior Engineers often tackle complex problems and mentor juniors. They’re not just coding; they’re also thinking strategically about project architecture and design.

Staff Engineer: Think of them as the bridge between hands-on coding and higher-level strategy. Staff Engineers dive deep into coding when needed, but they’re also big on shaping technical direction and solving larger-scale problems that affect multiple projects or the entire company. They often have a big say in tech decisions and mentor other engineers, including Seniors.

Principal Software Engineer: These are the heavy hitters. Principal Engineers are less about daily coding and more about setting the vision for the tech side of things. They work on complex, company-wide problems, set technical standards, and are often involved in key business decisions.

Architecture Stream

This role is like the master planner. Architects focus less on writing code and more on designing the overall system architecture. They’re responsible for making high-level design choices and dictating technical standards, including tools and platforms. Their job is to ensure the various parts of a software ecosystem work together seamlessly and efficiently. Architects often work on broader strategies, like how to integrate new technologies and how to handle scalability and security challenges.

You might think this sounds very familiar to the principal software engineer role above, and you’d be right that they sound similar but the difference is that the principal software engineer is more focused on the software side of things, whereas the architect is more focused on the system as a whole. The principal software engineer is closer to the application code whereas the architect is more likely to be involved with coordinating application code and infrastrucutre, tooling, and integrations.

Management Stream

When your organization is larger than just a few people, you will proably run into the need to have managers that are responsible for the people on the team. This is a separate stream from the engineering stream because the responsibilities are quite different. Managers are responsible for the success of the people on their team, not the success of the projects. They are responsible for the career growth of the people on their team, for the happiness of the people on their team, and for the productivity of the people on their team. They are also responsible for things like hiring and firing, performance reviews, and disseminating information that reports need to know such as major company updates or initiatives. They are not responsible for the technical success of the project, that is the responsibility of the engineering stream.

Another common responsibility of managers is to have “one on ones” (e.g. one on one meetings) with the people on their team. These are meetings where the manager and the report talk about anything that is on the report’s mind. This could be anything from career growth to personal issues to project issues. The manager is there to listen and to help the report with whatever they need help with. This is a very important part of the manager’s job and is often the most important part of the manager-report relationship.

CTO

If you notice, there isn’t really an arrow leading to the CTO role; this is intentional because it is not something you really get promoted into from any other role. CTOs are usually directly hired as CTOs and often were there since the company’s inception, having started as one of the first developers and going from there.