Here you will find ideas and code straight from the Software Development Team at SportsEngine. Our focus is on building great software products for the world of youth and amateur sports. We are fortunate to be able to combine our love of sports with our passion for writing code.
The SportsEngine application originated in 2006 as a single Ruby on Rails 1.2 application. Today the SportsEngine Platform is composed of more than 20 applications built on Rails and Node.js, forming a service oriented architecture that is poised to scale for the future.
Culture is a Team Sport is our sub-series on Coding in the Crease to talk about culture, processes and policy at SportsEngine. We’ll focus on what we are doing to create a generative culture where our employees are able to learn and grow. In this article, we share how team health checks have helped us deal with the human side of teamwork and high-level issues.
In a heavily technical environment with high stress and many people, the squishy side of teamwork (an Andy Fleener-ism for feelings, emotions, being human) can often be forgotten. Questions can often go unasked, like, “Do you feel supported by the rest of the organization?”, or “Do you feel that you are delivering value to your stakeholders?”, or “Are you excited about coming to work?”. These questions are tied to things we silently observe every day without expressing due to the very task-oriented nature of software development. A team that is not engaged demonstrates this through lack of ownership, creativity, or grit - very necessary things for sustainable software development. The idea behind team health checks (entirely borrowed from Spotify’s Squad Health Checks) is to give voice to the team around higher-level matters and encourage them to think critically about process and culture and then take action.
We have found them to be an important part of building a learning culture here at SportsEngine, but not for the reasons that you might think.
Several years ago, prior to SIPlay being acquired by SportsEngine, I had been observing that our teams had very siloed outlooks - if you were to speak to one team about how their process was going, you would be certain to have part of the team answer one way, and the rest of the team have individual ideas. The engineering leaders were talking about how we could have a better experience as remote workers (at the time, almost all of the engineers/qa/ops people were scattered all over the Americas). While I was trying to figure out what something like ‘team scorecards’ could look like, I stumbled upon the Spotify squad health check blog post, and the concept rang true as something we definitely needed to try! We ran our first health checks and the team leads genuinely thought the time was well spent and offered something we hadn’t been providing before - a forum for folks to express their concerns, to consider the bigger picture as a group, and to draw some conclusions from this to improve their team environment going forward. From that point onward we ran them twice a year, with there even being occasional questions as to ‘so when are we running the next one?’.
Intuition might tell you that doing this lends visibility into how people are thinking, and therefore leadership can act accordingly. You may think that great and wonderful action items are drawn from these meetings that change everything. However, what we have found to be the most successful piece of them is simply giving the teams room to breathe, to talk with each other, and to ask questions. We have seen more positive feedback around comments like “It was great to sit together as a team and talk about these things” than from any individual action item generated by the health checks. These meetings provide a trip to the top of the mountain, so to speak, for a view of the bigger picture. The real value lies in getting the team to talk amongst themselves, raising issues that generally sit beneath the surface but cause pain none-the-less.
These conversations do end up generating action items that do help, but what you really gain are teams that start thinking and conversing about these topics more often — the value of team discussion is made visible. Teams also have to face a measure of psychological accountability to the facilitator’s prompt of “how did the action items go last time?” The question can be asked, ‘What prevents you from acting on these things that clearly need some action?’
We run the health checks a few times a year, usually within the same week for an arbitrary measure of consistency and ease of facilitation. The entire team is present — tech lead, product folk, UX, QA, devs — including remote people, and we encourage that any local folk don’t work from home that day. The topics and ground rules are circulated a week or two in advance, with everyone being encouraged to look at the topics and think about them, to write down questions ahead of time. The meetings themselves are a three-hour slot where we see a need for two hours, but leave space for conversation. At the end of each topic’s discussion time, the group is polled (in future we’ll do silent voting, although this has drawbacks as well) and the simple red/yellow/green vote tallied. At the end of the session the “worst” topics help focus discussion on future action.
A core part of the health check is facilitation of the meeting. It’s tough in general to keep meetings on track, and especially so when people are venting their heart’s frustrations, and yet there needs to be some semblance of structure to the meeting because while the conversation is the primary goal, actually taking something out of it is still important. I’ve found the role of facilitator to be rewarding, but also draining, and consider there to be three core jobs to balance.
First, someone needs to break the ice, stimulate conversations, and lines of thinking. During the first topic especially, people are still uncertain about where the conversation is going to go, or their minds are still churning over their previous task or meeting. I try to focus the group by suggesting scope of the topic — what it comprises and what it does not. I bring up context-specific issues — ‘remember when you folks brought up this particular issue last time, how have your thoughts changed?’, or ‘now that we are heading in this direction, how does that impact your perceptions of this topic?’
Second, I try to focus my starter questions on the leaders of the group as a way of hinting “help me get the ball rolling here”. As the conversation progresses, you quickly find out who the chatty and not-so-chatty people are, and you learn how to curb the talkative, and encourage the shy - without being offensive or domineering. As another facet of this, some topics might hit a hot button with the group, and so sticking to ‘X minutes per topic’ could potentially remove time needed for the group’s thoughts to run their course. When to give/take time off a topic something entirely based on judgement at the time, I have found it to be a learned skill. It can certainly be challenging to balance covering all the topics against seeing a particular hotspot for a team that needs time to unravel.
Finally, given there are always friction barriers to overcome, and people can get locked into their normal ways of viewing things, new ideas or hard-to-discuss ideas need to be dropped in like verbal grenades. Questions like ‘So you have expressed a high level of product ownership. Could you tell me about the delay between a production deploy and the team knowing the app is still up, and the code is working as expected?’. This kind of thing is very contextual, but the idea is to take their ideas and demonstrate the next level they could move to - maybe it’s not something worth considering, but the team’s conversation will let them decide that. The caveat to this is, of course, to not let your personal agenda control the lines of questioning, which can be rather challenging to suppress.
During the process I’m also taking notes, writing down action item ideas, and tallying the voting. At the end of our time together, the last step is to discuss findings and create action items with specific owners. I try to encourage them to continue certain conversations throughout the next quarter, and to act on issues they feel strongly about.
I use my notes and the voting tallies to provide an anonymized summary of the major themes across all product teams to the VP of Product/Engineering. We’ve found value in these summaries being used as a semi-official confirmation of thematic problems - for example, teams were concerned almost universally about analytics capabilities, and shortly after the findings were presented leadership started actively looking to fill a dedicated analytics role (where before they would have been looking for another dev role). The teams are made aware of these notes and the intent - but this is a safe space, and the ground rules for all participants and leaders are made clear ahead of time.
-The health checks are quarterly high-level retrospectives that generate subjective data and thus CANNOT be used for team comparison or finger pointing, and CANNOT be used as compensation levers -They MUST generate conversation as a primary core function -They MUST build team growth/self-awareness as a primary core function -Action items that are accomplished are a secondary core function -If any of the primary core functions fail, the secondary will as well -If the secondary function is not happening, the effectiveness of the exercise is diminished -The only role for management here is identifying focus areas and systemic issues, aided by the visualization of the subjective data
When talking about outcomes, it’s important not to correlate action items generated with the effectiveness of the team. Action items like follow-up items, future meeting topics, or continued conversation are one indicator of the effectiveness of the conversations because they are a downstream effect of having had, and continuing to have, effective team conversations around process and culture. It’s also important to call out that the analysis brought to senior leadership should be seen as a ‘finger in the air’ to help with redesigning organizational systems. For example, if they see that everyone is angry about health of code, it’s clear that not enough debt items are being prioritized.
After conducting these health checks both during my time at Sports Illustrated Play, and here at SportsEngine, we have seen more focus put on team autonomy, ownership of code repos, team-building activities and efforts (including more comfort with retrospective activities), and that teams with good attitudes, rather than tech skill sets, make a huge difference in results. While it’s unnecessary to try and draw lines between results and this activity (due to the challenges of tying statistically fuzzy actions to concrete results), the anecdotal and survey feedback indicate this process has cemented itself as a pillar of our learning culture.