Digital Storytelling Platform

Divide and Conquer for Team Management Success

As the year progressed, the team grew, gaining more trust and investment from Pixelberry. The proof of concept evolved into its own software brand: StoryLoom. Atomic organized the expansive work into three thrusts across Atomic’s Grand Rapids and Chicago-based teams:

• One team inherited the original concept: Creator Studio, where users write and design original stories users can play.
• Another team took on Character Canvas—a part of the app that let users design the characters that would star in their stories.
• The last team tackled Player Experience—building out the marketplace for content creators and the interactive community where users could discuss the stories created.

These teams complemented Pixelberry's internal developers, who developed the game experience itself. With so much work happening in parallel, project management took on great importance.

Delivery Lead Tammy Pearson helped keep Atomic’s and Pixelberry’s stakeholders aligned, informed, and on task.

“We’re very careful about respecting their time and the communication channels we use,” she said. 

“Our choices around communication with the client have proven to Pixelberry that we’re good stewards of their budget and that we understand what we’re here to do.”

Robinson from Pixelberry said this investment in communication paid off.

“Within 6 months, we started recording the meetings Tammy would lead and share them across all divisions,” he said. “That was the benchmark for internal competency and customer service.”

Speedy Development through Micro-Frontends

To balance building different parts of the app at once, Atomic architected the app with parallel work streams in mind.

“We divided what could have been one big app into composable sub-apps that each team could tackle,” said Software Consultant & Developer John Ruble. 

“That led us to some cutting edge micro-frontend technology, that looks like a single app made of different modules or sub-apps.”

The micro-frontends allowed for three different teams with their own codebases. This enabled different teams in different cities to work on the same product at once without any toe-stepping. By dividing and conquering the features, the three teams made up of more than 20 makers moved through the work at a faster clip to meet the client’s deadline.

When Pixelberry takes ownership of the entire product development, they will inherit the same architecture, which will allow the company to scale more easily.

In addition to helping them scale, Robinson said the development structure helped build a better culture of development internally at Pixelberry.

“Atomic did as much to teach them how to manage the project as I did, because they could see an example of how a producer worked, how they communicate, and what’s an expectation of performance,” he said.

“No one ever goes to development meetings unless you’re forced to, but when there’s a queue to get in and people are mad they didn’t get invited, that’s how development should be.”

‍

‍