chapter 5

Next Steps

After exploring the patterns in this workbook, you may be looking for further techniques and approaches to try to help make a remote-first approach work well. This chapter gives some suggestions for further activities and patterns to adopt within your organization to make remote-first, team-centric work as effective as possible.

Design and Conduct a Developer Experience Platform Survey

One of the most important aspects of developing and running an internal platform of any kind is the continual “steering” of the platform features and usability by feedback from internal customers (engineering teams that use the platform). Two techniques that work well to shape the feedback from developers and other engineers are a platform survey and user personas for internal customers.

Internal Platform Survey

To begin with, ask a few simple questions about the usability and experience of using the internal platform. Send the form to various internal customers (developers and other engineers).

Below is a starter survey template for the developer experience. (This is the same form you can use to assess team cognitive load, as dicussed in Chapter 1, but now used in a different context. Given that one of the main purposes of a platform—in a Team Topologies sense—is to reduce cognitive load on teams using the platform, this should not be a surprise!)

Engineering Experience Feedback

With this survey, we want to assess how easy/hard you find it to build, test, run, and support the services your team is responsible for.

Note: answers will not be used in any kind of evaluation/review/appraisal context. Results will be aggregated at the team level.

Answer each question on a scale of 1 (very poor) to 5 (very good).

1.How is the experience of building your services? Things to consider: Is building a clear and repeatable task? Is it fast “enough”? What happens when builds fail? Are failures easy to diagnose?

2.How is the experience of testing your services? Things to consider: Is testing a clear and repeatable task? Is it fast “enough”? What happens when tests fail? Are failures easy to diagnose? Are test environments adequate? Are test environments easy to access/spin up/clean up/inject test data?

3.How is the experience of deploying your services? Things to consider: Are deployments a clear and repeatable task? Do you know what the deployment strategy is? What happens when deployments fail? Is it possible and straightforward to rollback a failed deployment? Do you have access to the necessary logs to understand why a deployment failed and/or its current status?

4.How is the experience of operating your services? Things to consider: Do you know how each service is being monitored and have access to the data? Are adequate alerts (few false positives) being sent? Are logs and information accessible and easy to find? Are data flows across services relatively easy to follow?

5.How is the experience of being on call for your services? Things to consider: Do you know what the incident response procedure is? Do you feel you have enough experience (either real or simulated) to deal with incidents without high levels of stress? Do you know who to reach out to for help during an incident when you’re on call? Would you be anxious about a 3 a.m. outage? What about an incident in a service that hasn’t been modified for months or years?

6.Would you like to comment on your overall engineering experience?

For an example of a more advanced approach to platform surveys, see the excellent 2018 QCon presentation by Justin Kitagawa,1 Senior Director of Engineering at Twilio, where he explains the approach they use to assess and improve the effectiveness of their internal platform. Twilio uses net promoter scores (NPS)—a technique common in consumer sales and marketing—to gauge how well the platform is perceived by internal customers.

Internal User Personas

Work with the user experience (UX) specialists in your organization to define and, most importantly, validate a set of user personas for internal customers (developers and other engineers). As with any user personas, it is vitally important to validate your assumptions with real users. Use this checking process to adjust your expectations about what needs to be built or provided to customers.

The simplest version of user personas is to characterize the goals and frustrations of each type of developer or engineer working with the platform: What do they want to achieve? And what do they find difficult?

Define Naming and Usage Conventions for Chat Tools

In a remote-first world, the chat tool becomes the online space in which work becomes coordinated. An online space that is clear to navigate and safe to use leads to better outcomes for teams.

Work through the suggestions in Chapter 3 of this workbook around naming conventions and usage of your chat tool. The aim is to create the conditions so a healthy dialogue can emerge to curate or nurture a good approach to the use of the online space around the chat tool. Do not be tempted to “design” everything up front: allow some patterns to emerge.

You may need to rework some of the channels or conventions after you introduce concepts like the team API, but that’s fine. The organization needs to become adept at modifying the conventions of the online space as the organization grows (or shrinks) and meets new challenges.

Focus on discoverability or predictability: How easy is it for a new person to discover or predict the channels that they should join? Can you use some “bots” to help with onboarding and suggestions? Chat tool ecosystems typically have several options for automated onboarding help using bots.

Use the Team API with Multiple Teams to Define and Clarify Team Boundaries

In the remote-first world, teams benefit even more from defining the boundaries of their work since there are no physical office spaces to provide this. An effective way to define a team boundary is to use the team API from Chapter 2 of this workbook.

Find teams that are willing to explore the use of a team API to help them work better together as a team. Suggest that teams work together to explore and refine an approach that works for documenting and broadcasting the team API of each team: a wiki, an internal website, a code repository, an online whiteboard tool, or something similar.

After a suitable, workable approach has been established, hold a series of showcase sessions where teams that have started using a team API can share their experiences with other teams. Explain why the team API is being introduced and how it can help to increase the clarity of purpose for teams.

Don’t forget to include details of current and expected team interaction modes within the team API showcase sessions (see Chapter 4 in this workbook). The ways in which teams interact and the purpose of the interaction is a key indicator of organizational effectiveness. Encouraging teams to think about the team interactions will help them to become more effective within the organization as a whole.

Devise and Share an Execution Plan

Meet with other people in the organization to discuss how to try some of the ideas and patterns in this workbook. Begin by identifying which techniques could be most useful immediately and start with those.

Revisit this workbook on a regular basis to see what else you could or should be doing. What have you learned from previous techniques? Can you improve how some techniques are being used?

If you need to increase shared understanding across multiple teams, consider some more formal or structured approaches, such as lunchtime chats, nonwork afternoons, internal tech conferences, etc. These sessions can have a substantial impact if the talks are prepared in advance and the speakers are confident in the delivery of the details. Internal Tech Conferences by Victoria Morgan-Smith and Matthew Skelton provides additional tips and tricks for a successful internal event.