Maintaining Software Team Purpose: Marco Leads a Team Discussion

Audio Discussion

When a powerful reminder of purpose touches a software team, how do they maintain that energy and translate it into lasting change? At MedTech, Marco and his team face exactly this challenge after Robert Fisher’s moving presentation about his daughter Sophie.

This story explores how a team takes an emotional spark and transforms it into sustainable technical excellence - and what they learn about themselves along the way.

Please note that all people and companies mentioned in this article are fictional.

The late afternoon sun slanted through the Jupiter conference room windows, catching dust motes still settling after the all-hands meeting. Marco sat at his desk, his coffee growing cold as he reflected on Robert Fisher’s powerful words about his daughter Sophie and the MedTech Rainier pump that had helped save her life.

He glanced at his team’s Slack channel, noting the unusual quiet - everyone still processing what they’d heard. After a moment’s consideration, he typed out a message: “Team, let’s gather in Jupiter in 15 minutes. I think we should talk about what Robert’s message means for us.”

The responses came quickly - thumbs up emojis from Sarah and Raj, “omw” from Tom, and “👍 grabbing coffee first” from Rachel. Soon enough, they were settling into their usual spots around the conference table, the energy in the room noticeably different than their typical technical discussions.

Before Marco could begin, Rachel spoke up, her voice thoughtful. “You know what struck me about Mr. Fisher?” she said, wrapping her hands around her coffee cup. “Here’s this guy who seems to have everything - successful, confident, arrives in a helicopter of all things.” She paused, gathering her thoughts. “But when he talked about trying to have children, about the IVF attempts, the adoption process… and then nearly losing Sophie…” Her voice trailed off.

Sarah nodded slowly. “Yeah, I noticed that too. All that success and privilege didn’t shield him from suffering. When he described watching every breath, every heartbeat on those monitors…” She shook her head. “That kind of helplessness is universal, isn’t it?”

“It made him more real,” Tom added quietly. “Not just some executive in an expensive suit, but a father who went through something terrible and came out wanting to share it with us. To help us understand why our work matters.”

Raj, who had been quietly listening, spoke up. “Makes you think about Grant too.” He referred to their CEO. “I always saw him as this untouchable figure, but did you see his face during the presentation? He looked as moved as any of us.”

Marco let the moment settle before speaking. “I think you’re touching on something important here. No matter who we are or what we’ve achieved, we all face moments of vulnerability and suffering. And our work here - writing software for medical devices - it’s about being there for people in those moments.”

Mei straightened in her chair. “So when we talk about quality and reliability, it’s not just about meeting specifications or passing audits. It’s about being there when someone’s child is fighting for their life.”

“Exactly,” Marco said, standing to move toward the whiteboard. “Now the question is: how do we take that understanding and turn it into action? How do we build systems that honor both the suffering and the hope in stories like Sophie’s?”

Sarah, who had been absently turning her coffee cup in her hands, spoke again. “It really hit home when he talked about the pump running for three days straight without a single glitch. That’s not just good engineering - that’s life-saving reliability.”

“Exactly,” Tom added, leaning forward in his chair. “But it makes me wonder - how do we make sure every piece of code we write lives up to that standard? It’s one thing to say quality is important, but another to actually deliver it consistently.”

Marco nodded thoughtfully. “That’s exactly what I want us to figure out. But instead of just making general commitments to quality, I want us to be specific about how we get there.” He stood and moved to the whiteboard, uncapping a marker. “And I think I have some tools that can help us think this through systematically.”

“You’ve been talking to Sam again, haven’t you?” Rachel asked with a knowing smile. The team had heard about Marco’s mentor before, and his influence on Marco’s approach to problem-solving was becoming familiar.

Marco grinned. “Guilty as charged. But this time, I think what I learned from him is exactly what we need.” He drew five connected boxes on the whiteboard. “This is called an Evaporating Cloud - it’s a tool for resolving conflicts that seem impossible to solve.”

“Like the conflict between speed and quality?” Mei asked, looking up from her tablet.

“Exactly,” Marco confirmed. “Let’s map out our situation.” He began labeling the boxes. “Our goal is to create successful medical devices that help patients. To do that, we need to meet deadlines to get Denali to market, but we also need to ensure absolute quality and safety. These requirements seem to conflict, but maybe they don’t have to.”

Lisa, who had been quiet until now, leaned forward. “How does this help us resolve the conflict?”

“By helping us surface our assumptions,” Marco explained. “We think we have to choose between speed and quality because we assume certain things about how work gets done. But what if those assumptions aren’t completely true?”

He drew arrows between the boxes, explaining how each connection represented an assumption they could challenge. “For instance, we might assume that ensuring quality means extensively testing every possible scenario, which takes time. But what if we could build quality into our process from the start, so we spend less time fixing issues later?”

Tom’s eyes lit up with understanding. “Like our assertion checking strategy - by catching issues early, we actually save time in the long run.”

“Exactly,” Marco smiled. “And that brings me to another tool I want to show you.” He moved to the adjacent whiteboard and began drawing a tree-like structure. “This is called a Future Reality Tree. It helps us map out how changes we make today create the future we want.”

Rachel studied the diagram with interest. “So we start with our goal at the top?”

“Right,” Marco confirmed, writing ‘Consistently deliver life-saving medical devices’ at the top of the tree. “Then we work backward, identifying what needs to happen to make that possible. Let’s build this together.”

For the next hour, the team worked on their Future Reality Tree, mapping out the connections between their daily practices and their ultimate goal. They identified key changes needed:

1. Implement automated testing that mimics real-world scenarios
2. Build quality checks into every stage of development
3. Maintain a sustainable pace to prevent burnout and errors
4. Create clear communication channels with other departments
5. Establish regular reviews of their assertion strategy

As they worked, Marco noticed the energy in the room shifting from emotional inspiration to focused determination. They weren’t just moved by Robert’s story anymore - they were building a concrete plan to honor it.

“You know what strikes me?” Sarah said, stepping back to look at their completed tree. “This isn’t just about writing better code. It’s about building better systems that naturally produce quality.”

Mei nodded. “And it ties back to what we discussed about maintaining a flat demand curve. If we manage our workflow better, we don’t have to choose between speed and quality.”

Marco felt a surge of pride in his team. They weren’t just paying lip service to Robert’s story - they were using it as a catalyst for real change. “This is exactly what I hoped would happen,” he said. “We’re not just reacting to an emotional moment. We’re building something sustainable.”

As the team began gathering their things, Tom paused. “Marco, do you think we could share this approach with other departments? It feels like this kind of systematic thinking could help everyone.”

Marco smiled, remembering his conversations with Sam about local versus global optima. “That’s a great idea, Tom. In fact, I think that’s our next challenge - helping the whole organization think this way. But first, let’s prove it works with our team.”

Walking back to his desk later, Marco pulled out his phone to text Sam: “Remember what you said about TOC being about Focus? I think I’m starting to really get it. Coffee this weekend?”

The response came quickly: “Same place, same time. Bring your Future Reality Tree - I want to see what you’re building.”

Marco smiled, pocketing his phone. Robert Fisher’s story had provided the spark, but it was their systematic approach to improvement that would keep the fire burning. That’s how they would honor Sophie’s story - not just with emotion, but with excellence built into every line of code they wrote.

Key Takeaways:

1. Emotional inspiration needs systematic follow-through to create lasting change
2. Tools like the Evaporating Cloud and Future Reality Tree can help transform inspiration into action
3. Building quality into processes is more effective than trying to test it in later
4. Sustainable improvement requires understanding and challenging our assumptions
5. Real change happens when we connect our daily work to its ultimate purpose

Additional Resources:

1. “Critical Chain” by Eliyahu M. Goldratt
   • Explores project management through the Theory of Constraints lens
2. “Thinking for a Change: Putting the TOC Thinking Processes to Use” by Lisa J. Scheinkopf
   • Detailed guide to TOC Thinking Processes including the Evaporating Cloud and Future Reality Tree
3. “The Choice” by Eliyahu M. Goldratt
   • Discusses the fundamental concepts behind TOC thinking tools
4. “Theory of Constraints Handbook” edited by James F. Cox III and John G. Schleier Jr.
   • Comprehensive reference for TOC tools and applications