GitLab support engineering: innovating hidden multipliers for circular economy groupthink

Everybody engineering

Several years ago, it became fashionable to label everyone in different customer-facing and back-end functions as some kind of engineer — but I believe support engineers are the genuine article, if an under-utilised one, in delivering the product that customers pay for.

Starting with individual issues, support engineers can deliver far-reaching, strategic benefits for customers. 

In a recent case, support engineers worked on a client bug that helped the client solve their direct problem, while also building more confidence that the support team are the people that can actually help. 

This interaction also helped the client gain a deeper understanding of the product, which transformed the way the organisation logged code issues, parsed the information and ran its troubleshooting procedures. 

Separately, an organisation working on reducing risk moved from annual to more frequent upgrades of its coding platform after support engineers showed that by deploying code more regularly, the company would be able to troubleshoot faster and greatly reduce its overall risk by increasing deployment confidence.

Don’t cut the knees, please

However, many support teams are cut off at the knees: they may successfully identify the customer’s problem, but once they have achieved this, they are expected to hand off some of these cases to the developers to solve. In another case, an internal support engineering team needed assistance to deal with a software bug they had identified in their own support tool; they escalated the matter to a Level-3 support engineer but found that the engineer couldn’t see the code either.

Support teams are able to grow into their role by conducting wider audits of issues and analysing causes of problems. As such, they can become engineers that are able to fix a larger proportion of customer problems, start to develop a more analytical role and actively contribute ideas. Not just ideas, but code and documentation.

Additionally, there are cultural factors, or groupthink, at play here. 

GitLab’s Matos: Don’t be blinded by corporate cucumbers – companies today need to find more effective ways to open up problems that their customers encounter to their support teams.

Organisations are broadly divided between developers/engineers and [commercial-side] customer support functions and because most developers think in terms of code and are expected to solve problems, support is expected to talk to people. The way that organisations’ product and support functions are set up hasn’t changed radically in a long time. 

Circular economy groupthink

It’s as if a high-end manufacturing company hasn’t looked at the benefits of reusing offcuts of expensive raw materials in a circular economy strategy. Or a retail store has a returns department but has not empowered it to look at why customers return different products or use that data in a feedback loop to improve product design quality. 

Companies need to find more effective ways to open up problems that their customers encounter to their support teams. Currently, engineering teams have too many conflicting priorities — creating new code, reviewing code and more. Support teams have one priority: fix the problems that exist right now.

As we are arguing at our next DevOps industry event, helping companies make their support organisations more capable will deliver a raft of benefits to today’s organisations that depend on software development to:

1. Help their customers do more
2. Fix more problems and gain a better insights into different problems and what might be causing them
3. Reduce problem rates and free up product teams to reduce time-consuming tasks such as bug fixes 
4. Contribute to organizations’ overall code – there are cases where a support engineering function has actively contributed to code over the years, and its support engineering team is empowered to interact with customers and solve their problems.  

Where support engineering teams are empowered to grow their capabilities, realise their problem-solving potential and actively contribute to the organisations’ code, these different factors create a multiplier effect – ultimately contributing to changing the economics of complex software pipelines as well. 

There are essential conditions for organisations to achieve this approach, such as greater transparency/visibility of its software pipelines and their data and greater trust in their software development process. Many firms still have silos or areas of code managed by one person (as in: “don’t go there, that’s Harry’s or Henrietta’s area) that others don’t touch.

I foresee a time not very far away when support agents and CX engineers will be closer to customers’ codebases and will solve more problems more effectively and change the dynamics of software lifecycles. 

Everyone really can contribute.