In our 19 years, BlueModus has morphed and changed how we operate through experimentation, necessity, and a drive to operate as efficiently as possible while bringing high value to our clients.

As background, BlueModus is a web development and design agency. We work with a variety of clients, usually implementing, integrating, or supporting .NET content management systems (CMS) in environments requiring a high degree of customization.

Some typical engagements:

• Redesign and build a company's website
• Integrate websites with CRM and marketing automation
• Upgrade from one major version of a CMS to another
• Migrate from one CMS to another
• Take over the support of an existing website

Our Progression

Infancy - Ad-Hoc Teams – 2001-2014

Here, we informally assigned projects to the Project Manager (PMs), Solution Lead (SL), and Developer (Devs) who were available and a good fit. PMs generally managed all the projects for a particular client which led to some de-facto standing teams, but no SL or Dev was dedicated to one team. There were always responsibilities to another team.

Additionally, we generally had different teams specialize in big projects (“Solution Delivery” in our parlance, “SD” for short) or ongoing support (“Strategic Services”, “SS” for short).

This worked well enough for a long time, but we discovered several years ago that we had hit that intersection where lack of structure started slowing us down rather than speeding us up.

Toddler - Emulate Trendy, Complex Engineering Model – 2014

We were inspired by Spotify's "Squads, Tribes, Chapters and Guilds" approach and tried to implement it in a relatively pure form. In the end, it was too complicated for our relatively small team. The structure led us to break more rules to get work done, and while it made management more difficult for us, it demonstrated that some type of more formal subgrouping might be beneficial.

Teenage - Keep the 1 Good Thing – 2014-2016

A simple idea: Group people together into autonomous units - squads. Each group would have PMs, SLs, and Developers. We initially had visions that each group could become their semi-autonomous division, with their P&L, making their own decisions, etc. That part never happened, but the more rigid grouping started to work. Developers especially, when they started working with fewer PMs, things started to speed up.

How Big? How Small?

The tricky part was squad size. When the squads were too big, they hindered management. When the squads were too small, we were constantly shuffling people between squads to have enough human power. It was more a series of Venn diagrams than neat little boxes.

Squads could choose their names (Taco Cat, Burrito Dog) and at one point, my squad embraced "Los Prestados", loosely translated to "The Loaned Ones." Depending on how you looked at it, we were either the temps or the ringers for everyone else.

Eventually, we found equilibrium around 8 members for a squad. That was usually 1 Project Manager, 1-2 Solution Leads, 3-6 Developers. Front-end Developers were still bouncing around because our projects tended to need them for specific portions rather than the full cycle and we started to add dedicated QA Engineers into the mix, which complicated but did not break, the system.

Around this time, we started growing quickly and added our formal design practice. This model helped from both an operational perspective as well as a social perspective (it is much easier to be onboarded into a team of ~10 that's part of a larger team than an amorphous collection of 50-100 colleagues.)

Adulthood - A New Role for an Old Opportunity - 2016-2018

Background Aside

Up to this point, we had avoided "account management." As an engineering-founded and -led organization we felt having someone to squeeze money out of our clients to be unseemly, and unnecessary. Our philosophy had always been that if we do good work, clients will keep asking us to do work when they need it. It had worked for 15 years, after all.

Our project managers were the de facto relationship manager for the clients they did projects with, and they were tasked with figuring out what was next with their clients.

As anyone who has held an account/project role will tell you, the account portion gets short-changed because the immediate needs of a project always trump the potential future needs of an account, so there was not a lot of proactive growth happening.

The Opportunity

Now that we had relatively stable groups and could focus more, we realized a few things:

• If we were going to keep the groups stable, we would need to have better planning and forecasting to avoid the ebb and flow and shuffling people around.
• The more time we spent with clients, the more we realized we could help them in ways they had not thought of. We started to be proactive rather than reactive.
• Some of our project managers were good at finding valuable work with their clients, sometimes turning small one-off projects into huge multi-year programs.

That led to the creation of our Strategic Director role. For shorthand, we usually explain it as "a combination of a consultant and an account manager on steroids."

Most of them are former project managers with wide-ranging knowledge and intense curiosity. Their mandate is to:

• handle all new work requests to allow the team to focus on current work.
• be the voice of the client and user within the team. In scrum parlance, they are the "Product Owner".
• serve as a strategic consultant and subject matter expert at the client's disposal.

The key to all these things turned out to be the "roadmap." By working with our clients to see their whole operational, technical, and political picture (even the parts we were not involved in). With that context, we could propose ways to support their long-term goals, often planning work out 6-12 months in advance.

Together, the Project Manager, Solution Lead, and Strategic Director form the "three-legged stool" of our Squad Leadership Team.

We also realized that it did not make sense to make clients juggle 2 squads as part of our workflow, so we removed the distinction between SS and SD, allowing clients to only deal with the one squad that makes the most sense.

Maturity – 2019-????

Clients, whether they were coming to us for a project or support, are assigned to a squad and, when it makes sense, stay with that squad for the entirety of their relationship with BlueModus.

Also, we stopped fighting it and created a "Shared Services" squad for design, front-end, and QA. They move around as needed, but as little as possible, using default assignments to the other squads to keep things consistent.

Though the changes in this evolution seem small – the effects are measurable:

Efficiency

Because people only work in their squad, there is only one set of group meetings people need to be a part of. It cut down our meeting time a lot and made for less fragmented days.

Consistency and Maturity

Because the same people with a client over time, the squad builds up an institutional knowledge of the client, their business, their priorities, their roadmap, and their codebase.

This consistency leads to trust and performance. Mature teams can be more high performing, and consistency lets the depth of understanding emerge. It also makes teams more resilient to personnel changes on either the squad or the client-side.

Redundancy and Flexibility

The fact that a squad is bigger than any one client needs is by design. As an example, say there are 4 developers on a squad and a project is being handled primarily by 2 of them. We will purposely have the other two do some work on the project to make sure they are set up to work on it and familiar with it. This mitigates risk, but also creates opportunities.

• People can get sick, and it does not kill progress.
• People can take a vacation without feeling guilty.
• If a big spike of work becomes necessary, more people are available to pitch in without spin-up.
• If something unexpected happens, there are more shoulders to tap.

Responsiveness and Fairness

Questions I hear all the time are “How work is prioritized?” and “How is it possible that everyone’s projects get worked on?” After some probing, what they want to know is, “How is it possible that my support work or small project won’t take a backseat to another big project?”

It is possible because we make realistic timelines, and we plan our work in two-week cycles. Everyone’s work is in the plan because everyone’s work must get done. When emergencies arise, we can more easily absorb them because the group can more easily flex and respond than if we had a more rigid model.

The Future

We are not perfect, and we are not done iterating. We try a hundred little changes every year; it is part of our culture to always try to improve. The important thing is that we are constantly getting better in a way that is better for us and better for our clients.