Six tools became one. So did the picture.

THE COMPANY

Four brands, one company. No project managers.

BEGiN Learning is an early-childhood education company built from four separate brands brought under one umbrella — digital apps and physical products for kids aged two to ten, with a hyper-focus on two to five.

"That's where learning starts, and where kids typically need the most help, because they're just getting into school, or getting ready for school, and kids can be in wildly varying different spots."

Keith Brickley, Senior Program Manager, BEGiN Learning

Keith runs operations and delivery practice across the organization. Notably, BEGiN doesn't really staff project managers.

"We have people here who have been project managers, but that's not their official title — they have that mindset. I work across the organization with all the teams, making sure they're spending as little time as possible doing reporting and task management, and the most amount of time doing work. Creating, building, fixing."

That constraint matters. Every hour BEGiN's teams spent maintaining the picture of the work was an hour not spent making the product.

THE PROBLEM

Six tools. No way to see across them.

When four companies become one company, the org chart merges long before the tooling does.

"We had four companies that came together that all used different tools. ClickUp, Monday, Asana, Jira, Pivotal Tracker. There were at least five or six different tools teams used to track work that were now all under one roof. And we had to go to one tool — to make it work for everyone, and for leadership to be able to track and see progress."

That second half is the whole brief. Consolidation wasn't the goal on its own; it was the only route to a single view of what was happening across a company that had just quadrupled its number of teams.

The tools themselves were the barrier. The sheer number, as Keith puts it, "alone creates silos" and "creates barriers for both information and collaboration."

And BEGiN is unusually cross-functional, so the silos bit constantly. A single piece of web work might need data, creative and marketing alongside it — each in a different system. "It was, oh, let me make a ticket in your tool and you go make a ticket in my tool," Keith says. "They don't talk to each other."

The sixth tool was a spreadsheet. And it was wrong on arrival.

Because none of the five spanned the teams, cross-functional status lived where it always lives: in a sheet somebody had to keep alive by hand. That spreadsheet was, in every practical sense, the sixth tool — the only one everybody used, and the only one nobody could trust. Keith's internal pitch for change came down to a single sentence.

"The moment you put it into a sheet, it's out of date. The moment you get an export from any tool — because you have to combine data into one spot — it's literally out of date after you hit export. If someone goes in and changes one status, you don't have that status update. So you're always behind the ball."

He'd built exactly that artifact himself: a sheet with a section per department, everyone filling in their part, everyone then going back to update their own tool and never the sheet, and the whole group meeting around a document that had been wrong since the moment it was created.

The licensing math made it worse. The stale sheet wasn't just the best shared view — it was the only one most people could open.

"Not everyone has access to every tool, and not everyone can see, because you're not paying for licenses across the whole company. That's just super expensive. So I bring up the sheet — but it's always out of date."

THE OBJECTION

Any one of them would have worked. For half the company.

The obvious move was to pick a winner from the tools they already had. Keith could see why that wouldn't hold.

"You could have gone to any one of those tools. But when you look at those tools in a vacuum, they serve only a portion of the users. If you say, hey, let's all move to Asana — the marketing team, the sales team, they love that. Engineers hate it. If you say let's move to Jira, engineers are like, yep, that's my world. And the marketing team's like, I don't ever want to touch that thing."

Every option on the table won one half of the company by losing the other half. And Keith had watched what happens when a team tries to escape that trade by migrating from one heavyweight tool to another.

"You're going from one massive tool with lots of stuff to another massive tool with lots of stuff. You're not making it easier. You're just replacing the chaos with a different form of chaos."

What made a single system survivable was that it didn't demand a single way of working. Some BEGiN teams run Kanban. Some run sprints. Both are true at once, and neither taxes the other.

"One team's desire to work that way does not impact or impede another team's desire to work in a different way. But you can have it all level up to the same single point. And that's what matters to everyone else. The teams get what they want, PMs and leadership get everything they want. It's almost a meeting-in-the-middle type thing."

Keith's framing of where a tool should bend and where it shouldn't:

"It's flexibility right where you want it. And it's inflexible in all the places where it probably shouldn't be flexible."

He's equally clear about the opposite failure — the tool that lets you customize everything until nobody can untangle it.

"You could make Jira super customized, and it becomes very unwieldy for anyone to break apart. A new person comes on board and you're like, yeah, we have this, but you need to know five different teams use it five different ways. In DevStride there aren't a thousand features, there isn't I can flip every one of these switches and make this super customizable — because once you go down that road, you can't come back."

That restraint pays off later, too. BEGiN has reworked its workstream structure more than once as company focus shifted. In most tools that's a rebuild; here it's a drag, and it doesn't disturb anyone below it.

"It changes nothing about your boards, changes nothing about your statuses. Everything you do will still remain. They would literally not notice the difference unless they were really keen on a breadcrumb name change. That's always a wipe-off-the-brow moment for people — okay, that's not as big of a deal as I thought. Because other tools make it a big deal. They have trauma from other tools."

THE SWITCH

An export and a mapping. Under five hours.

BEGiN moved out of Jira the way most teams hope a migration will go and rarely find it does.

"We did an export from tool X — Jira — into a CSV file, and just mapped it to fields that already existed. Most of them already did. If we had to create a couple new ones, that was easy too. And then, boom, import it all. We could literally dump it where and how we wanted it. I want to say hours — less than five. It was not a heavy lift at all."

The mapping carried structure across, not just rows: work labelled bug in Jira landed in a workstream called bug, and so on down the list. Teams arrived already organized.

Onboarding was a short demo and a couple of pages of screenshots Keith wrote up so people had something to refer back to. What came back surprised him.

"The one thing I heard more than any other thing was that once they got in there themselves, within two hours — if not less — they knew how to do most everything. They were very surprised at how easy it was to pick up. It's almost like we built it up to be more scary than it actually is."

The clearest test was someone with no stake in defending the choice. BEGiN's VP of Operations gave herself an hour and a list of questions.

"She said, I'm just going to jump in, and I'll get back to you in an hour or two with five questions. After an hour she sent me a message. She said, I love this. This is great. She didn't have any questions. She'd already made stories."

WHAT CHANGED

Every team kept its board. Leadership got the picture.

Asked for the single biggest benefit — setting the cost savings aside entirely — Keith went straight to the view.

"The biggest one, even taking out being cost-effective, is being able to work cross-functionally. Different teams that literally worked different ways in different tools still work in different ways in this tool — but can work together in a way where we can all see the status, the progress, the Gantt charts, the calendar of the things being worked on."

The mechanism is ordinary and it is the whole point: separate items, on separate boards, with separate statuses, all rolling up to the same epic.

"The web team goes and makes their tickets, does what they need to do. But they might also need data help for insights on who's clicking around the web page. They might need marketing help. So we can have separate items, but they all lead to the same epic — and people can put them on their own boards. The web team has all these statuses, the creative team puts it on their board and has all these statuses. It doesn't matter. They're not in conflict, because they're doing their own work."

So the working teams look down at their own board, and Keith looks across at the epic — one place where every contributing team's work, from six formerly separate systems, sits together with its dependencies. "I can easily go to an epic and that will have everything underneath that anyone could see," he says. "You can manage it in your own way, but see it all tied together."

Status meetings became working sessions

With one live system underneath, the reconciliation ritual disappeared — and the meeting changed character.

"I do this every week with our creative team. We're on a call and it's, oh yeah, that one's actually done — and I just click done on the screen, and it's done. Nothing is out of date. We did it in real time. No exporting, no other spot to go duplicate the effort."

It also surfaced problems the spreadsheet had been hiding. Once nobody is merging exports by hand, the question stops being whose copy is right and becomes why isn't this being kept current — a question you can actually act on.

THE PROOF

The plan got built in the room. Not written up afterwards.

BEGiN began planning the launch of a new physical product under its Little Passports brand. Keith, the CMO, and the physical-product team went into a room and built the go-to-market plan directly in DevStride rather than writing it up afterwards.

"Just having everyone in the same room looking at one tool, we built out what we need to do to go to market with this. And then having it built out all along the way, we'd refer back to it — okay, here are the things we need to talk about. It kept us very on track and in line. It was a central spot for different folks from different teams who could all view the same project plan."

The same pattern held for a second, very different piece of work — sunsetting an older offering — where the plan was assembled live, on screen, as the conversation happened.

"People were like, oh, we need to do this — and someone can just make a new item as a placeholder. Then you could see all the things we need to do, start throwing out dates, use the Gantt chart to move some stuff around. Being able to do that in one spot progressed the conversation dramatically faster."

The shift is small to state and large to live in: meetings stopped ending with a list of things to go write down. Before, Keith says, it was "a lot of hours — which costs a lot of money, people time and dollars — spent just trying to come together on what's the current status?"

The project delivered on time. A plan built in the room, hitting the date the room set.

THE LINE ITEM

Off the software bill. More than $50,000 a year.

With the legacy tools shut down, the software spend went with them.

"We were able to shut those all down and save over $50,000 a year. And we're a small company. For larger companies this would scale up significantly. It was a big chunk of money, just saved on tools."

That number is the floor, not the ceiling. It counts licenses. It doesn't count the hours BEGiN's teams were spending exporting, pasting, formatting and reconciling a picture of the work that was wrong on arrival.

KEITH'S ADVICE

The software took an afternoon. The agreement took longer.

Worth being precise about what took time at BEGiN, because it's easy to read the wrong lesson into it.

The technical work was trivial. The export, the field mapping and the import ran in under five hours. Teams were productive inside two. BEGiN's VP of Operations — not an engineer — sat down expecting to surface a list of questions and had built stories inside an hour instead.

What took a while was getting a company that had just merged four cultures to agree to move at all. That's a change-management problem, and it would have existed no matter which tool BEGiN picked.

"It took a while for me to get DevStride adopted here. It was a long journey, which I think most people usually give up on. There was a time where I was like, okay, this just seems like it's never going to happen."

The resistance wasn't about capability. It was about memory. Everyone in the room had lived through a bad migration before, and they were pricing that experience into this one.

"There's a bit of too good to be true. People are scared of change, especially at a company. If they moved from Monday to Jira, it's just a pain — you're going from one massive tool with lots of stuff to another massive tool with lots of stuff. So there's a mental barrier there. It's tough to switch, I don't want to think about it."

What broke it open wasn't a better argument. It was showing people their own work, already moved.

"It's not only persistence. It's take a chance on it yourself. Get the tool for yourself and run with an example. Make some examples of what it would look like with your company. Because the proof is in the pudding."

So Keith — a program manager, not a developer — did a sample import of BEGiN's real Jira data, with help from the DevStride team, and put the two side by side.

"It's, here — here's literally your work from Jira. This is your today in Jira. This is my today in DevStride. And I can drag these things around. I can do this. I can create a marketing thing. That took, I'd say, a day. Not even a full day — I did it in the time between other things."

The demo did what argument couldn't, because it removed the part people were afraid of.

"The farther back you are from showing concrete examples to your colleagues, the more they have to imagine what it could be. And when people imagine, they'll think the worst — because that's how they've always been burned by something. Leave less to the imagination, and show it."

Once colleagues could see it rather than picture it, the objections went with the picture: "Once I show folks, all of a sudden those walls start to come down."

Asked what he'd tell someone sitting where he was sitting, he didn't need long.

"It's not as hard as you think."

WHERE BEGiN IS NOW

Consolidate and simplify. Then grow together.

"We consolidated and simplified — and then we took the simplified consolidation and grew that into what we needed it to be, and what we were missing before. It's almost like you go backwards, but I don't mean that in a bad way. Let's all start at the same spot, and now let's all grow together. The fact that you can be in one spot and start on a solid foundation — the rest is up to the folks you have at the company. That's a people thing, not a tool thing."

Four brands. Six tools. One system, and one picture of the work.

Six tools became one. Yours can too.

Export from the trackers you run today, import into DevStride, and manage every team's work in one place. Keith's whole migration took under five hours — and no team had to change how it works.

Get a guided walkthrough →

Or talk to a person: Laura Haner, Director of Strategic Partnerships · laura@devstride.com · +609-865-7416

Every plan includes every capability. No tiers, no surprises.

Download the case study (PDF) ↗