Design thinking tools to boost your DevOps journey – part 2

Isaac Perez Moncho was at the National DevOps Conference 2021 at the British Museum a few weeks ago and gave a talk about how to design thinking tools to boost your DevOps journey. Here is the second part of this talk.

In part 1, we followed William Blacksmith on his collaboration journey. In part 2, we will find out what these three techniques are called in the 21st century and understand how they can help you increase collaboration within your organisation.


Before we start, we should review the impact of the traditional lack of collaboration between platform teams and product teams.

The feared organisational silos are an example of a lack of collaboration. They had two negative consequences for platform teams:

  1. Teams had to support applications they knew little about.
  2. They created platform services that were suboptimal for product teams.

The first consequence is better addressed by following the “you build it, you run it model”, which is out of the scope of this article. The second consequence, creating suboptimal services for product teams, is addressed through better collaboration and using techniques like the ones Will used.

The organisational and business impact of suboptimal platform services can be substantial. Lower performance from product teams means a slower response to market changes and lower capability to deliver business plans. The negative impact is likely to compound in the current hiring environment, with no shortage of companies with excellent platform services like Netflix. Software engineers expect better from the services they use. Having outdated tools and services will frustrate them, making them more likely to change jobs.

In my previous role, the platform team created a “self-service” monitoring service, complete with a 20-page installation guide. It did not make product teams happy.

The goal of Will’s techniques is to increase collaboration between platform teams and product teams. Better collaboration results in better tools, better relationships between teams, and more satisfied engineers.

Now that we know the benefits of Will’s techniques, we can get into them in more detail.


User Surveys 

The first technique Will used was User Surveys.

What is it?

A low-effort technique to asynchronously gather feedback or requirements.

How is it done?

Ideally, user surveys are conducted using tools like SurveyMonkey, Google Forms, or other survey tools. They can also be done via Slack or Email.

My personal preference is for short surveys, three to five questions, using a survey tool. Short surveys increase the response rate by reducing mid-survey dropouts. A tool like Google Forms enables data gathering and a better analysis of the responses.

Three questions you can use to get started are:

  1. Would you recommend our services?
  2. What would you improve?
  3. What would you keep?

The questions can be geared towards one service or to all services managed by the platforms team.

Why is it used?

User surveys are low effort for both the creator and the subject and can be done with frequency. Surveys help create a continuous feedback loop and show to the users that you care about their input.


User surveys can feel impersonal and cold, which can garner more honest feedback and requirements. However, they will not create strong personal relationships between the teams.



The second technique Will used was Shadowing.

What is it?

Immersion in the users’ journey.

How is it done?

Involves engineers (DevOps) observing users (Software Engineers).

The DevOps engineers will observe the software engineers while they use the platforms’ tools. The observers take notes and ask questions when required while taking into account the observer effect.

Why is it used?

Shadowing makes the pain points of the tools and processes visible and fosters relationships between individuals.


Adds a personal dimension to the feedback gathering process.

It can take more effort to use than user surveys. However, it can also increase collaboration by establishing or improving personal relationships between teams and individuals. It requires coordination between individuals, and remote shadowing can lower the usefulness of the technique.


Idea Generation

The third technique Will used was Idea Generation.

What is it?

A brainstorming session with plenty of post-it notes that includes software and DevOps engineers. Engineers generate ideas to solve the problem at hand. The objective is to generate a solution that the platforms teams can implement to solve a problem experienced by the product teams.

Idea generation techniques can be used to structure and inspire the participants. Some of the techniques include Mind-mapping, S.W.O.T analysis, and Six Thinking Hats.

How is it done?

Invite representatives of all involved parties, have post-its ready, and select an idea generation technique.

After gathering enough ideas, spend time pruning and consolidating them. The organiser, or assigned person, will take action and next steps to develop the ideas generated.

Why is it used?

There are several benefits: a broader set of solutions, ice-breakers between teams, deep user understanding, increased collaboration, and relationship building.


Idea generation can be the more powerful technique to use in terms of enabling collaboration, but it is also the riskier one and the technique that requires more effort to use. The session must be conducted in some order and produce an actionable output that will be considered when creating the solution.


Now you have two techniques you can use straight away to start fostering collaboration between teams, User Surveys and Shadowing, and one that can bring it to the next level, Idea Generation.

To finish, I’d like to recommend the following book. It contains the above and many more techniques, case studies, and resources that you can use to think about user involvement when creating your platform services: This is service design thinking.


Article written by Isaac Perez Moncho, Head Of Infrastructure at Lending Works