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.

Even as leaders design career paths, they must also be able to secure trust from their teams. In a small start-up, it may be hard to convince an employee that you want them to become a manager in the future, if that role does not currently exist yet. As the future is unclear and full of variables, you can’t promise them a clear pathway, but you should make them believe that you are invested in their development and that there is a path you want to take them on.

Empty promises are not enough to make employees believe that you believe in them – communication is the key to making the ideals line up closer to reality. It’s not easy to communicate your expectations for each level of career progression throughout your team; even as you grapple with the ambiguity of the roles created, you also can’t narrow and simplify expectations into a checklist, because not everything can be quantified. For instance, a level 5 software engineer would need to be proficient in systems implementation, but you can’t assign a specific value to the word ‘proficient’. At the same time, skillful communication is needed to reassure dissatisfied employees who may feel that they are not being pegged to the right level for the work they are doing.

Beyond strong internal communication, you can also reach out to other companies that have undergone a similar growth journey as what you have planned, bringing their representatives to your employees to share best practices and examples of developing career paths as the company scales up. We have previously invited friends from Facebook and Google to speak to our team members on this very topic.

Maintaining good communication and employee passion is a constant work in progress – there is no definite end-point for it, no matter how fast or slow your company grows.

What Makes Software Engineers Tick

Being aware of tech employees’ unique traits is key to understanding how to manage them. Most do not perceive software engineering as a creative process, unlike how they view designers or artists. While engineering is logic-heavy, a creative process is required to discover solutions – developing such a process entails a lot of thought, problem-solving and critical thinking. If you don’t consider these aspects, you may face problems trying to empathise with engineers. At the same time, due to the nature of the job, software engineers are usually rational, curious problem-solvers with a tendency to question everything.

If such employees are subject to certain rules (for instance, coming in to the office at 9am sharp), they will seek a logical explanation behind these rules. If they don’t find one, they might see no rationale to follow the rules and run afoul of HR; in turn, HR might communicate to the engineers’ team leader that they are being troublesome and non-compliant. Without understanding the context of the engineers’ actions, a manager might inappropriately discipline them and create friction within the team. Engineers appreciate clarity and will be satisfied if a particular instruction makes logical sense.

From observation, newer generations of engineers seem more likely to open up, if they’re treated with the same trust and respect given to other people. Conversely, without bringing empathy and respect to the table when talking to them, you will not get them to open up. In turn, if they don’t trust and respect you as their leader, it will be difficult to manage them. For these reasons, an experienced engineer, ideally at level 5, should hold the role of a team lead – this senior employee’s credentials will command more respect from the rest of the team. Firm knowledge on the field will also help the leader ask good questions and obtain useful insights beyond simple ‘Yes’ and ‘No’ answers.

When building rapport with software engineers, beginning the conversation may be the hardest part. You want to find common ground when first talking to them; do note that they love to entertain intellectual conversations. They are not as interested in small talk for small talk’s sake and may be reluctant to talk about their personal lives or what they did during the weekend.

If you want to effectively break the ice, start asking them actual engineering questions or stuff about their work, then listen and get them to go in-depth. Engage them and learn about their creative processes behind solving technical challenges, and why they opt for certain approaches to the problem. As the conversation progresses, they may touch on certain pride points that highlight their enthusiasm; if you respond warmly to these, engineers will see your understanding and empathy towards them, and they will put their best foot forward accordingly.

Moving Up in the Tech World

In this field, learning is constant and you must constantly pursue growth and goals. The technology of five years ago may be obsolete in the next three years – keep an open mind towards training and refreshing your skillset. Don’t upgrade yourself merely because you want to climb to the next level – instead, as you learn new things and expand your capabilities, it will be easier to promote you if you are already handling responsibilities expected of a higher-level employee. If you are already able to handle the workload of a higher position through experience, you will be seen as a safe, proven choice for promotion.

Before committing to specialising or managing engineers, ask yourself some key questions. Do you feel that you have what it takes to lead, with all the responsibilities that come with the role? Are you highly passionate about the technical aspects of software engineering? If management isn’t your thing, you will benefit more by taking a step back, shifting gears and driving into a specific domain that holds your interest.

Leaders in software engineering must be prepared to face challenges by their teammates. Engineers are curious and motivated people; they cannot be micromanaged or expected to just sit down and take instructions. You can only lead with the respect of your people, and part of this respect comes with being a strong engineer. No matter which level or path you end up on, you must be competent in the tech.

1. Ask Yourself the Right Questions

Consider if you’re willing and able to manage other people, or if your true interest lies in specialising as a technical domain expert. Assess yourself and make the choice when the time comes.

2. Communicate With Empathy

As a manager, maintain good communication with your team to ensure that they are passionate and invested in the career path you’re offering. Understand the software engineer’s mindset and show empathy and respect to them to be an effective leader.

3. Keep Learning

As a specialist, constantly pursue knowledge and growth to retain your expertise and relevance in your chosen domain. It is easier to secure a promotion if you prove yourself taking on the responsibilities and expectations of the level above you.