2016 was a big year for growth for us. We’ve been talking about it a lot because, well, it’s exciting! But also because it has had a huge impact on our team and how we work together everyday. One of the biggest changes to come out of this growth is our new internal team structure, which has helped us to be more efficient and agile for our clients.
WHAT HAD HAPPENED WAS…
About mid-way through the summer, after an influx of new hires, we realized that the structure that had been working for us for nearly 10 years was now kind of working against us. We needed to find a way to work effectively and efficiently as our team doubled in size.
The first warning signs of growing pains became apparent on the project management side of the house. Our project managers were spending a lot of time trying to manage and plan for an increasing number of developers. Our ability to be flexible during resource planning meetings was looking more and more like a complicated mess. In the past, we’ve seen that when planning goes awry, the development side of the house begins to feel it, too. Developers were running out of tasks quickly and project managers would work to fill the gaps. Any one of our developers might be asked to work on one of 30+ active projects. This was definitely less than ideal.
At Human Element, we have almost always allowed the team structure to develop organically. When your team consists of 5, 10, or 15 people a very flat structure can work for everyoneto communicate easily and get things done. But as we got to 20 and then 30 team members, we started to see team members get weighed down. We were less agile and site emergencies were more likely to disrupt the entire development team. We quickly realized we needed to make a change.
YOU’RE GONNA NEED A BIGGER BOAT
The leadership team at Human Element recognized that there was an issue with how we were structured, and they had sensed the growing pains. We put a leadership committee together to start solving the problems of a large flat team structure. Due to the potential for significant impact on the team, we included operations, project management (that’s me), and development perspectives in the group.
Our first step was to clearly articulate the problem and document what our current structure looked like. We were then able to list out what had made this model successful in the past, why it was failing us now and how it was still working for us. We then identified what a successful team structure might look and feel like, without applying an actual model. For example, we wanted the new structure to allow us to be flexible, efficient and reduce the amount of planning time. But it was also important to maintain our culture of fun, and minimize the need for additional levels of management.
We also looked to other organizations, partners and even competitors. How were they structured? Could that model work for us? Would we like the culture a certain model might promote? Was it scalable? One trend of breaking the large team into smaller groups started to emerge. The makeup of those groups looked different from company to company. Some were based on skill level, others were based on project type (new builds vs ongoing maintenance work) and some were built around a project manager. We looked at all of these models and mentally tried them on for size. We listed pros and cons for each, becoming a little discouraged as our con lists were always longer than our pro lists.
It was at this point that Jason, one of our Managing Partners, was able to pinpoint a potential solution. The existing Human Element structure was incredibly effective when we were a very small organization. It hit almost all the points for our success criteria. So what if we created small teams of mini Human Elements? What does that look like? The group mulled it over and while it was not without pitfalls, it seemed like the best solution for our team.
This process took us several meetings over a course of three weeks. We started to get buy-in from the larger team, and created a plan to rollout the new structure. It was important to us that the execution of this was as smooth as possible. We wanted minimal disruption to our team as well as our clients. It was doubly important that everyone at Human Element was up for making the change and trying it out.
Over the course of 6 weeks we planned and documented what processes would need to change and met with the team several times to get their feedback and opened the floor to questions and suggestions. I personally spent hours assigning, re-arranging and leveling each of the teams to make sure we had a balance of projects and resources. Then on September 6th, we flipped the switch and made the transition.
BUT WHAT DOES ALL THAT LOOK LIKE?
Below in Figure 1 you can see an approximation of our old team structure. All PMs and their respective client lists could easily end up working with any given development resource at any time. Resource planning meetings took about 90 minutes every week, plus another mid-week check-in to make sure everyone had the resources they needed. The breadth of the team became to large to manage in this way.
In Figure 2 you can see that we created small groups, where each team manages it’s own smaller roster of clients, and includes designated project managers and developers to work on those specific clients. Teams were assigned based on a developer’s skill set and the projects on a PM’s roster. We had to take care to make sure every team was balanced in terms of front end and back end resources as well as project hours.
We used color names for the teams. This might not seem like a big deal, but we wanted to make sure there was no hierarchy between the teams. We don’t have an A team and a B team, we have Red, Blue and Green teams.
In the new team structure, we found it necessary to create a few new roles that we didn’t have before:
- Team Tech Lead: Each team has a Tech Lead that is responsible for assisting dev team members with tasks, checking in with their tech team and having a high-level understanding of ongoing projects and their status.
- Dev Float: This role is intended to be an assist to all teams and is a higher level resource. Part of this person’s responsibilities is to handle site emergencies as much as possible.
- PM Float: Like the Dev Float the PM float is intended to assist all teams. This resource works with the PMs to help solve tricky issues and move work along for each team.
OK – BUT WHAT IF WE GROW MORE?
You’ll notice in Figure 2 that the Red team has an extra Dev and PM. It seems like a simple matter or re-allocating the dev to different team or redistributing some projects to other teams to balance things out. However, the extra resources on the Red Team was an intentional move during planning.
At some point in the future we know we’re going to need to hire more developers and take on more projects. Our three mini-Human Elements won’t be able to sustain that on their own. At that point, we’ll need to spin off a new team. The idea is that one team might seem a little heavy on resources, but when the time is right we’ll split off devs and a PM and build a new team around them. That way they’ll have knowledge of the projects instead of starting from square one on everything.
It was important that we made this model scaleable, and even transferable to remote offices if that becomes a need. We’re hoping that this new structure can withstand the test of further growth and change in the organization.
One of the most challenging things in this transition was our inability to pilot this new structure. As we were discussing rollout I realized that if we were to pilot the program with a small group, but left the rest of the team on their own it would have caused more stress and disorganization. However, the risk of not piloting the teams meant that we could possibly transition a team into something that didn’t work at all and we would have wasted time and money. To mitigate the risk, we documented success markers for both the short term and long term. We also created a rollback plan.
Another challenge for me personally, was finding a way to communicate to the team what this new structure would look like and feel like when it was rolled out. When you have a group of people who are used to working in a particular way and you are proposing a major change to that, it’s important that you are on the same page in terms of what that change actually is. The Human Element Project Managers are a very methodical lot and if processes change they need to know why and how. Having early and frequent conversations and sharing documentation with the PM team and the wider team were important in overcoming this challenge.
We also weren’t sure if or how this would impact our clients. I think this unknown made our team the most wary since our clients are a very important part of why we get to come into work everyday. Our theory was that this new structure would create efficiencies that would benefit our projects and our relationships with our clients. The best way to clear up this uncertainty was to find a way to measure how our clients felt we were doing. We sent out a survey to our clients asking about their overall satisfaction, how responsive we are and whether or not they would recommend us to another company. We took a baseline measurement in August before we rolled out the new structure and we’ll be sending out another poll in the near future to see how we’re doing.
We’ve been working under this new structure for almost 5 months now and I feel that overall, it’s been a success. We solved a lot of the issues we were experiencing and the new problems that pop up are being resolved by each team in different ways that work for them.