Lost in translation: How one engineer learned to speak CFO – Chapter 4
Synopsis
Building a simulation business case isn’t only about having the best technology, it’s about explaining its value in a language decision‑makers understand. Marcus wasn’t trying to change his company. He just wanted better tools to do his job. A simulation platform that could model the complex thermal-electrical interactions his current software couldn’t handle. The kind of technology that would turn weeks of guesswork into days of certainty.
He had the technical proof. He had the vendor demos. He even had a business case, at least he thought he had. What he didn’t have was the ability to speak CFO.
This story follows an engineer who discovered that translating simulation capabilities into financial outcomes like ROI, NPV, and payback period is what turns promising ideas into approved investments.
This is a fictional story, with fictional characters working for a fictional company, but it’s built on real experiences. From engineers in various industries including automotive, aerospace, marine, heavy equipment and industrial machinery, and dozens of others who’ve fought the same battle. Engineers who learned that speaking two languages fluently, technical and financial, isn’t selling out.
This is the final chapter in the series Lost in translation: How one engineer learned to speak CFO.
Read here chapter 1, chapter 2 and chapter 3.
Chapter 4: The Resolution
Six weeks after the license arrived, Marcus became the most popular engineer in the building.
It started with the controls team. They had a motor-inverter thermal analysis due in three days, the kind that normally took two weeks of back-and-forth between electrical and thermal models. Could Marcus help them set it up in the new platform?
Then the mechanical design group. Gear noise analysis, acoustic-structural coupling, deadline approaching. Just a few hours of Marcus’s time?
The integration team. The powertrain group. Even the senior engineer who’d been skeptical in the initial meeting, he had a hydraulic-thermal problem that his current tools couldn’t handle.
Marcus said yes to all of them. He’d built the business case on department-wide value. He couldn’t prove that sitting alone in his office.
By week eight, he was working sixty-hour weeks. His own projects fell behind. He spent mornings teaching other engineers how to set up multi-domain models, afternoons debugging their simulations, evenings running analyses because it was faster to do it himself than to explain it again.
Elena noticed first. She’d been tracking the utilization data: hours logged, projects completed, savings realized. The numbers were good. Too good.

“Marcus, you’re running analyses
for twelve different engineers.”
“Thirteen, actually. The NVH team
just asked for help with a vibration problem.”
“On one license.”
“I’m managing.”
Elena pulled up the utilization log.
“You logged 87 hours last week.
There are only 40 working hours in a week.”
“I’ve been staying late…”
“You’re burning out. And more importantly, you’re proving the wrong thing.” She turned the laptop toward him. “Look at the project distribution. You’re personally involved in every single analysis. That’s not scalable adoption. That’s Marcus-as-a-service.”
Marcus slumped in his chair. She was right. He’d become the bottleneck he was trying to eliminate.
“What do I do? Tell people no? I built the business case saying this would help the whole department.”
“You built the business case saying the tool would help the whole department. Not that you’d personally run every analysis.” Elena made a note. “We need more licenses. But to get them, you need to show the committee that the value comes from the platform, not from you working 87-hour weeks.”
Marcus started saying no. It was harder than he expected. The requests kept coming, just one more analysis, just a quick setup, just a consultation. Each one was reasonable. Each one was urgent. Each one chipped away at his capacity to do his own work.
He tried to train people to use the platform themselves, but the learning curve was steep. The multi-domain coupling that made the tool powerful also made it complex. Engineers who were experts in thermal analysis struggled with the electrical side. Controls engineers got lost in the mechanical setup.
By week twelve, the backlog of requests had grown to twenty-three projects. Marcus was working weekends. His own deliverables were two weeks behind schedule. His director pulled him aside.
“I’m getting complaints.”
“I know, I’m behind on the battery cooling redesign, but…”
“Not about your work. About access to the simulation platform.” His director pulled up an email chain. “The integration team says they’ve been waiting three weeks for you to help with a vehicle energy model. The NVH group says you promised to set up their analysis two weeks ago. And your own project manager is asking when you’ll actually finish the work you’re assigned to do.”
Marcus felt the walls closing in. “I’m trying to prove the business case. The committee wants to see utilization…”
“They want to see value, not you working yourself into the ground.” His director closed the laptop. “Marcus, you’ve proven the tool works. Everyone wants to use it. That’s a success. But success without capacity is just a different kind of failure.”
“I’m getting complaints.”
Engineering Director
That night, Marcus sat in the empty office, staring at the backlog. Twenty-three projects. Thirteen engineers waiting for help. One license. One Marcus.
The math didn’t work.
His phone buzzed. Stefan: Still there? Come to the lab.
Marcus found Stefan running a thermal test, watching temperature curves on three monitors.
“You look worse than when the CFO rejected you the first time,” Stefan said.
“At least then I knew what I had to do. Build a better business case. Now I’ve built the case, gotten approval, and I’m still failing.”
“How are you failing? Everyone wants to use the tool. That’s what you wanted.”
“I can’t keep up. I’m twelve weeks in, and I’m the bottleneck. The committee gave me twelve months to prove the ROI. At this rate, I’ll burn out in six.” Marcus sat down heavily. “Maybe they were right to only approve one license. Maybe it doesn’t scale.”
Stefan turned from his monitors. “Or maybe you’re trying to scale the wrong thing.”
“What do you mean?”
“You’re trying to scale yourself. Be the expert on every project, help every engineer, run every analysis.” Stefan pulled up a chair. “That’s not how technology adoption works. You need to scale knowledge, not effort.”
“I’ve tried training people. It’s too complex…”
“Because you’re trying to teach them everything. Multi-domain coupling, advanced meshing, optimization algorithms.” Stefan leaned forward. “What if you didn’t? What if you taught them just enough to be dangerous, and built templates for the common cases?”
Marcus thought about the projects in his backlog. Motor thermal analysis: he’d done five of those. Battery pack modeling: seven variations on the same basic setup. Hydraulic system dynamics: three projects with nearly identical structures.
“Standardized workflows,” Marcus said slowly. “Pre-built templates for the common analysis types.”
“And office hours. Instead of custom help for every engineer, you hold regular sessions. They bring their problems, you help them solve it, everyone learns from each other’s questions.” Stefan smiled. “You’re not a consultant. You’re a capability builder.”

Marcus spent the next two weeks building what he started calling the “simulation toolkit.” Pre-configured templates for the six most common analysis types. Step-by-step guides for setting up models. A troubleshooting wiki for common errors.
He scheduled office hours: Tuesday and Thursday afternoons, two hours each. Engineers could drop in with questions, work on their models, learn from each other.
The first session, three people showed up. By the fourth session, the conference room was packed.
The controls engineer who’d struggled with thermal coupling watched Marcus help someone else with a similar problem, then successfully set up his own model. The mechanical designer learned meshing techniques from the integration specialist. Knowledge started spreading horizontally, engineer to engineer, instead of flowing only through Marcus.
The backlog started shrinking. Not because Marcus was working longer hours -he’d cut back to 45 hours a week- but because engineers were solving their own problems.
Elena tracked the metrics. By month six, the utilization data showed a different pattern:
- Marcus: 32 hours per week on the platform (down from 87)
- Other engineers: 94 hours per week combined (up from 12)
- Total platform utilization: 126 hours per week
- Projects completed: 47 (vs. projected 35 in the business case)
She pulled up the financial model and recalculated the NPV based on actual data.
“You need to see this,” she said, calling Marcus to her office.

The spreadsheet showed six months of real results. Time savings measured on actual projects. Prototype iterations avoided. Design problems caught in simulation instead of physical testing.
“Your projected first-year savings were €127,000,” Elena said. “Based on six months of actual data, annualized, you’re tracking at €156,000.”
Marcus stared at the numbers. “We’re exceeding the projection?”
“By 23%. And that’s with one license and the bottleneck you created in months two through four.” She ran a new calculation. “If we had three licenses and distributed the load, the model projects €340,000 in year-one savings. That’s NPV of €1.1 million over five years, IRR of 312%.”
“Think the committee will approve expansion?”
Elena smiled. “I think you have actual data now, not projections. That’s what they asked for.”
The second investment committee presentation was different from the first. Marcus didn’t present projections. He presented results. Forty-seven projects completed. €156,000 in measured savings over six months. Thirteen engineers trained, with utilization data showing they were running analyses independently.
He showed the templates, the office hours attendance, the knowledge-sharing that had emerged. He showed the bottleneck he’d created, and how he’d solved it. Not by working harder, but by working differently.
“Your original business case projected €127,000 in first-year savings,” the committee chair said. “You’re tracking 23% above that. Why?”
“We found value we hadn’t anticipated,” Marcus said. “The time savings were real, but we also caught design problems earlier. Three projects avoided prototype iterations entirely because we found issues in simulation. That’s €36,000 in savings that weren’t in the original model.”
“And the bottleneck period, months two through four, where you were personally involved in every project. What did you learn?”
Marcus took a breath. “That technology adoption isn’t about having the best tools. It’s about building capability across the team. I was trying to be the expert on every project. That doesn’t scale. What scales is teaching people to solve their own problems.”
The committee chair made a note. “Your expansion request is for three additional licenses at €141,000. Walk me through the ROI calculation.”
Marcus pulled up the financial model. “Current state: one license, 126 hours per week utilization, €156,000 annualized savings. We’re capacity-constrained. There are projects we’re turning away because we can’t support more users on a single license.”
He showed the demand data. Twenty-three projects currently in queue. Requests from departments that hadn’t been part of the original case study, even the testing group wanted to use the platform for virtual sensor placement.
“With four licenses total, we can support the current demand plus growth. The financial model projects €340,000 in year-one savings, €425,000 in year two as adoption increases. NPV over five years: €1.1 million. IRR: 312%. Payback period on the expansion investment: 3.7 months.”
“And if adoption doesn’t grow as projected?”
“Then we’re still cash-flow positive in month four. The downside risk is minimal, we’ve already proven the utilization with one license. We’re not speculating on whether people will use it. We’re responding to demonstrated demand.”
The committee chair looked at the other members. Nods around the table.
“We don’t need to deliberate on this one,” she said. “Your expansion request is approved. Four licenses total, plus additional training budget for the new users.”
She closed her laptop. “Marcus, six months ago you presented us with an excellent business case built on projections and pilot data. Today you presented us with results. That’s the difference between a good investment proposal and a proven business improvement. Well done.”

Marcus walked out of the building into the spring afternoon. Six months since the first license. Three months since he’d nearly burned out trying to do everything himself. And now: four licenses, a trained team, a proven ROI, and a model for how to scale capability across the department.
His phone buzzed. Stefan: Heard the news. Drinks tonight?
Elena: Congratulations! The CFO wants to use your case as a template for other technology investments.
His director: Excellent work. Let’s talk about what’s next.
Marcus sat on the same bench where he’d sat six months ago, processing the one-license approval that had felt like both a victory and a limitation.
This time, it just felt like a victory.
His wife called. “How did it go?”
“Four licenses approved. €141,000 expansion budget. Full training support.”
“That’s wonderful! So you’re done?”
Marcus thought about the requests from other departments. The testing group’s virtual sensor project. The manufacturing team asking if the platform could simulate assembly process variations. The whispers that other sites in the company were hearing about what the Aachen site was doing.
“Not done,” he said. “Just getting started.”
“That’s what I thought.” He could hear the smile in her voice. “Come home. We’ll celebrate the win you actually have, not the next one you’re already planning.”
Marcus laughed. “Deal.”
He stood, looked back at the engineering building, and walked toward the parking lot. Behind him, in offices and labs throughout the building, engineers were running simulations, solving problems, building knowledge.
The platform was just software. But what they were building, a new way of working, a new capability, a new confidence in their ability to understand complex systems before building them…That was something more.
That was worth the three months of rejection, the late nights learning financial metrics, the near-burnout of trying to do everything himself.
Six months ago, he’d wanted to prove that better simulation tools could transform how they worked.
He’d proven something better: that transformation doesn’t come from tools. It comes from people willing to learn new languages, try new approaches, and teach others to do the same.
Marcus got in his car and drove home.
Ready to build your own simulation business case?
Marcus’s journey mirrors real transformations happening across the automotive and manufacturing industries. Engineers at real companies like Certia, Practicon, and Cummins have successfully navigated the path from technical vision to CFO approval, and are now reaping the competitive advantages of advanced simulation capabilities.
Want to experience the technology firsthand?
Start your free online trial and explore how modern simulation tools can transform your engineering workflow. No business case required to get started!
And the good news? Today, getting started is easier than ever. Simcenter X now offers cloud-based licensing and unprecedented flexibility, making the financial case even more attractive. Lower upfront costs, scalable licensing, and pay-as-you-grow models mean you can build proof of value before making major capital commitments. Exactly the kind of low-risk proposition CFOs love to approve.
