InLeading SAFe 6.0, theRelease Train Engineer(RTE) is described as“a coach for theAgile Release Train.”While this is definitely part of the role, it is not the whole story. In a recent RTE certification class, one participant shared that leaders in her organisation were completely undervaluing the role based on the description inLeading SAFe. Interestingly, we are also finding that this description is creating some confusion about how the RTE role differs from theSAFe Practice Consultant(SPC), as the SPC can also be a coach for the ART.
In previous versions ofLeading SAFe, the RTE was described as“the Chief Scrum Master for the train.”If you have read my views on theSAFe Scrum Masterrole, you probably will not be surprised that I find "Chief Scrum Master" to be a more accurate description than “coach for the Agile Release Train.” Just like aScrum Master, RTE should be passionate agilists with the gumption to call out non-lean-agile behavioursfrom peers and stakeholders.
The Evolution of the Release Train Engineer Role
InAgile Software Requirements, the source of the originalSAFe Big Picture, there was no RTE. There was a facilitator forPI Planningwho most likely came from a program management background. InAugust of the next year, version 1.0of the framework was published at scaledagileframework.com. This was followed by version 2.0 in October 2012, and in this version, the role had a name - Release Train Engineer.
The original responsibilities of the Release Train Engineer included facilitating important ART events likePI Planning,Inspect & AdaptandScrum-of-Scrums(now called Coach Sync). They also facilitatePI execution, escalate impediments, manage risks, and lead continuous ART-level improvement. Perhaps most importantly, the RTE was a servant leader whose primary focus was supporting the teams on the Agile Release Train. The early RTEs mainly came from program management, project management or development manager backgrounds. (For those wanting to take a longer trip down memory lane, check out theoriginal RTE guidance article on Wayback Machine.)
For the most part, theRelease Train Engineerrole is not dramatically different today. It has evolved to place a great emphasis on coaching and an explicit expectation around optimising flow, as illustrated in the SAFe 6.0 RTE responsibility wheel below.
Where do Release Train Engineers come from?
In 2014, I was in Boulder, CO, as part of the 2nd cohort ofSPCTcandidates (along with friends Joe Vallone andInbar Oren!), attending an exemplaryImplementing SAFeclass taught byDean Leffingwell. On this occasion, when Dean reached the section on the RTE role, he took a quick survey asking which attendees were RTEs and then how many of them were previously program managers. As I recall, about a quarter of the class were RTEs, and 80% were previously program managers (includingAdrienne Wilson!).
Over the years, most RTEs I have worked with have come from Program Management backgrounds. This makes a lot of sense to me. As a rule, Program Managers are used to dealing with delivery complexity and organisational red tape, and these skills are useful to an RTE. They are also usually skilled in leading larger delivery teams with significant budgets. We usually recommend that organisations source RTEs internally as we can teach someone to be an RTE, but it is much harder to teach someone to navigate a specific organisation's politics! That said, an internally sourced RTE needs the relationships and credibility to be accepted, trusted and supported by all the ART’sBusiness Owners.
This doesn’t mean every Program Manager will make an awesome RTE. This is both a delivery and people-centric role. In our experience, the RTE sets the tone for the culture of the ART. Will the RTE you have in mind be the sort of person who will championTribal Unityand a one-team culture? Will they host and advocate for aUnity Hourfor their ART? Will they create space for and encourage learning?
The right Program Manager for the RTE role will have a learning mindset. Some of the best RTEs I have worked with have been self-educators, or what Dean Leffingwell calls “lifelong learners.” They read books, follow blogs, attend conferences, and sign up for training. They are also humble. They know what they don’t know, and they ask for help.
The other two backgrounds I have seen RTEs come from are Project Manager and Scrum Master. In both cases, the individuals can struggle to make the leap from working with smaller teams to leading a team of agile teams. A good RTE is a systems thinker. They can see the big picture and don’t get lost in the weeds. This can be a significant learning curve for some Project Managers and Scrum Masters.
Of the two, I think Scrum Masters are perhaps best placed to make the transition, as they, at least in theory, already have the right mindset. Scrum Masters working on Agile Release Trains can start to build skills for leading at scale by stepping in for their RTE when the RTE is unavailable for ART Events.
The bottom line is that RTE is a huge role with a significant amount of responsibility and a massive workload. When selecting the RTE for your ART, choose a person you trust to lead a team of fifty to one hundred people and facilitate the delivery of an annual program of work in the vicinity of $5 to 20 million USD.
A final consideration is the right level of seniority. We like the RTE to be a peer of theProduct Manager(s)andSystem Architect and senior enough to be able to walk into a Business Owner’s office or pick up the phone when they need help and have that Business Owner listen and act on the information.
While there is clearly no one-size-fits-all approach to selecting RTEs, having clarity about the role's size and influence is a good place to start. Then look for someone who is outcome-focused, has a learning mindset, behaves as a servant leader, and has the respect of the teams, their peers, and the ART’s Business Owners. Yes, you are looking for a unicorn, but I promise the search will be rewarding.