This is the fourth and last articles of my series about deep work. The first article was about the value of deep work for peak performance. The second article was about seven tips for more deep work for individuals. The third articles was about deep work for teams.
The developer experience team at BRYTER was rather fluent on the scale from pure-platform to pure-enabling. Depending on the topic and its maturity in the organisation, we would either choose a platform- or enabling-approach. Furthermore, close collaboration and communication with other teams ensured that we stayed connected and worked on the most relevant things.
To some extent, our team came close to what others would call a software reliability engineering team. Unless: software reliability was not our focus. Nurturing high developer productivity and experience, was.
Naturally, our team had a wide range of knowledge and topics. Our work rabid from developer tooling over delivery pipelines, architecture, and infrastructure. We also were the driving force behind introducing true continuous delivery.
Obviously, we were the first team, engineers would turn to, if something did not work as expected with everything from building over linting and testing to deploying, running and monitoring.
In short: Whenever something went wrong, we were one of the first teams to know. Not necessarily because it was our responsibility, but because we had the knowledge to solve the issue and help quickly. Furthermore, we were very approachable. This was intentional.
Needless to say that such a dynamic makes deep work impossible, if you don’t channel and control it.
I believe that this is true for many platform- and enabling-teams. You want to stay in touch with other teams, help quickly, where help is needed and still maintain a significant amount of focus and deep work for some bigger topics. Finding the right balance is not always easy.
Six Mechanisms for Deep Work
In my opinion, our team found a pretty good balance. Therefore, I am sharing six mechanisms that helped our team to stay on top of all the requests and distractions while finding enough time for deep work without turning everybody down.
1. Week Kickoff
Our team would always start the week together on Mondays with a “Weekly Kickoff“. Firstly, this was a personal checkin to see how everybody is doing, to share stories from the weekend and to reconnect. Furthermore, we aligned on topics that were open from the previous week and discussed things we wanted to achieve this week.
Thereafter, we started to collaborate on the one or two most important topics of the week. This could, by the way, also mean collaborating with other teams, if there were some more urgent requests.
2. Scheduled Collaboration Times
Throughout the week, we had at least two blockers of 3 hours in our calendars for collaboration times. We also collaborated outside these blockers often, but these blockers were reserved for the team to reconnect and work together.
3. Support Rotation and Support Slack Handle
As we would regularly be pinged for things outside our team, we introduced a support handle in Slack and reminded people to use it. Every week, two other people from the team would hold this handled and react to requests from outside the team. This made sure that the rest of the team got more focus time while still maintaining close contact and short response times for teams that needed us.
Side-note: As we never wanted or had a formal team lead, we rotated a couple of responsibilities like this. Some of them were:
- Being on support rotation
- Managing the inbox (see below) and other requests to the team
- Facilitating the weekly kickoff
- Posting our weekly update message (we wrote it collaboratively)
This made sure that the entire team was equally capable of doing these tasks, and we did not have a single point of failure, a risk that many teams with a formal team lead have.
Side-note 2: We also reflected on the meta-level of requests to our team:
- Why did this request happen in the first place?
- Can we improve something (documentation, processes, …) to help teams to help themselves?
- Can we educate teams so that they need to depend less on us? (After all, you do not want people to depend on platform teams, as dependencies eventually would slow them down)
Being conscious about requests and distractions not just helped us to react to them timely, but als reduced the number of those eventually.
4. Inbox Channel
Not everything is urgent. Therefore, we introduced an inbox channel where people could drop their ideas, feedback, and requests at any time.
The policy for this channel was: We will check it and react to messages at least once a week on Monday morning. Thus, people had the choice to not distract us while still sharing things on their minds.
In reality, we checked this channel much more often. The important thing was: We checked it on our terms and did not feel pressured to answer immediately.
Furthermore, we made checking this channel and making sure every message is handled appropriately a task for the people on support rotation. Therefore, other members of the team were free to ignore the channel.
5. Default-to-Open
At BRYTER, we had a Default-to-Open policy, meaning: Everything that can be discussed in public, should be discussed in public. Thus, when people would ask about technology, tools, or processes in direct messages, we would kindly direct them to a suitable public channel (public inside the company) to ask their questions.
This came with the benefit that they got answers faster, that other people could learn from the answers or be pulled in when they had additional information. It also reduced the amount of direct messages, everybody on the team got.
6. Focus Weeks
We sometimes did focus weeks on really difficult topics. Those weeks were essentially a series of deep work blocks. In those weeks, we were able to achieve really cool things that we would have not achieved in months, otherwise.
Read my article about focus weeks for all the details and the aspects that made focus weeks a success.
Summary
Getting enough time for deep work and focus can be especially challenging in platform- and enabling-teams. Your customers are near all the time. This is great for getting quick feedback and figuring out the right solutions with them, but it can be a challenge for getting enough focus.
The developer experience team at BRYTER managed to find a good balance using the following six mechanisms:
- Week Kickoff
- Scheduled Collaboration Times
- Support Rotation and Support Slack Handle
- Inbox Channel
- Default-to-Open
- Focus Weeks
I will elaborate on some of these topics more in detail in my next articles.
Was this article interesting to you? Share it with your co-workers or your network to inspire others.
