Tag Archives: engineering

Engineering Values, part 2: Mindful Collaboration

Previously on the blog…

This is the second in a series of blog posts exploring the values held by our Engineering department, and how we put them into practice. As a refresher, our Engineering department’s values, in no particular order, are:

  • Sustainability
  • Mindful Collaboration
  • Data-Driven Approach
  • Shipping Software
  • Diversity & Inclusion
  • Learning & Innovation

In the previous post, I went into detail about the value of sustainability. Today I talk about mindful collaboration.

Value: Mindful Collaboration

At first glance, mindful collaboration may seem like a squishy subject that has little to do with software development. But in reality, the opposite is true: we are humans working together to build something we care about. Collaboration is a key feature of a successful company. (Company, after all, literally means multiple people gathered together.) So when we talk about mindful collaboration, we’re talking about building a culture and environment that is optimized for humans working together.

Specifically, this is what mindful collaboration means for Engineering at Omada Health:

  • Leading with empathy
  • Minimization of ego
  • Proactively asking for feedback
  • Having clear expectations

Putting it into practice

Probably the most important characteristic in mindful collaboration is empathy. No matter what we do, we must always consider the needs of other people: our teammates, our stakeholders, our target audience. When my team makes decisions, we must consider the impact of those decisions on other teams. Will there be any side effects? What assumptions and expectations are there about what our team works on? What don’t we know, that other teams might, about something we’re about to do?

We must understand that there will always be tension between requirements, available resources, and time. This often manifests as tension between developers and stakeholders. I believe this tension is healthy: it pushes us outside our comfort zones, which is how we grow as human beings, and it makes us question our assumptions, which helps us better understand each other.

To be an effective collaborator requires awareness of one’s ego, and the ability to set it aside. Doing so enables us to receive constructive feedback without taking it as a personal attack, and to participate in blameless postmortems. It allows us the freedom to acknowledge how we showed up to a meeting or a pairing session: maybe I wasn’t entirely present because I have a lot on my mind, or maybe I was more defensive in a conversation than I intended to be.

In addition to receiving constructive feedback, mindful collaboration includes proactively soliciting feedback, and graciously receiving it. This can happen anywhere: in team retrospective meetings, one-on-one conversations, formal feedback tools, or even in ad hoc hallway conversations. It can be as simple as asking, “Is there something I could have done a little better?” We find our retrospective meetings to be a good forum for this kind of feedback, especially when it comes to finding ways to improve our processes.

Empathy and a proactive feedback culture—one in which feedback is offered in a continuous cycle, in varying forms—allow us to engage in spirited debate, particularly when arguments are backed by data (more on this in a later post!).

When we work together as a team, and especially when multiple teams work together, it is key to set clear expectations of everyone involved. What are we trying to accomplish? By when? We ensure clear communication of expectations by clearly documenting requirements and acceptance criteria as early as possible—and regularly coming back to this documentation as we work on features, to check in on how we’re doing relative to the expectations we set at the start.

This often applies to meetings, as well. When I am running a meeting, I like to build an agenda before it starts. This helps me identify what I hope to get out of it, and will help keep it from going off the rails. (Everyone’s time is valuable.) During the meeting, I ask questions—and encourage others to ask questions—when things are unclear. At the end, if applicable, I run through the conclusions reached during the meeting, so that everyone is on the same page. This also helps ensure that I heard everyone correctly.

What have we learned? How have we benefited?

Doing this effectively, on an ongoing basis, is hard! Mindful collaboration requires mutual trust and a willingness to be vulnerable, on the part of everyone involved. It can feel awkward. It takes practice and reflection, performed in cycles, to get it right.

When we get it right, though, it is awesome. It leads to better function across teams. It helps teams identify potential problems early. Maybe that means a change in direction, or maybe it just means the affected teams have more time to prepare. Either way, everyone has benefited! Moreover, proactively looking for potential effects on other teams builds their trust in my team.

Mindful collaboration requires effective communication, and that needs to take multiple forms, and usually involves some amount of repetition. We’ll often see the same message communicated through both Slack and email, because not everyone uses both. Then there are the tools we use for things like project management, issue tracking, documentation, and so on. Even sticky notes can be effective. And there’s rarely a substitute for face-to-face communication.

The biggest benefit by far is the way it produces an inclusive work environment. When people feel valued, they’re happier. And when people are happier, they’re willing to invest more of themselves in their work. That feeling comes through in the office culture, which makes people want to stick around. And who wouldn’t prefer to work in an environment where their colleagues actively want to be there?


Mindfulness is difficult, and collaboration can be difficult, so it stands to reason that mindful collaboration poses a challenge. It’s complicated, it’s messy, and it takes practice. A lot of practice. But the benefits are so worth the effort: improved cross-team communication and function; a greater feeling of ownership and investment; happier teams; and a more inclusive environment. A team that works well together is a team that will last.

Engineering Values, part 1: Sustainability

At Omada Health, we have a set of values that guide everything we do as a company. This post, however, is not about our company values, but the values held by our Engineering department. These are the principles that drive the work we do as software developers, data scientists, and infrastructure architects. These values are the product of brainstorming by the management team, and were given shape by input and healthy debate across the entire department. (As with any exercise in identifying guiding principles, there was very little that was clear and obvious from the get-go.)

Our Engineering Department’s values, in no particular order, are:

  • Sustainability
  • Data-Driven Approach
  • Mindful Collaboration
  • Shipping Software
  • Diversity & Inclusion
  • Learning & Innovation

Today’s post concerns the first of those, and future posts will go into detail on the others.

Value: Sustainability

When we talk about sustainability, we aren’t referring to ecology or economics, so I’m not going to talk about renewable energy or fair-trade crops. For us, sustainability means pacing ourselves, thinking about the future without losing sight of present needs, and remembering that professional software development is a marathon, not a sprint.

As it applies to Engineering at Omada Health, sustainability means, among other things:

  • Preventing turnover
  • Avoiding knowledge silos
  • Shipping quality, well-tested code
  • Having a strong relationship with our Product teams

Putting it into practice

We’ve put this value into practice in a number of ways, whether it’s promoting a healthy work-life balance, practicing pair programming (it’s our default mode of operation), or taking the time to refactor old code. We practice test-driven and behavior-driven development (TDD and BDD), which we combine with comprehensive monitoring of key performance indicators (KPIs) and system health, to help surface anomalies and outages as quickly as possible.

In service of sustainability, we practice some tenets of Agile software development. The principles that are most important to us:

  • Starting simple and improving iteratively
  • Continuous delivery of working software
  • Being responsive to changing requirements and circumstances, especially when they are beyond our control
  • Allowing our teams to organize and run themselves
  • Face-to-face communication
  • Close alignment between the Product and Engineering teams
  • Regular retrospective meetings to reflect on, and make adjustments to, team processes

How does practicing sustainability help us?

First and foremost: teams made up of happy people are more productive. (Who knew?!) Through promoting a healthy work-life balance, reasonable working hours, a culture of inclusion (more on that in a future post), and building and nurturing cohesive teams, our people enjoy coming to work, and they are motivated to make Omada Health a leader in helping people live free of chronic disease.

On the more technical side, we know from experience that keeping things simple is challenging. How do we decide what needs to be included in an MVP, and what can be added in a later iteration? How do we identify what we need to do now, what we’ll definitely need in the future, and what we might need later on? Answering these questions requires a firm understanding of the problems we’re trying to solve, and putting those answers into practice requires buy-in from stakeholders. (Then there’s the question of identifying your stakeholders!)

Of course, we want the software we build to last. TDD, BDD, and pair programming are effective ways of preventing knowledge silos, documenting expected behavior, and getting input from multiple people. What’s more, we encourage everyone to include refactors of old code if it gets touched through the course of writing new code. And taking the time to do refactors now will make twelve-months-from-now you very happy.

Lastly, doing all these things is impossible if the relationship between the Product and Engineering teams is broken or lacking in trust. We encourage a healthy relationship between Product and Engineering by ensuring that they are constantly working closely together, and always able to communicate. Whether that’s in daily stand-ups, planning sessions, retrospectives, or ad-hoc conversations, the key is open, honest, and clear communication.


At the end of the day, we like feeling proud of the work we do. We want our work to have a profound and lasting impact on the lives of our participants. The surest way to ensure that our work will endure is to practice sustainability across the board, every day.

Reference: 12 Principles Behind the Agile Manifesto