The Dialogue way

When I joined Dialogue a little over 2 years ago, aside from the wonderful people I met through the process, I was also deeply impressed with the maturity of the development processes I found. Our core value is ensuring a five-star member experience, and we live it every day. From how we organize our clinical teams to how we organize our tech teams. From its inception, the tech team at Dialogue has adhered to the highest standards of security, scalability, and operational efficiency.

Here’s how we do it.

The backbone of our process is the relationship among product managers, designers, and tech leads. Product managers own the “why”; they work with stakeholders, synthesize user feedback, and make the hard calls about what we build next. Designers drive the experience of “how it works”; they make those decisions and ensure what we ship is something a nurse or a patient can actually use. And lastly, tech owns the “how” and ensures things can be built within the time we say they can. All this amounts to the classic tripod organization of tech and product teams.

What makes this work is proximity. Product and design are in the same rooms in our offices in Montreal or Toronto, on the same teams, and accountable for the same outcomes.

We believe in offering the highest standard of care to our members, our patients. Part of how we achieve that is ensuring our care team is part of the Dialogue family, not the gig economy. This has immense benefit in placing the tech and product team in direct contact with both our patients and the care team, so we can work with them to deliver the best experience they need to provide care.

Our software development teams are roughly organized along the lines of where we prioritize our business. We have a stream that focuses on our client needs, a stream that focuses on the needs of our clinical team and a stream that focuses on the member experience. To support them, we have a platform stream that focuses on foundational technologies.

All the streams are uniquely responsible to own and maintaining the software they build. We don’t handoff things between teams, we believe in the builder-owner model. Streams have to collaborate - adding an experience for a client means improving the member experience in the mobile apps. To help accomplish this, our streams are full stack, and empowered to work across the technology stack.

Every engineering team has technical debt. We’ve made a choice to be deliberate about how we manage it. Like all companies with deadlines, we sometimes have to take shortcuts in how we build features: this is a natural part of being a fast-moving startup.

Our approach to managing this is having reserved capacity in every sprint for what we call sustaining engineering. The ratio varies with the state of the codebase, but it never drops to zero. Short-term pressure to ship features is real, and if you don’t explicitly defend that time, it disappears.

We’ve invested heavily in CI/CD practices that surface problems early, and we’re organized around DevOps principles, where each team and stream owns the microservices they build and operate.

As an example of how we think about tech debt, we recognize that not all care journeys are perfect, and as a result, we’ve deliberately set up a dedicated team of developers to build the best next-generation interactive video platform we can think of for our members. This is a real investment in our platform, all driven by our obsession with member experience.

We use Scrum for most of our feature work. We have two-week sprints organized around the canonical scrum ceremonies: retrospectives, planning, refinement demo and dailies. Some teams use Kanban for work that doesn’t fit neatly into sprints.

We organize our roadmaps using EOS, a standard process for aligning organizations that works well at our size. These roadmaps are reviewed quarterly, and we do our best to find the highest-priority items to work on. Then our tripods are responsible for aligning this into their backlog from which the teams can draw for the sprints within the quarter.

As an example, this past quarter we had a large client deliverable, but also an important investment in our member experience. We had to hash out which teams would support the initiative. The end result was that even though each stream has their own swimlanes as outlined above, we come together to support the highest priority across streams and collaborate towards a common goal.

Building software in healthcare has unique challenges, like most other domains — not because the technology is more complex, but because our clients, both our internal clinical teams and the patients they follow, have distinct demands. As a result, we’ve organized ourselves around leading software development best practices to help us focus on and deliver the kind of member experience we want.