Engineering Team Partnering

Working with Engineering teams should be a partnership to be truly effective. As one of Engineering at Storio’s core tenets is ‘You build it, you own it’, SRE can not and should not be the people who run applications on behalf of or provide black box solutions to our partners in Engineering because this directly contradicts the tenet of ownership. However, it’s also important to recognize that Engineering Teams (ET’s) have different needs when it comes to their partnership with SRE; there is no one-size-fits-all model. Engineering Teams commonly use different technology stacks, in different ways and rely on different platform components, as well as having their own level of maturity with cloud platforms, observability and the other core pillars SRE leverage strategy on. This means that there is no one-size-fits-all model that can be applied for how SRE partner with Engineering Teams. To create some type of standardization, we’ve laid out three different engagement models which adapt the partnership based on the needs of the Engineering Team.

Fully Embedded

A named SRE will attend all ceremonies of the partner team and effectively act as a member of that Engineering Team. This model is most suitable for teams that have a low maturity in cloud native systems and a substantial, long term problem they wish to solve that will continue to need SRE support post resolution. The embed is a collaborative approach; the SRE is there to help design a solution to a problem, support implementation and then to share the knowledge on the solution across the ET, ensuring that ownership of the solution is adopted by the ET. Periodically, and to the needs of the ET, we’ll endeavour to rotate named SRE who is part of the ET in order to stop the creation of single points of failure.

Partial Embed

A named SRE will attend core ceremonies as defined by the EM of the Engineering Team. This model is most suited when a team has a particular project outside of their skill area and they would like help implementing it, but the project has a natural and relatively short end point. A good example would be a PoC of a new frontend framework. Similarly to full embed, a successful interaction includes a graceful exit to as the ET are fully empowered to own the solution that has been created.

Ad Hoc

A SRE won’t attend core ceremonies of the Engineering Team, and the main method of contact between the ET and SRE will be via the support channel. This is by far the most common model and is suitable for ETs who have a high cloud native competency and level of independence. SRE in turn prioritize supporting ET’s operating in this model as per the priorities of the wider organization.

Choosing a model

The needs of Engineering Teams naturally change over the lifecycle of their projects and to that end, picking one model at the start of an interaction and never varying it does not work. To that end, SRE will review with the EM of each ET that the engagement model between SRE and the ET is the most suitable for the next Quarter’s work. This will let us shift gears on a regular basis, so for instance if an ET is about to work on a particular project with lots of unknown cloud work, they may chose to shift in to a partial embed model for the next quarter. Equally, if an SRE is in a full embed mode with a team, but there is not work there to satisfy utilization of the SRE’s time, they may chose to trigger a conversation with the ET’s EM to shift down a gear into a partial embed or to ad hoc levels.