Disorganizing an Agency’s Teams

Back in October, 2015, I wrote about Dynamo’s switch from an ad-hoc approach for project resourcing to a rigid Team structure. We divided our company into three distinct full-stack teams with the intention that any existing or upcoming project at the studio would be handled exclusively by one of the teams. I wrote about some highs, lows, and things in between that we experienced in our first 4 months within this new structure. Well, it’s been a little over a year, and since one of Dynamo’s core values is to Embrace Change, we’ve decided to change things once again.

The limits of team-based project management

While our switch to Teams was akin to changing the tires while driving, this new change has been more gradual and has, to some degree, snuck up on us. Our approach was that, since our teams were full stack, each project coming into a team should be the perfect project — we should be involved from initial strategy, through design, on to development and quality assurance, into analytics and beyond. The reality was that we were signing a lot of cool projects from great people who were in the process of building up their own internal teams (#startuplife). As a result, the specifics of how we were needed was quite diverse from project to project. A handful of perfect projects should not a company-wide rule make. We therefore started to wonder about the inevitable — since we’re seeing a lot of interesting projects from awesome people come our way that don’t fit our “perfect project” mould, are Teams still the best way to address project resourcing?

Decoupling projects from teams

As it were, we had a great case study to examine this wonder of ours. We took on a new client that absolutely required people from different teams to come together and form a “hybrid” team specifically for one project. We really wanted to work with this particular client to build their product, yet none of our three teams had the perfect mix of available resources. So we went for it, and then experienced the inevitable pains that straddling teams caused, including:

• Aligning time across teams — ensuring Niko from Team America was able to work at the same time as François from Teamye so they could pair up together to efficiently build out the solutions the project required;
• Multiple Project Managers managing one person’s time;
• Too many meetings — our teams have morning scrums that deal with all team projects, so once straddling was introduced, those straddlers had to go to another “special” meeting for their “special” project;
• People wondering what the point of Teams was anymore (just like we were wondering).

During this straddling project case study, we saw that trying to hold onto our rigid Team structure while allowing for occasional straddling was never going to work. There is too much friction between those two extremes (ad-hoc vs. team). So… what’s the solution? To be honest, I’m not sure there is one definite silver bullet to our constant project resourcing conundrum. I do know, however, that we’ll keep changing as often and as long as needed, and that right now that means decoupling Projects from Teams.

Sometimes a Jackalope is cooler than a Unicorn

Looking back, I’m extremely happy that we tried out a rigid Team structure for a year(ish) and I wouldn’t change anything about how we tackled this particular challenge. However, after having tried this Team approach for a little over a year, we discovered something about our business as well — while we thought that our “perfect project” could only ever be that custom full stack, A-Z, 100% involvement Unicorn, we have thoroughly enjoyed working on some half stack, A-J, 62% involvement Jackalope projects. For example, we’ve taken on exclusive back-end development during our augmentation of the team over at Reformation for some awesome experiential development. We’ve also gone full strategy & design during our rebranding of a great culinary innovator (GoodFood) and we’ve also taken on exclusive design & front-end development during our build of a client’s Shopify site. Each of these 3 great projects were “missing” major parts of the perfect Unicorn, yet we adored working on each one of them. It would be foolish of us, both professionally and culturally, to restrict potential partners due to a structure we had invented and implemented ourselves.

Keep the best, change the rest

So we’ve been trying something new, a hybrid approach of sorts. We’ve been on this hybrid train to SuperTown for about 3 months and, while we don’t know what it will ultimately look like, we know 2 things for sure:

1. We want to hold on to, even exploit, the best things that a Team structure offers.
2. We don’t want a structure that hinders us from taking on awesome projects from great people.

To the first point, we found that being on a Team meant that you have a central point of contact for things like vacation and sick days, you have a tight support system both professionally and personally and things like pair programming were incredibly easy to facilitate. We want to hold on to these specific positives so we’re keeping Teams intact. However, we’re decoupling Projects from Teams — meaning that a project does not necessarily need to belong to only one team. Projects are now resourced according to a few variables. The major ones being:

1. Who’s best suited for this project?
2. Who’s available for this project?
3. Who wants to work on this project?

Creating tailored processes & tools

What’s different about this approach versus how we used to do things way back when is that we’re taking a good long look at who is best suited for a project, not just who is available right now. We try to do our best to adjust expectations accordingly if the best-suited and most-available do not align immediately. This is still a w-i-p but we like what we see so far.

To help with this new format, we’re embracing process and tools like nobody’s business! Our initial thoughts were that, in the absence of a Team structure for team management, we would need to rely more than ever on process and tools to make this as lovely as possible for everyone. Since all the people will be working with all the people, we need to make movement between projects as seamless as possible. In that vein, we’re getting every single one of our projects running with the same Agile PM tool (Pivotal Tracker), we’re using one central resourcing planning tool (Float) so that each Project Manager has exposure to all of the people and projects (see our recent post on this topic) and finally, we’ve sent some people to Scrum training who have in turn brought back their new learnings to help us run a much stricter, and smoother, agile process.

Building the best conditions for Now

At the end of the day, I’m still not sure this hybrid approach is the “genoux des abeilles”, but it’s definitely allowing for some high-value project resourcing while forcing us to embrace process & tools like never before — 2 things that make the Operations side of me jump with utter glee! I sometimes find it crazy that we’ve been doing this for over 16 years and we still don’t have the perfect solution to project and resource management. However, in speaking with myriad other agency owners & operators, it’s evident to me that what we’re seeking is potentially ever-elusive, an endless quest if you will. Humans, tools, technology, requirements, expectations, and skillsets are always changing — it’s what keeps this life interesting. It’s also what makes finding that silver bullet potentially impossible. We’ve decided to try and build the best conditions we can for the Right Now and adapt as needed. With no way of knowing what the future holds, Now is all we got. And Now is what we’re trying to make awesome.