RTE's vs Program/Project Managers

An RTE is a release train engineer. They would typically support a program manager(s) and help facilitate (Kaizen) continuous?management by collecting data from program?owners or end-user?experience via (UX). RTE typically possesses business skills versus technical IT skills such as a Java programmer.?

They are individual business analysts focused on run and support versus build activities. RTEs traditionally have degrees in business solutions versus IT and focus on delivering measurable value to an organization using a variety of agile?frameworks.?

The goal of an RTE is to deliver value to the organization via software release management. RTE's are typically diverse in QA (Mainly UAT) and incremental?release management with IT and business owners. RTEs are typically only utilized in large organizations within individual teams greater than 150 users (for example finance, customer service or marketing) and have in-depth knowledge of one of those areas?They focus on short-term initiatives?versus long-term initiatives and product roadmaps.???

Key responsibilities of the release training engineer

1. They are responsible for managing guidance, mentoring change and coaching users such as scrum masters on agile tools, and facilitating when needed. RTE's typically are not involved with project management, but instead focus on reducing bugs and minor changes to existing solutions. Support versus build focus.??
2. RTE's assist in providing road mapping statuses and schedules in incremental?timeframes (Support focus) for program managers.?For example RTE's are responsible for gathering, and documenting annual calendars, evaluating team readiness/availability and sharing continuous?support initiatives. Similar to a scrum of scrum managers?they report on readiness to begin projects and resource availability, and are responsible for managing the adoption of a project from build to support teams (IT and Business).?
3. RTE's reports on the accomplishments of IT teams and is responsible?for ensuring improvements are completed on time. A good chunk of the communications are around retrospectives of completed initiatives. They are responsible?for easing system changes, showing progression, and providing demos (before and after data).??
4. They provide feedback on resourcing to address critical blockers and delays for PMs and supporting managers. A good example of a function provided would be to work with product owners, review SLA, and ensure headcounts are in place to support programs.??
5. They are traditionally focused on operational improvement?(OPEX) support versus CAPEX (Capital expenses/large projects). They focus on operating within the?budgetary constraints.
6. They collaborate and support PMOs to ensure proper execution of Agile reporting and focus on operational training of team members to track, report, and improve their adaptation of agile tools such as JIRA, or PMO-based applications.?
7. They are responsible for communicating and collaborating with product and solution management, product owners, and other stakeholders to guarantee the alignment of strategy and execution of plans.
8. They typically?manage metrics, provide interpretations of metrics,?and guide program managers.?

In addition, successful release train engineers possess strong communication, negotiation, and critical thinking skills, the desire to be a lifelong learner, and a solid acceptance of the servant leadership philosophy. As a servant leader, RTEs are expected to:

• Think of the big picture, beyond the day-to-day activities;?

Furthermore, release train engineers should be people of integrity; they should treat everyone fairly and hold themselves accountable for their words, actions, and mistakes. Finally, RTEs should be strong presenters and facilitators of conversation as well as supportive and influential teachers and mentors.

RECAP: Release train engineer vs. program/project managers

While release train engineers and?project managers?possess similar capabilities -- such as issue,?risk, and dependency management,?quality assurance?and time management, people and communication management, and?cost management?-- they also perform different responsibilities.

For example, while project managers handle scheduling and scope or change management, RTEs do not possess these capabilities,?they focus on improving relationships and buy-in.?

RTEs are responsible for release training, monitoring the use of standardized scrum tools, training teams on how to use them, and typically acting as scrum masters. RTE's typically are responsible for the show and tell of progress, and demos of changes to internal?teams.??

A project manager typically does not deal with managing the scrum meetings and is focused on reporting and change management.?

An RTE is typically concerned with mentoring scrum teams, nurturing skills, and changes into small increments to get buy-in from workers, and UX teams to improve the work environment.

In short RTE's typically are compared to release managers who are responsible?for environmental maintenance and progression from a testing?state to production. They are responsible for resource coordination when projects are handed over from the build teams.?They are responsible for the adoption of changes/support from internal teams/product owners.??Please note RTE's are not official positions, but provide a series of services similar to a business analyst who is collecting a backlog of change requests/improvement requests for a program versus a single project.??

Depending on your PMO methodology RTE's may not exist and responsibilities could be mixed across several roles.

Feel free to ask any questions. *This article is opinion-based since RTEs are based on best practices not supported by multiple PMO methodologies. If you believe this article is incorrect please comment, on the post. I've read several articles with conflicting views including PMI articles.