Week one: The portal
Halcyon made software that helped field-service companies (heating and air conditioning, plumbing, electrical) schedule and dispatch their technicians. It was good software. Customers who got it running rarely left.
The problem was getting it running.
On Dana’s fourth day as CTO, Marcus slid a competitor’s press release across the conference table.
“They launched a customer portal,” he said. “I told the board we’d have one by spring.”
Rachel, who ran sales, already had a list of features. Finance knew a vendor who could have something live in a quarter. Someone pulled up a mockup. It felt like momentum.
Dana didn’t pick up the printout. “Which customer problem did we promise the board we’d solve?”
Marcus didn’t blink. “Two enterprise prospects have made self-service a condition of signing. We’ve also lost eleven customers this year. Which of those would you like me to ignore?”
Dana asked for one hour, before anyone signed anything, to read why the eleven customers had left.
Rachel pulled up the exit notes. They read them together on the big screen.
Not one of the eleven had mentioned a portal. What they mentioned, again and again, was time. One owner of a plumbing company had written it plainly: “We signed in January. We dispatched our first job through Halcyon in March. In between, my office manager spent six weeks doing your job.” By the time Halcyon worked, some customers had already decided it didn’t.
“So we have two problems,” Dana said. “Prospects want to serve themselves. Customers can’t get started. A portal might answer the first. Nothing tells us it would fix the second, and the second is costing us money right now.”
“Give me ninety days to test the onboarding diagnosis,” Dana said. “We’ll measure time to first value: the days between a signed contract and the first real job a customer dispatches through Halcyon. At the board meeting, we decide what the evidence supports.”
“And the two prospects?”
“Rachel and I will talk to them this week. If what they actually need is self-service onboarding, we may be building the same thing.”
Marcus looked at the press release for a long moment. Then he turned it face down. “Ninety days. But I’m not walking into that board meeting with an opinion. Bring me numbers.”
Solutions feel like progress. The problem is where the value is.
Weeks two to seven: The queue with a name on it
In the second week, Dana booked a conference room for an afternoon and invited everyone who touched a new customer: sales, the onboarding team, support, two engineers. She drew a line across the whiteboard, from contract signed to first job dispatched, and asked them to fill in what happened in between.
It took three hours and a lot of sticky notes. When they finished, the wall looked like this:
- Handoff from sales · 2 days
- Kickoff call · 1 week
- Data import · 2 weeks
- Integrations · 1 week
- Configuration · 3 days
- Training · 2 days
- First job
- Handoff from sales (2 days). Sales notes lived in a different system, so onboarding usually started by asking customers questions they had already answered.
- Kickoff call (1 week). Mostly finding a time on everyone’s calendar.
- Data import (2 weeks). The customer emailed spreadsheets of their technicians, customers, and job history, and someone at Halcyon mapped them into the system, column by column.
- Integrations (1 week). Connecting Halcyon to the customer’s accounting and payroll software.
- Configuration and training (about a week). The parts customers actually liked.
Then Dana asked a different question. “For each step, how many days is someone actually working on it?”
They went back through the wall. Half a day for the handoff. An hour for the kickoff. Two days of mapping. A day or two of integration work. A day of configuration, once the customer finally sent their settings. Two short training sessions. When they added it up, the work came to about six days.
Six weeks of onboarding. Six days of work. The rest was waiting: in inboxes, in calendars, in queues.
And the longest queue on the wall had a name on it. Every integration, the connection that let a new customer’s billing and payroll actually work with Halcyon, went through the same person.
Tom had built most of the integration code over nine years, and he was the only one who really understood it. Every repair and every custom request waited for him. Somewhere along the way, waiting for Tom had become part of onboarding.
Dana needed more people who could do what Tom did. Recruiting found Jordan within days: sharp, polished, with an answer for everything. The panel loved him. Recruiting wanted the offer out by Friday.
Dana asked for one more step: an hour working through a real integration problem with two of the engineers. Getting it on everyone’s calendar would cost a few days, and Marcus noticed. “I thought we were in a hurry.”
“We are,” Dana said. “That’s why I can’t afford to get this one wrong.”
The session told her what the interviews hadn’t. Jordan was brilliant at explaining his own ideas and uninterested in anyone else’s. When an engineer suggested a simpler approach, he talked over her. When the problem got messy, he blamed the requirements.
Dana passed. It meant three more weeks with less capacity than the plan assumed. In week five, Sam arrived: less polished in interviews, but better at working through problems with the team. Sam’s first move wasn’t to write new code. It was to write tests around Tom’s, so the rest of the team could change it without breaking it.
Hiring Sam helped, but it didn’t fix the bigger problem. Tom was still the only person who understood the integrations, and he wasn’t letting anyone else in.
Dana sat down with him and was direct. The integrations were the bottleneck. She needed him to document how they worked, pair with Sam, and let others make changes, with specific milestones over the next three weeks.
Tom’s answer surprised her. “For nine years, every time something broke, I fixed it at midnight and got thanked for it. Nobody ever gave me time to write anything down.”
He wasn’t wrong. Halcyon had rewarded him for being the hero, and then wondered why there was only one. Dana told him so, and cleared space on his calendar to make the handover possible.
The documentation still didn’t come. In week seven, when Elena fixed an integration bug, Tom reverted her change and told her to stay out of his code.
Dana reviewed the written expectations and the missed milestones with HR, along with Tom’s account of why the handover had stalled. Then she let Tom go.
It cost something real. One customer implementation slipped by two weeks while the team worked through code nobody had been allowed to touch. Dana told Marcus before the customer did.
But something else changed, too. For the first time in years, people started opening the integration code. Elena’s fix went back in. By the start of week eight, three engineers were making changes that used to wait for one.
Hire slow, fire fast. And own the cost of both.
Week eight: The task list
Eight weeks in, onboarding was faster, but not fast enough. Sales notes now carried straight into onboarding, kickoff calls were booked before the contract was signed, and three engineers could build integrations. Time to first value had dropped from six weeks to four. But the data import still took two weeks, the longest step left on the wall.
She opened her calendar one Sunday night and stared at it. Approvals. Reviews. Status meetings. Every change to the onboarding flow needed her sign-off, because she had insisted on it after Tom left.
On Monday morning, Elena was at her door.
“I sent you a proposal for the import problem on Thursday,” she said. “Are we still waiting for your approval?”
It had been sitting in Dana’s inbox for four days.
That was when it hit Dana. She had removed one bottleneck and quietly become the next one.
“Data imports,” Dana said. “They’re the longest step left. They’re yours: the approach, the priorities, the trade-offs. You don’t need my sign-off. Two exceptions: anything we promise a customer, and anything that could put customer data at risk. Those come to me.”
Elena found the real problem in three days. Every customer labeled their data differently: “Tech Name” in one file, “Employee” in another, first and last names split across two columns in a third. Someone at Halcyon matched every column by hand. Elena built a tool that recognized the common formats, mapped them automatically, and let customers confirm the result themselves.
The first version rejected a customer’s file in a format nobody had seen before, before importing anything. Elena didn’t escalate it. She sat with the operations team for two days, learned how they actually handled the exceptions, and rebuilt the tool around what she learned.
Imports went from two weeks to two days.
So Dana widened the circle: the whole first-week experience, then a small team to lead, Sam and two other engineers. Her calendar, for the first time since she’d arrived, had empty space in it.
A task list builds dependency. Empowerment builds leaders.
Week eleven: The one-on-one
Two weeks before the board meeting, Elena asked for an extra one-on-one.
“I got a call from a recruiter,” she said. “Engineering manager. More money.”
Dana felt the plan wobble. Elena was the reason it was working.
“I don’t want to leave,” Elena went on. “But I don’t want to be an engineer forever, either. I want to lead. A team. Maybe a product someday.”
Dana didn’t reach for a counteroffer. She asked a question instead. “You’ve been leading a project for a month. That’s not the same as leading people: hiring them, growing them, having the hard conversations. Is that what you want?”
Elena didn’t hesitate. “Yes.”
So Dana asked more. What kind of leader did Elena want to be? What did she want to learn that she couldn’t learn here?
Then she told Elena what she was seeing. The conversations with the two prospects had changed the plan. What they wanted from self-service turned out to be mostly what existing customers needed from onboarding. If the board agreed, onboarding would become a product of its own next year, with a roadmap, a team, and a lead.
“I can’t promise you that role today,” Dana said. “It depends on the board. Here’s what I can promise. You lead the onboarding team through the board meeting, I sponsor you for the role, we review your compensation this quarter, and we sit down again in ninety days to see if this is still the path you want.”
Elena didn’t call the recruiter back.
When personal ambition and company direction line up, motivation stops being something you manage.
Week twelve: The customer who didn’t fit
Nine days before the board meeting, Elena put a chart on the screen that nobody wanted to see.
Five of the six new customers had reached their first dispatched job in an average of twelve days. The sixth hadn’t moved in eighteen days. It was Halcyon’s biggest new customer: a regional company with four hundred technicians, three payroll systems inherited from acquisitions, and an operations director who had stopped returning emails.
“The new process works,” Elena said. “Just not for them.”
The room went quiet. Everyone knew what the chart meant. The story Dana had promised the board, onboarding in under two weeks, was true for small customers and false for large ones. And large customers were exactly what Rachel’s two enterprise prospects were. Both were in final contract review.
Sam suggested the obvious thing. “We could report the five. The sixth is an outlier.”
Dana had been building toward this board meeting for nearly eighty days. She could feel how badly she wanted the clean version.
“It’s not an outlier,” she said. “It’s a preview. The enterprise customers we’re about to sign will look a lot more like this one than like the other five.”
So she changed the plan she had championed. Large customers would get a different path: a dedicated implementation lead from day one, integrations scoped before the contract was signed instead of after, and a weekly call with the customer’s own team. It would take people away from the self-service work Elena’s team was halfway through. Some of what they had planned to show the board wouldn’t be finished in time.
That afternoon, Dana called Marcus before he could hear it from anyone else. “Our first five smaller customers are through. Our largest is stalled, and it looks like the enterprise accounts we’re about to sign. Here’s what we’re changing.”
There was a pause on the line. “That’s not the story I wanted,” he said.
“I know. It’s the one that’s true.”
A longer pause. Then Marcus surprised her. “Good,” he said. “Every board member has watched a CTO walk in with a perfect chart. Bring them the real one, and bring the fix. That’s the part they’ll remember.”
Sam volunteered to lead the new enterprise path. He spent the next three days on site with the stalled customer, mapping their three payroll systems with their own team instead of waiting on email. By Friday, the customer’s operations director was returning calls again, and the first dispatched job had a date on the calendar.
Dana didn’t walk into the board meeting with a clean story. She walked in with something better: a plan that fit the customers Halcyon was about to win.
A plan is a hypothesis. Hold it firmly enough to act, and loosely enough to change.
Day ninety: The board meeting
Ninety days after Marcus turned the press release face down, Dana stood in front of the board.
She didn’t say onboarding was fixed. She said what they knew.
“Five of the first six customers through the new process reached first value in an average of twelve days, down from six weeks. The sixth, our largest, showed us the process wasn’t ready for large customers, so we changed it nine days ago. It’s too early to claim a retention effect; we need two more quarters of renewals for that. Here’s what we do know. Both enterprise prospects signed, because self-service onboarding was what they meant by a portal, and because we could show them exactly how we’d onboard a company their size.”
One director asked what the enterprise path would cost. Dana had the answer ready: two implementation leads next year, and the first enterprise contract more than covered them.
Another board member turned to Marcus. “So what happened to the portal?”
Marcus answered before Dana could. “What Dana’s team built is the first piece of it. Ninety days ago I was ready to buy the wrong thing, and Dana asked which problem we were solving. We’ll bring you a proposal for the rest of the portal once the enterprise path is proven.”
The principles
- Start with the problem, not the solution. Before anyone talks about what to build, agree on what problem you’re solving and for whom, and how you’ll know it’s solved. The answer usually changes what you build.
- Hire slow, fire fast. Take the time to see how someone works with your team before they join. When someone isn’t right, give honest feedback, a fair chance, and the support to succeed. Then act, and own the cost.
- Empowerment builds leaders. Give people outcomes, not task lists, with clear boundaries for the decisions that still need you. Keep widening the circle as they deliver, especially when the bottleneck turns out to be you.
- Align ambition with direction. Learn what each person wants from their career, and find where it overlaps with where the company is going. Then put something real behind it: scope, sponsorship, and a path.
- Embrace change and adaptability. Treat every plan as a hypothesis. When the evidence changes, change the plan, even one you championed, and say so out loud before someone else has to.
Leadership is choosing the right problem, making room for others to solve it, and having the courage to change course when the evidence says you should.