What Ticketmaster is doing about professionalising software careers

“My wife is doing her accountancy exams so is busy tonight, so I’m staying in to look after the kids” is something you expect to hear in every day conversation. But what about “My partner is doing his software engineering training tonight so I’m unable to come out for a beer?” Why is this still unusual? Are software developers still a product of their bedroom and dorm room past, hacking things together and so often saying ‘yes’ when no other professional would in a similar situation?

Software development, let’s face it, is an immature industry. We build software, but not many of our parents generation did. What we often fail to realise is the number of different roles we play. When we started out in software, we most likely will have felt the excitement of building something, and seeing it work. But to get it to work properly, we likely had to do some testing. As our initial projects mushroom, we start to learn various constraints – so without realising it, we start thinking about the design. Then when we have something that other people start using, they might have found a problem with it. So we need to do some investigative work. Then we find that there are additional requirements which can’t be met by the current design – so we start to think about the architecture.

What we haven’t realised is that we’re doing all the parts of what is known as the Software Development Lifecycle (SDLC): Requirements, Design, Development, Testing & Support.

Let’s think about other roles we play in our life. We may be parents, sons & daughters, friends and neighbours. But what about surfers, fans, climbers, shoppers and garage organisers? What we learn from looking at our lives that way, is that if we don’t plan for these roles, or put any time into them, then there are most likely negative consequences. If as a parent, we put no time or effort into parenting, or trying to be better as a parent, then that’s likely going to have a detrimental effect on us and our children. If as a garage organiser we put no time or effort planning or being a garage organiser, then our garage will remain a mess, and it’ll be impossible to find things when we need them.

sdlc

So the same goes for us as software engineers. We need to plan, prepare and learn how to master the different roles we play, or there will be negative consequences. Software support is often seen as less glamorous than developing, but as engineers it requires sharpening our detective skills to be able to find a metaphorical needle in a haystack. This requires a completely different set of skills to development. So in order to take ourselves more professionally, we need to gain an awareness of these different roles, and gain maturity in developing our skills in these different areas.

Here at Ticketmaster we’ve been Agile for over 6 years now, and we’ve come to the realisation that with that level of maturity, multi-disciplined skills are required in order for development teams to continue to grow in a healthy way. When we reviewed our career progression processes across multiple engineering locations, we also found a lack of consistency across job roles and criteria for career progression. We came to the conclusion that without a transparent process that was consistent across all our teams, it was hard to set expectations and provide our engineers with the optimum experience for growing how they wanted to in their chosen profession.

So what we’ve done at Ticketmaster to address these issues is create a career map – a flexible set of pathways built from what we do as engineers day to day, but that provides both a range of options for career progression along with outline steps of how to get there. This provides mastery of any chosen career progression route, with a clear vision of the outcome that you’re looking for as an engineer.

How did we do this? We used a number of industry standard resources, building on the SWECOM model created by the IEEE, and using influences from other industry models such as SFIA. This has enabled us to build a three part progression guide:

progression guide

  1. SDLC skills – these are built up from the SWECOM model and outline 5 maturity steps in each professional skill, built from the SDLC.
  2. Technical skills – these have been built up using a platform and technology neutral approach, again providing a 5 step program of technical skill for all areas pertinent to Ticketmaster’s engineering strategy.
  3. Behavioural skills – we have outlined four areas for awareness and growing maturity that we believe make the biggest difference to our success as a people first organisation: Team work, Innovation, Results orientation, Professionalism. We can’t and don’t want to mandate behaviour, so we provide lots of examples of what maturity looks like at each level.

So armed with a clear map of what is required to progress, engineers are empowered to make this journey with the support of their colleagues. How do we do that? We used the guiding principles from Drive by Daniel Pink.

Autonomy

It was really important to us that we avoid this scenario, which you may be familiar with:dt_c131214

Again, we considered the engineering profession from the viewpoint of different roles, and saw the role of the manager as a coach, like Boris Becker working with Novak Djokovic. We want to create an environment in which engineers can excel, rather than be micro-managed or stressed by unnecessary distractions. So we trained all our managers to operate with a coaching model in mind at all times, supporting and only intervening from the sidelines when required.

Mastery

We’ve empowered our engineering teams by giving them the tools and resources required to progress their careers – and them giving them responsibility for progression. The progression guide makes it clear what is required to progress to the next role. The guide was put together through numerous rounds of consultation, to ensure everyone had a say in how it was constructed. In order to satisfy the requirements of the next role, we have introduced a peer review and assessment process, whereby individuals submit their evidence to show they have mastered the professional, technical and behavioural skills to the appropriate level. What we learnt from engineering led organisations such as Google as well as other industries is not to have a single peer reviewing, but to have a minimum of three to ensure bias is minimised and the process is as objective, fair and transparent as possible.

We’ve rolled out training across all our engineering teams on how the career map process works, and run workshops on how to create suitable objectives in order to reach the requirements for each role. At each stage we have looked to put responsibility for progression with the engineer, but provided suitable support structures to enable and facilitate progression. This includes an online tool specifically created to help manage progress, providing a simple view for instantly seeing what steps are required and a convenient way to store evidence.

Purpose

Software engineering is constantly exploring unchartered territory. That’s why agile has won out over waterfall as a methodology because iterative exploration and learning is almost always better than educated guesswork. Like software projects, software careers are also subject to a high level of flux because of the nature of the industry. Established skills can be rendered redundant overnight by the introduction of a new technology, product or service (e.g. the iPhone, or Uber). By providing engineers with multiple options in terms of charting their career path, we believe that we can avoid exposure to the threat of redundancy of specific technologies by building opportunities for career breadth and depth.

This enables engineers to not only change as the industry does, but also to facilitate proactivity rather than being constantly reactionary, which is far more stressful. Undue stress does not contribute to a healthy working environment, which is what we’re constantly striving for.

But we’re also looking to professionalise our industry, and make software engineering an even more exciting destination than it was a generation ago, when it was really in its infancy. By building our approach on existing standards and the best disciplines from other industries, we’re aiming to show that we’re part of an extremely vibrant but also professional industry which will endure for millennia to come.