Making Changes that Matter

Shifting to an integration mindset

If you have been following along on the Schutzworks approach to Resolving the Clinicoproduct Divide part 1 & part 2 then hopefully you’ve started integrating clinicians into your development teams. As you work through this process, which will take many iterations (need help?) you will begin to notice an uptick in your development output. Your frontline users and patients may even take notice and briefly praise you. But then something very confusing will happen, as the very people who were pushing you to speed up, now start begging you to slow down. “No more changes, we can’t handle this. Who asked for this change? We are going to hold off for now, etc.” Wait, what?

Let’s for a moment highlight a key difference between consumer and enterprise focused development. The beauty of building for consumers is that they are free to join and leave, hence all the Silicon Valley “move fast, break stuff” garbage. You can and must make decisions to solve problems for some customers at the expense of all possible customers, in whatever method meets your objectives. Put concretely: Shame on you for getting sushi at a gas station, that’s not what they do. This starts to break down when you get into building for your own employees, who are not “free to leave” with the same frivolity as deleting an app. You have to design for multiple user types because brutal segmentation can hobble your workforce or undermine your mission. Healthcare gets even trickier as you are usually designing for patient users AND your employees at the same time. Segmenting by technology capability may ultimately mean abandoning patients you’re intending to help, while switching jobs is non-trivial for your employees.

To add to the challenge, when it comes to employees and patients, you actually have an opinion on what they do. So you can’t just study what they are doing and fix it, or can you? Let’s hold off on this question for another time, but the brief answer is: 1) Use your goal setting and management functions (including direct observation) for your normative behavior or “what SHOULD be happening.” 2) Use your development function to make whatever SHOULD be happening, easier. If you’ve been attempting to force behavior changes via technology, you are probably seeing changes go quietly ignored, if not all out revolt. This very rational employee behavior is doubly destabilizing, first because ignored changes cause your already divergent service environments to diverge further. Second, every change into these divergent environments further erodes trust and faith in leadership, which leads to further rejection, and so on.

Shifting Constraints

So let’s dive into exactly what’s happening here, which is that the constraint in your ability to develop new “things” has shifted from production, problems inside your development team, to consumption by your front line that have to incorporate changes to their daily work on what feels like a hasty, random basis. This change can sneak up on you suddenly, because you were so used to development being the constraint that it never occurred to you that it would no longer be the problem. This scarcity mindset will blind you to this constraint shift, which is the successful result of your improvement efforts, like putting clinicians on the team. It turns out that the reward for success is a host of new, much harder problems, while the penalty for failure is living persistent, worsening problems until you get taken out. Hurray!

Your response, after the bewilderment and rage at the resistance subsides, is to shift your prioritization to the new constraint (because all improvements not at the constraint are an illusion), which is variously called roll out, change management, or my preferred term, integration. Put simply, you have to match the output of your development teams with the uptake rate of your front line teams (the new constraint). Because development was so slow before, you likely never considered the rate of absorption of your teams. Furthermore, if you run a multi-site (or virtual) clinical service, the daily operations of each site are likely different from each other, so the ability to absorb a given change at a given site will change wildly, suggesting that your rate of uptake is pretty close to zero across the organization. Ugh. What to do?

The Integration Mindset

Cue the integration mindset: Where a change can only be considered successful when it achieves the expected measure of success. Integration differs from release in that the developers take responsibility for the feature actually achieving its goal, not merely being available for use. Neither is integration entirely the same as roll out, change management, or training, which focus on important activities instead of the intended outcome. Rather, these activities i.e.release, roll out, training, change management, measurement are all part of the successful integration of a change into a new whole. We are going to introduce a ton of new concepts in this article, and I’m happy to go deeper on any of them if you’d like, so please request in the comments!

The first important aspect of integration is ensuring that the goal of your development process is to make operations more systematic and similar over time. This starts with a mindset shift in what it means to “make a change” to your operating system toward measuring success. When I work with most development teams, they celebrate the release of a feature or protocol change as their “mission accomplished” moment. This mindset is contributing to your chaos. Instead, you’ve got to level up your developmental discipline by changing your definition of done. For every change you intend to make, whether it be software, equipment, or process, you must add the requirement for a measure of success. This should stem from the initial user story, “As a physician I want to be able to quickly find my previous notes so that I can accurately and efficiently care for patients.” In this example, the measure of success could be “time spent hunting for notes” or “clicks down the infinite scroll” or “searches executed.” Whatever the metric, every change requires a measure of success.

A measure of success helpfully forces a few positive behaviors. First, it clarifies the purpose of a given change to all involved by specifying the expected change. You’d be surprised how often the same button is expected to do wildly divergent things. Second, progress in a measure of success demonstrates a causal relationship between the feature and the desired outcome. If the measure doesn’t move, the feature is at best a component of the solution, or possibly a bust. The third and most valuable aspect of a measure of success is that it forces development teams to focus past a feature’s release. No more throwing a feature over the wall and assuming all is well. How many times have you experienced a minimum viable product (MVP) “to improve later” and never touched the feature again? Minimum viable becomes maximum allowable really fast when there is no follow up. And as an added bonus, by focusing on the measure of success, you can begin to create a roadmap of desired results rather than desired features, which is always superior, because nothing works the way we think it does anyway.

By deploying measures of success in your development process, you will also be able to make operations at your site more systematically similar to each other (avoiding “standardized” on purpose), because you can measure variation and deal with it appropriately. As your operations become more similar, it becomes easier to integrate changes into your system, which in turn bring your operations together, reversing the vicious cycle of quiet rejection you have been manufacturing to date. To access this cycle, once you’ve deployed measures of success, you have to do two things really well: make change work visible and deeply incorporate frontline employees in the development and integration process.

Making Work Visible remains one of my favorite books because it is so simple and actionable. Applying the concepts from the book to the challenge of change integration, we created a weekly meeting (yes another meeting) forcing everyone (developers, clinicians, the finance team, HR, innocent bystanders) to see what is going through the development machine to be integrated into frontline service. This meeting, often attended over protest, allows for clear communication of the intent of work, its status, and indications of what is coming to whom, by when. This visibility keeps everyone aligned on the purpose of work, gives an opportunity to pause/kill work, to resolve false assumptions, ensure that intended work can hit its goals and that goals are relevant, allows time to plan for training and managerial efforts, and allows the work to be paced. By definition, everything that changes the experience of your front line goes through this integration system–HR changes, payroll changes, everything. All changes are changes. While this can seem unwieldy and bureaucratic at first, the alternative is haphazard change flying at your employees.

The key to work visibility is that it isn't an “approval” meeting, rather a collaborative place to be informed but also push back, ask questions and make plans. It must be led by a senior master of ceremonies who has the authority to change schedules based on points raised by the group, and keep everyone engaged on work that is soon, hot or blocked. For instance, I used to count to five and if no one spoke on the piece of work being discussed (represented by a trello or jira card), then we moved on. It made the meetings faster and less boring. We could do this in an hour every week with a 750 person company. You can too. Done well, this active work visibility builds empathy, understanding and clarity as to intentions AND the reality on the ground. While your best people may initially hate it (and finance will resist the longest), over time it will become the beating heart of your organization.

But visibility alone is not enough. You must incorporate the front lines into your development process. Remember I told you I’d tell you what to do with all of the other clinicians that did NOT join the development team? For every result prioritized (formerly known as a roadmap) you can dedicate both central development and front line operator/creator individuals from across the organization in your development work. The RAPID framework allows you to square the circle between agile and operating teams, with your development teams facilitating disciplined creative work rather than DOING the development work in a vacuum. The front line clinicians are involved in creating the changes and in communicating to their peers throughout development and integration. By “putting their face on the work” through teaching & training, they calm bewildered, well-intentioned clinicians who, in resistance to overwhelming change, will ask “Who built this?” To this, you can reply with confidence that “Your peer, Dr. so and so from Atlanta.” This distribution of development and integration seems slower at first, but it has the dual benefit of bringing sites closer together, while lowering the sales burden of a change, because half the recipients personally know and trust one of the creators.

So in summary: when resistance comes to your speedy pace of development, recast your focus on integration– focusing on the impact of the changes rather than the changes themselves. Make your work visible, including users in development and integration supported by your development teams, and iteratively work toward systematic operations resulting in achieving your goals. You then get to keep pushing your goals higher, broadening your impact and moving closer to achieving your mission every day. And once this all gets humming, your constraint will shift again!