Defining Career Paths in Tech

Technology undeniably dominates the world today. It is the driving force behind today’s start-ups and is deeply involved at all stages of the business, from process to product. In order to survive and thrive in this rapidly shifting landscape, tech departments must be aware of changing demands. They’d need to adapt organisational structure to clearly mapping out career paths for software engineers. In turn, software engineers who possess insights into their career paths and options will be better able to master their respective domains and build new skill sets.

A possible start-up career path for tech people eyeing such opportunities could be: in a founding team of five or so members, your role and position might be that of a software engineer, responsible for building your new company’s technology capabilities from the ground up. In a larger team of 10, you might then become a team leader, responsible for leading other engineers towards the company’s tech needs and targets. Suppose your company continues to grow – at 30 employees, you might find yourself overseeing more people as head of software engineering, or processes; at 50 employees and beyond, you would then become a CTO (chief technology officer), mapping out the company’s strategic tech direction according to your vision.

However, that’s just one example - tech-centric career paths in a company are often influenced by the organisation’s growth and business needs on a case-by-case basis. At the beginning, you would likely not have an idea on how much your tech team will grow. Start-ups may not even survive long enough for the long-term tech planning to become reality.

Throughout every growth stage of your start-up, its organisational structure will look very different – between a small team of founders and an established company numbering some hundred employees, tech roles will be redefined, created, splintered off and delegated. In the founding stage, when the start-up pioneers don’t have defined career paths to follow, the most technically inclined team member or initial hire can by definition be considered the CTO. However, what does the position actually mean at this level? In your start-up, is CTO just a glorified title, or does it come with the roles and responsibilities expected of a c-suite executive?

For start-ups, many aspects surrounding current and future growth and organisational structures can be unclear and uncertain. Whether you’re engineering or managing software engineers, this piece will help throw some light on the paths ahead.

Growing and Defining Career Paths

Defining a career path as a leader for a small team is very different from doing the same for a big team. Within a team of five, it would indeed be hard to establish fixed roles for employees to grow towards, especially when these are at the managerial level. Instead, adopt a collaborative mindset and work with your tech team to figure out the direction that growth is expected to take, and pinpoint the likely areas your team members can grow in – even if actual progress hasn’t been made yet.

When your team has 10-20 people, team lead and managerial roles begin to take shape, waiting for capable employees to assume these positions. They will need to be formalised within the organisation, and leaders must step up and follow through. With a group of 50, the CTO (or equivalent) should then identify and then build smaller, specialised teams and populate them with capable employees.

To clearly illustrate organisational hierarchy and internal growth opportunities, you can segment career progression within start-ups into five levels. Upon reaching the top level (henceforth known as level 5), high-performing employees can then choose to either transition into management roles or become technical specialists. Some options open to the specialist route include systems architect, product development or maintaining tech infrastructure; such intensive roles will allow them to build their skill sets. Those that choose to move into management will have many opportunities to hone their people management and communication skills.

At each level, the scope of influence and corresponding expectations should be clearly defined. For instance, an intern’s scope of influence is very limited, and the expectation for them is just to deliver on small tasks as requested, under guidance. From what I have witnessed, it is possible for an intern to convert to a full-time entry-level employee (level 1) within three to six months of successfully hitting performance benchmarks; subsequently, it would take around a year to further progress to the second level.

If you design career progression around levels, those making the journey will have a better understanding of what is expected of them, and what it takes to climb to the next level. At the same time, one can exponentially increase the requirements and expectations of each subsequent level; as the company grows, simply adding more levels is not the solution, or you’ll end up with an unnecessary, complicated scenario where your company has 20 or even 50 levels, making promotions less meaningful. As the team or department expands, expectations of individual levels should also be revised to keep the model relevant.

Choosing to Manage or Specialise

If you are on the management track, your scope of influence covers your responsibility toward your people and the product development process. You would normally manage a team of five to six, and part of your role is to communicate technical advice to the non-technically inclined team members. Dealing with people is a large part of your work, and while you should have the technical competency of a level 5 software engineer, you are not expected to be the most proficient engineer in the team.

Some experienced engineers may not see themselves as leaders and might not be comfortable managing other people. If you are in a position to influence their role, you may want to push them to realise their untapped leadership potential and convince them to accept the role of a team lead or a manager.

As a specialist, you are more focused on software engineering. Your scope of influence is mainly domain-oriented – for instance, you may be a domain expert on implementing payment technology. On matters of payment modules and how they can fit into the overall product, others will then rely on you to handle them. Recognising your role as a specialist, they will defer to your best judgment on how to implement the payment modules.

If you’re unfamiliar with salary matters in the technology industry, you may be shocked by how certain engineers may be paid more than their managers. Despite their lower position on the hierarchy chart, their higher salaries are warranted due to the emphasis placed on their knowledge, skills and capabilities. As a CTO, I would want to hire someone smarter than me to develop my product.

Recognising that you are not the smartest person in the organisation as a CTO is important, as it helps you reaffirm your role in helping others grow and develop; part of this recognition is accepting the fact that those below you might be paid more. CTOs should be the best leaders, but not necessarily the best software engineers – they should grow the department and the business by seeking out and hiring the best people for the job, rewarding their interest with generous salaries.

If you’re interested in the leadership path, you must be able to empathise with your team in order to effectively coach and mentor them. As tech managers, you have the ability to look at issues from a different perspective, as you have greater exposure to things outside of software engineering. This big-picture, goal-oriented viewpoint will benefit both leaders and specialists. A second pair of eyes, whether from a manager or specialist, will help in giving suggestions and managerial assistance for a holistic understanding of the situation and the factors at play – the team can leverage this to develop a better product.