What's a "Sync" meeting anyway?
When I say "Let's Sync" this is what I mean
In my role as a engineering manager, I’ve adopted a unique approach to team communication. Instead of traditional standup meetings, where developers gather on a call to discuss their progress and plans, I’ve implemented a different strategy. I believe that traditional standups often serve the manager more than the makers, which led me to rethink this process.
I’ve introduced a concept I call “sync” meetings. These occur at the start and end of each week, providing a platform for each developer to connect with me individually. The term “sync” might seem ambiguous, and that’s why I’m writing this post - to shed light on its meaning and purpose in our workflow.
To prepare for these sync meetings, I create a weekly journal that includes a checklist of priorities. This not only helps me stay organized but also ensures that our team is aligned and focused on our common goals.
Through this post, I aim to demystify the concept of “sync” meetings and share how this approach has enhanced our team’s productivity and communication. Stay tuned as we delve deeper into the mechanics and benefits of this innovative practice.
We have similar stories
As a manager, I need to sync with my developer, so that we have alignment with the immediate and ultimate goals of the product we are making.
As a developer, I need to sync with my manager, so that I’m well supported to succeed in my construction efforts, and to make sure I’m building the good parts.
In my capacity as a manager, it’s crucial for me to maintain regular communication with my developers. This ensures that we are in sync and aligned with both the immediate tasks at hand and the overarching goals of the product we are creating.
From a developer’s perspective, these sync sessions with the manager are vital. They provide the necessary support for successful execution of tasks and ensure that the focus remains on building the most valuable features of the product.
As an engineering manager, my role extends beyond just managing developers. I engage in regular discussions with other managers about the products we are developing. These discussions encompass a range of topics, from shifting priorities and content delivery schedules to release timelines.
Working in an eLearning company, our focus isn’t solely on software development. Our product is a comprehensive package that includes various elements such as video production, instructional design, and customer studies. As these elements take shape, they can influence our engineering priorities.
In this dynamic environment, we are akin to the tail following the dog. We need to be adaptable and open to change. Priorities can shift from one week to the next, and that’s perfectly fine. It’s all part of ensuring that we deliver the best possible product.
The Sync Checklist
I’m a huge fan of checklist. Read the Checklist Manifesto if you have not. It’s required reading on my teams. Here’s what I think a sync meeting should look like:
Journal Creation: The manager creates a journal ticket for the week, summarizing the effort and outlining a checklist of goals.
Journal Review: The developer reviews the journal ticket for the week, focusing on any new information or changes in priorities.
Meeting Setup: Schedule a meeting that lasts between 10 to 20 minutes.
Co-Authoring the Journal: During the meeting, co-author the journal ticket in real-time to ensure the checklist is accurate and complete. Ask yourselves: Are the right things on the list? What’s missing?
Detailed Discussion: If a checklist item is a larger topic (like a feature), discuss the details to ensure everyone has the same understanding of the requirements. Refer to the Feature Checklist for guidance.
Planning Additional Meetings: Plan any necessary additional meetings with other team members and document these in the journal.
Noting Important Dates: Make a note of any days off or other significant dates for the week.
Remember, the key to a successful sync meeting is clear communication and mutual understanding.
The Feature Checklist
If you are starting a new feature, then check off the following:
Requirements Review: In the presence of your manager, review all the requirement assets listed in the feature’s topic/ticket to ensure you have everything you need.
Agile Stories Discussion: Discuss the feature using Agile Stories to fill in any gaps in the overall feature requirements.
Specflow Feature File: Locate or create the specflow (reqnroll) feature file in the project repository, if necessary.
Specs Codification: Review and add scenarios and behaviors to the Specs to cover all the requirements as you understand them.
Plan Formulation: Develop a plan and discuss it with your manager and peers to determine the best approach that leverages existing platforms and prior work.
Plan Publication: Publish the plan as a specflow (reqnroll) feature file in the project repository.
Scenario Checklist: Create a checklist of scenarios on the ticket/topic for the feature.
Work Assignment: Assign the work to yourself and start your feature branch.
Work Announcement: Announce in the project channel that you are undertaking this work.
The Why
The shift from traditional standup meetings to individual “sync” meetings has proven to be a game-changer in our team’s communication and productivity. This approach, coupled with the use of checklists and BDD, has fostered a more supportive and efficient environment for both managers and developers.
The dynamic nature of our work in an eLearning company necessitates flexibility and adaptability. Our focus isn’t solely on software development, but on delivering a comprehensive product that includes various elements such as video production, instructional design, and customer studies. As these elements evolve, they can influence our engineering priorities, and we’ve learned to embrace this change.
The key to successful sync meetings and feature development lies in clear communication, mutual understanding, and thorough planning. By adopting these practices, we’ve been able to align our immediate tasks with the overarching goals of the product we are creating.
* Codify the Specs is the name of another post on this blog. Read it for more details.