Skip to content

landing_img

Introduction

Be humble, help others, be kind.

Special Olympics’ mission is to create an inclusive and equitable world. Our job is to support that mission by leveraging technology, data, and science to accelerate our positive impact on the lives of people with intellectual disabilities. We envision a future in which the movement is supercharged by technology, able to answer profound questions, and reaches all individuals with IDD not just through sport but across multiple aspects of life.

We are the Technology & Data division within the broader Digital Products & Technology department. Our portfolio is spread across three pillars: Data Science & Analytics, Digital Health, and Engineer/DevOps. Our core function within the organization is to build best-in-class technologies to support Programs and Business Units with an unwavering focus on the full data lifecycle from origination to value generation.

How we work

Culture

Our division’s culture is grounded in flexibility, patience, collaboration, transparency, and empathy. We work like a startup and leverage best practices across Design Thinking, Lean Startup, and Agile. Digitizing an organization requires modernizing a team’s practices and we aim to continually improve not only our product and output but also the way we work.

Core Practices

It is important that we acknowledge that work is only one part of life. It is equally critical to ensure that our day-to-day work life is healthy, respectful, and empowering. To that end, we adopt the following core practices: 

  • Do not work more than 40 hours a week on average
  • There is no expectation to respond outside your work hours
  • Be mindful of different lifestyles and schedules when asking for people’s time
  • Prioritize transparent communication and a free flow of information
  • Empower your teammates to say “no”
  • Document everything
  • Automate as much as possible
  • Take a goal-first approach

Collaborative Development

...or “If it is not in GitHub, it does not exist!”

While you may spend a significant amount of time and energy building a model or system from scratch, the ownership of the code base is our team’s collective ownership, not the individual developer. You may act today as both the engineer of a system as well as its maintainer, addressing bugs and data issues reported by downstream consumers, but remember that all of us are likely to work on something else eventually and someone else will step into the shoes of the maintainer for the system you have built.

All our work should be under source control in GitHub; “if it isn’t in GitHub, it doesn’t exist!” Contributing to a repository should follow the standard open-source contribution process:

  1. Develop on a branch from master
  2. Pull request those changes to master
  3. Have code reviewed and request approved
  4. Merge pull request and delete the branch

It is all of our responsibility to review each other’s code. All code we produce should be properly documented and written according to best practices.

See below for our GitHub organization:

specialolympics

See below for the repo for this documentation site specifically:

soi-docs

Meetings

Poor meeting hygiene is destructive to productivity and a common cause of burnout. We believe in being purposeful about meetings and limiting them to only what is necessary, leaning on asynchronous communication to get things done. We are encouraged to ask ourselves if our presence is really needed at a meeting, and we should be proactive in debriefing with teammates later if critical information arises in their absence. To curtail meeting bloat, we limit ourselves to four regular meetings a week, on average, described below.

Regular meetings

  • Every Tuesday and Thursday we hold a standup meeting
  • Every week we have a 1-1 with our manager
  • Every month we have sprint planning
  • Every month we have a department-wide status meeting

In addition to these, we expect to be in a small handful of vendor- and stakeholder-facing meetings each week, as well as ad hoc working sessions as needed. Every quarter we meet to review, reflect, and plan for the next quarter.

Finally, everyone is encouraged to take “light Fridays” and limit meetings on that day when possible.

Feedback

Awareness as to what needs to be fixed is the first step towards fixing it. Feedback is how we generate awareness. Feedback can relate to any aspect of the project - people management, business priorities, and code quality, to name a few.
Each of us is taking part in different aspects of the team, and therefore are exposed to and can identify different issues.

We are encouraged to share feedback routinely. At times, we will proactively set up feedback sessions when needed.

If given the wrong way, feedback can lead to undesired negative feelings, becoming counterproductive. Here are some basic principles to keep in mind:

  • Feedback should not be seen as criticism of the individual but as a means for learning, improving, and growing
  • Making a mistake or an incorrect assumption is acceptable and even expected in an experimental startup culture
  • Feedback is the way to communicate about these mistakes, learn from them, and fix them

To encourage a strong feedback culture, we adopt the following best practices:

  • Effective and concrete - feedback should include examples and be specific
  • Timely - feedback should be given when it is still relevant and fresh
  • At the right frequency - feedback should be given in the right setting to not be disruptive and not too frequent
  • All directional - feedback should flow from all directions, from leadership to individual contributors and vice versa and from colleague to colleague
  • Objective - feedback should be based on facts

Receiving and providing feedback well is also an incredible teaching tool. New team members may bring skills that are not already part of the team, or further add strength to the overall team in a manner that was not necessarily expected - that is, feedback from all team members in a constructive manner is encouraged.

Work Planning and Practice

We are a hybrid agile team that runs on two-week sprints with a sprint retro + planning every other week and twice-weekly 15-minute stand-ups. We leverage Jira as our planning and tracking tool, and we are all expected to actively use Jira and maintain good card hygiene. This is not meant to be added overhead but rather supports our core goals of transparency and automation.

We try to follow the following best practices for work management in Jira:

  • Keep your cards up to date throughout the sprint
  • Add new inbound work to the backlog at the time it is surfaced
  • Keep the backlog groomed
  • Document work with clear, concise, and meaningful cards of appropriate size
  • Continually monitor the progress of Epics
  • Surface and create risk cards at time of project initiation and maintain accurate risk levels throughout a project’s lifecycle

See below for our Jira board:

so-tech-data-science

The Team

Data

  • Jackie Palmer
  • John Hanley
  • Karly Jerman
  • McGregor Ambler

Digital Health

  • Michelle Duong
  • Abir Salah

Technology and Engineering

  • Jeffrey Sanita
  • Koffe Togbe
  • Gabrielle Del Bianco