Inside Ai Part II: Implementing an Agile Engineering Organization

How listening to Spotify made us rethink our organization

This is Part II in a series on how Automated Insights revamped its internal organizational structure and approach to management. Start at the beginning with Part I.

Two years ago at Automated Insights, we started a project to build a new SaaS product from scratch. We had been acquired a couple months prior and the acquirers were supportive of us moving away from our primarily services business to one focused on recurring SaaS revenue.

We had always wanted to go in that direction, but when you are on the VC-treadmill it is really hard to make a pivot like that by the time you are post-Series B like we were. We had a growing services business in progress, and it’s tough to make a big business model change when you have to raise another round in 12–24 months. Getting acquired by a leading private equity firm with a product vision similar to ours solved that issue for us.

We started to slow down our services work and focus the bulk of our engineering team on building the new product. Since we were building something that was largely independent from the rest of the company, we didn’t feel constrained to use the same (traditional) organizational model we had grown into. While still relatively flat, we had groups split out by major functions (mainly aligned with employee roles) as is the norm:

Taken from a slide I presented at a company meeting where I described our traditional organizational structure

The biggest problems with the traditional org structure are its inflexibility and inefficiency. It’s generally very difficult to move people between groups and often it doesn’t make sense to. All the software engineers are in the software engineering group. The marketing people are in the marketing group. But what if the marketing group needs software engineers? Sure you can try to share them across departments, but in practice I rarely see this working well.

Also, as the organization increases the number of employees, the teams within each department also tend to get larger. We had a 16 person engineering team. It’s one big mass of resources and it’s easy to see the inefficiency I talked about in Part I start to creep in. Sure, you can try to divvy up the large departments into sub-groups, but it still follows a similar pattern. Maybe you have a front-end group and a back-end group. You are still aligning the org around job functions.

A Fresh Approach

A year before we started building Wordsmith, I watched a couple interesting videos about the Agile-inspired Spotify Engineering culture. I highly recommend them:

• Spotify engineering culture (part 1)
• Spotify engineering culture (part 2)

Rarely do I get excited about another company’s organizational structure and culture, but what Spotify did hit all the right notes for me. I loved the notion of loosely coupled, highly aligned, autonomous, small teams (i.e. squads). This seemed like a much better way to drive accountability and ownership (two things we had been wrestling with). After socializing internally, we decided to implement the Spotify Squad model across our engineering organization.

We embraced much of what Henrik Kniberg laid out in his videos. It was a little different for us being sub-50 employees at the time versus Spotify having over 1,200 employees, but most of it applied as-is.

We divided our group into eight squads covering different aspects of the Wordsmith product. Our workflow consisted of:

• Two-week sprints
• Mandatory demo/retro meeting every other Monday
• Following the demo meeting, each squad held their sprint planning meeting to discuss their work for the next two weeks

It wasn’t long and I was hooked on the value of the model. Everyone working on a two-week cadence with a regularly scheduled planning meeting resolved a lot of questions about who is doing what and when.

A demo meeting where EVERYONE presented helped keep all the developers in the loop on what everyone else was working on — and it also provided some positive social pressure to have something decent to show for your previous two weeks worth of effort.

The retrospective helped us continually refine the process as we went.

Nine months later and we were rolling out Wordsmith to customers. But there was one problem. We had developed this productive organizational structure and workflow for the engineering team while the rest of the company was stuck working in the traditional org chart. Marketing had their own process and cadence for scheduling and getting work done. Sales had their own process and cadence. Support had their own process and cadence.

As the CEO, it was difficult to keep clear who was doing what and by when. Also, where does the customer factor into all of this? Shouldn’t they be what we focus our organization around instead of job titles?

That’s when we decided to Squadify the whole company…

Next up in Part III, I’ll go into detail on how we remapped our organizational structure to better align with the customer journey by expanding on the Spotify Squad model.

If you like this article, please let me know by clicking the ❤️ button below!