How We Restructured Our Engineering Team (As It Was Doubling In Size)

At Riskalyze, we reorganized our team so that management and domain expertise are stable without requiring that product or project assignment be static. By organizing engineers into smaller squads, individuals – and experience – don't get lost in the organization.

How We Restructured Our Engineering Team (As It Was Doubling In Size)

At Riskalyze, we reorganized our team so that management and domain expertise are stable without requiring that product or project assignment be static. By organizing engineers into smaller squads, individuals – and experience – don't get lost in the organization.

In 2017, we hired 54 people into our Engineering and Product teams. It’s been our biggest step so far away from ‘scrappy startup’ and toward ‘organization of some size.’ Since we were going to be onboarding so many new people within a compressed time frame, we knew it would be as good a time as ever to update our structure. We hadn't yet reached the point where the current one was unmanageable, but we knew that day was coming, and saw several advantages to a shakeup.

The Squad

The main quanta of our reorganization is a squad. A squad comprises somewhere between three and six engineers, including the engineer who manages the rest of the squad. We wanted to maintain as much of the small team feeling that was fresh in the memory of many of our engineers as possible. A year before this change, the Engineering and Product teams totaled about two dozen people. We also wanted to have a better way to shift and share engineers between projects, without ending up in a situation where person X was the only one who knew about system Y because she had volunteered to help with it at one point.

It was important that, while we were trying to increase mobility across the team, we didn't increase chaos for the individuals that are the team.

Moving people more easily between projects and leaders is a great goal for those leaders – but can easily cause chaos and unpredictability for the people being moved around. (On a related note, it would probably not surprise you that we also refuse to use the term Human Resources.) Flexibility at the cost of predictability for our team is not worth it, so we had to figure something out.

Our Least Bad Setup

As our CEO frequently characterizes organizational structures, we determined that the 'least bad' way to set up our team was to add a layer of management. (Cue the hissing from a trove of Medium posts.) Flat organizations are awesome – while they're still the least bad option. By embedding this new layer of managers with their engineers (roles we call ‘squad leads’), we accomplished a lot of the balance we were aiming for. These new managers were all engineers interested in taking the leadership path of career growth. They all still take sprint work alongside their teams. – it’s very much an embedded role.

Results From The First Year

We’ve found a lot of benefit to this system, but some goals have yet to be realized. In the year-or-so that we’ve been running like this, we’ve only ended up shifting squads from the product they’re used to into a new domain a handful of times. It turns out that product roadmaps get comfortable with the resourcing they have, and don’t easily adjust their expectations up or down. Our squad setup hasn’t shown that it can limit individual engineer-swapping as completely as we’d hoped. Landing the right balance of project ownership between our project manager proper, the squad leads, product managers, and our directors is also definitely a work in progress.

On the positive side, we’ve been able to more than double our team while still providing management consistency and weekly one-on-one meetings for everybody. The accessibility of our senior leaders has survived very well, albeit with more people and projects competing for their attention. If the in-person communication we heavily value at Riskalyze has changed at all, it’s more a consequence of rapid growth than any structural change.

All said, this proved to be a good move to make, with room for improvement in a 2.0 version. That’s about as much as you can reasonably hope for with an organizational change, when a new structure becomes less bad than what you’re currently using.