My software development team is on the larger side, with about 12 developers split between multiple locations. Most of the discussion about pain points with the services we’ve been building used to happen informally, while sitting together and venting about frustrating parts of our system. As a result, there was often agreement between two or three people about what tech debt needed to be addressed, but never alignment between the entire team.
Because of this, we would only ever address small, contained tech debt and felt that we could never address larger-scale refactors, since we didn’t have the buy-in of the entire team. This was what initially motivated us to start holding dev syncs.
Dev Sync Agenda
From there, we decided to schedule a weekly dev sync, inviting every developer on our team as an optional attendee. The goal was a low pressure and casual meeting; if there was something more pressing to attend to, there’s no any obligation to always attend each meeting.
For our first dev sync, I invited folks to compile a list of tech debt and known issues. Then, as a group, we split up the work to create tickets for smaller issues, and developers volunteered to create proposals for how to tackle more complicated efforts. We also planned to make a commitment to start allocating a certain percent of our sprint capacity to addressing these new tech debt focused tickets.
With time, the meetings evolved into a slightly different structure. Now, new topics are added to an ongoing list at any time and we vote on the highest priority discussion items at the beginning of each meeting. With this new format, the meetings started providing even more benefits to the team.
Continuous Technical Knowledge Sharing
Our dev syncs have also turned into a space for ongoing technical knowledge sharing. People began introducing agenda items requesting (or volunteering) short overviews of specific systems or tools. These have ranged from walkthroughs of how certain third-party integrations work, to introductions of newly adopted infrastructure. These developer-driven sessions have helped reduce knowledge silos and made more developers feel confident working across different parts of the system.
A Bridge to the Broader Engineering Team
Our dev sync have also served as a bridge between our team and the broader engineering organization. There are many meetings where only a few representatives from each team attend — cross-team web syncs, backend discussions, and so on. Much of the content of those meetings wasn’t immediately relevant to our team, and that which was didn’t always make it back to every developer on our team
We now use our dev sync as a place to relay relevant takeaways from those larger meetings. Team members who attended will often use our dev sync as a way to summarize what was discussed, highlight decisions that affect our work, and call out upcoming changes we should be aware of. Just as importantly, we use the time to talk through how those decisions fit (or don’t fit) with our team’s needs and constraints.
Escalation of Issues + Support from Our Team Leaders
The dev sync has also become a good forum for escalating recurring issues to our team’s tech leads and engineering managers. It’s yet another place where they can learn about what’s slowing the team down, so they can prioritize addressing these issues or reaching out to other teams for support when needed.