My name’s Gavin Barton, CTO at Rentalcars.com. I am going to share with you, in a multi-part blog, the journey our Software Engineering team at Rentalcars.com has gone through over the last few years. There is no end date on our evolution as, in the true spirit of Agile, we will keep inspecting and adapting throughout our iterations. The initial part of our Software Engineering evolution has been focused on:

  • Building cross-functional product teams
  • Embedding agile practices into teams
  • Starting the shift towards Continuous Delivery and DevOps
  • Laying the foundations to shift to domain-based services architecture throughout our stack

In other words, we have great cross-functional teams that collaborate and own their stuff, we release regularly, and we give our people control over their products by taking a domain-based approach. To achieve all this, we must have teams who focus on the customer, have solid Engineering Practices and have the right tech to do the job. We are now on the journey and still have a way to go but its exciting to be part of shaping the journey with the team.

Where our journey started

At the start of our journey, we focused on 3 key themes:

  • Building our team
    • Reinvent our Engineering community and brand
  • Shaping our ways of working (Engineering Practices)
    • Focus on the Delivery practices and tools required to deliver high-quality and robust solutions
  • Reviewing our Technical Landscape
    • Map out our systems
    • Start to socialise and educate the need to consider Best Practice, Resilience, Adaptability and Scalability
      The rest of this first blog will focus on building our team.

Building our team

The first major goal for us was laying the foundations for our teams, with a clear career path and set of competencies. We iterated on a career framework with the team and did the following:

  • Introduced an in-role promotion scheme. This gave everyone in Engineering the ability to move to a more senior role by developing in their current role. While manager roles are based on vacancies, tech track roles are not – so the whole team can move into more senior roles over time, without being limited by vacancies.
  • Introduced a Technical and Manager track for our Engineers; we found that some engineers do not want to manage people.
  • Introduced a basic pattern for our Engineer careers, consisting of 4 roles
    • Engineer
    • Senior Engineer
    • Engineering Lead
    • Principal Engineer
  • Introduced some levels within the Engineer and Senior Engineer roles, so we could remove Junior and Graduate job titles, reducing hierarchy and giving Graduates and Apprentices an equal voice in the team. These levels are purely for each individual’s career development, so they are not shared with the rest of the team. Instead, everyone became either an Engineer or a Senior Engineer in their respective discipline (for example, Software Engineer, Senior MIS Engineer or Senior Test Engineer).
  • Removed the Developer and Tester job titles, instead calling everyone discipline based Engineers. Software Engineers and Test Engineers. Subtle but intentional, putting Engineers on a level playing field and removing the Developer / Tester divide.
  • Recruited managers who understand the job technically: rather than being General Managers, everyone must be hands on and be able to go into the detail. ‘Hands on’ is an overloaded phrase and shouldn’t be confused with being in code: we see ‘hands on’ being ‘in the appropriate level of technical detail for the role’. So Architects can be hands on at the strategic level and systems level, but do not need to necessarily be into the detail at the class level.
  • Introduced a Skills and Competency framework that the team use to build up their personal development plans.
  • Introduced Graduate and Apprenticeship programmes.
  • Introduced a Skills Coaching Programme.

The following is a visualisation of the career paths. The % distribution of duties is only a guide: it will vary day to day and team by team.


Skills & competency framework

We introduced a skills & competency framework that provides a framework and guidance for our team to grow, focus and develop their experience.
Building a framework was tough, as we needed something that was generic enough to allow people to be flexible within their roles, but specific enough that they could use it on a practical basis.
Our framework is based on 5 skill levels per competency:

  • Aware
  • Familiar
  • Proficient
  • Highly Proficient
  • Expert

We have two parts to our Engineering Skills & Competency framework:

  • Common Competencies that are common across all disciplines,
  • Specific Technical Competencies that are role specific – for example:


That’s it for the first part of this blog, in my next post I will continue with the Building the Team theme and will focus on Recruitment, Graduate and Apprentice programmes.