Our career path for Engineers

Our career path for Engineers

Fostering career development isn’t just something we aspire towards at GetYourGuide, but something we guarantee and outline for all of our employees. Within our Engineering Department, we’ve created a career path matrix for how an Engineer can expect to grow. Here, the term “Engineer” refers to all members of our Engineering teams including Data Analysts and Data Scientists. This career path matrix offers the opportunity to grow either as an Individual Contributor (IC) or in a management role as an Engineering Manager (EM). Within this matrix, both paths are valued equally, and Engineers even have the option to move back and forth between the two.

Our approach to decision-making and people management 

Before we dive into the framework, first a word on our overall Engineering organization from Udi Nir, our CTO. Having received many questions on hierarchy and how we maintain a fast-moving and impact-driven environment at scale, Udi articulates there are two areas where hierarchy can appear in an organization: in decision-making and in people management. In the former, we aim to eliminate hierarchy: 

“The decision-making is as flat as possible — everyone on the team has a voice and everyone contributes. The teams are very autonomous, there is no asking for permission and there is an emphasis on independent work. This works well because it puts the people who actually know the domain and the specific customer or business problem in charge of driving the work and decisions forward. We strive to have the decision made by the smallest group of relevant domain experts, or in the case of internal decisions, the smallest group of people being impacted by the decision.” 

In the latter, however, we aim to use hierarchy to our advantage:

“On the people management side, it’s been necessary to implement a more hierarchical structure so our Engineers have the support they need to perform at their best and grow. It’s about the numbers here. We want managers to pay attention to the people they manage, meaning they cannot have too many reports. This structure is a good thing because it provides the manager time to think about all of the things that matter to the team and better support the team.” 

Regardless of role or level, all of our Engineers are empowered to make decisions, drive projects forward, and hold themselves accountable. 

One example of this is our network of Guilds. Guilds are organized around a technology, discipline, or engineering concept (i.e. PHP Guild, Agile Guild, Frontend Guild, Native Apps Guild, Data Engineering Guild). The Guild is made up of members of all different levels within the Engineering team. As a group, they own engineering decisions for their discipline.  With a well-defined decision-making process, the Guild provides all members, regardless of title or level, the opportunity to make decisions that impact our entire tech organization. 

Growth as Individual Contributor 

EMs and ICs are equally valued for their impact at GetYourGuide, but each path has its own steps and expectations which can be illustrated as an ever-growing sphere of influence, responsibility, impact, technical mastery, and ownership. By focusing on the skills that will allow them to broaden their sphere, ICs naturally progress in their career. A successful IC takes the lead on projects, mentors fellow Engineers, and is considered a role model within the entire company.  

Growth sphere for Individual Contributors

Growth sphere for Individual Contributors

Seniority Levels for Individual Contributors 

Engineer - Learn how to be autonomous in the team 

Engineer II - Execute autonomously, move projects and the team forwards

Senior Engineer - Execute complex pieces of work in the team in a self-sufficient way, sometimes leading other Engineers and proactively improving how the team works

Staff Engineer - Define and lead complex work across teams, create leverage through other people, proactively seeking / creating opportunities to be effective beyond own team

Principal Engineer - Define and lead company-wide projects across groups, create leverage through other teams, effective across multiple areas

We define each step on the IC path with a set of competencies that consider both technical expertise and behavior

Technical expertise and behaviors of Individual Contributors

Technical expertise and behaviors of Individual Contributors

Growth as a Manager 

Once our Engineers become senior or staff, they have the option to pursue a managerial track. This transition is not considered a promotion, but rather a role change. If an IC becomes a manager, they still have the option to later transition back into an IC role. Growth can happen in any direction.

Growth sphere for Engineering Managers

Growth sphere for Engineering Managers

EMs, both internal transitions and external hires, are evaluated based on the performance and success of their respective teams as opposed to individual success. EMs support their teams, steer their teams, and help their teams achieve their goals. Team success is the top priority. Check out our Engineering Manager series for a deep-dive into the framework. 

The 5 components

There are 5 components an EM is responsible for and evaluated upon. Similar to the IC path, each role on the manager pathway builds upon the 5 components listed below:

Team Health - Building trust amongst the team, creating an open work environment, onboarding new hires efficiently and effectively, and managing both low and high performers. 

Stakeholder Happiness - Aligning with stakeholders by setting expectations, delivering on promises, and communicating surprises.

Productivity - Maintaining a sustainable pace, setting the right expectations, and delivering consistently.

Business Impact - Ensuring the team is working on the right problem, measuring the correct metrics, and shipping often to move the needs on important business goals. 

Systems Health - Documenting all services appropriately, conducting reliability checks, and maintaining a dashboard where important system metrics and SLAs (Service Level Agreements) can be monitored. 

The engineering management structure is determined by a combination of team size and discipline/business-domain focus:

  • Team size - This is a pure numbers game. A team of a few people needs one manager. A team of many people need several managers and those managers need a manager too. 

  • Discipline - Specific disciplines deserve their own management organization and the more complex and unique the discipline is, the higher the expectations and the higher the seniority level will be for the leader of the discipline.  

  • Business domain - Sometimes it’s necessary to break the Engineering organization up to focus on different business domains. The ratio of ICs to EMs may then vary depending on the domain. 

We should also mention that when it comes to compensation, we ensure great managers have the room to grow even if the organization doesn’t have the need for a more senior manager role.

Where the two paths meet

This career matrix provides our Engineers with a clear outline of how they can grow and what they need to achieve in order to reach the next level. By providing this path, we give the Engineers the opportunity to own their own development and find the path that’s right for them. 

Although the IC and EM paths are different, one constant is the opportunity for impact. Whether an Engineer wants to grow on the IC track towards becoming a Principal Engineer or wants to grow as a manager to become a Director of Engineering or move between the two, they will have the chance to make their mark on a rapidly-growing industry.  

Learn more about our career path from the Engineers themselves by checking out: 

Interested in developing your career on our team? Check out our open positions




Associate Engineering Manager program - a leadership growth path

Associate Engineering Manager program - a leadership growth path

Engineering Manager series part 6: systems health and how to create a DevOps culture

Engineering Manager series part 6: systems health and how to create a DevOps culture