Robbie Allen

Apr 4, 2017

5 min read

Inside Ai Part VI: Lessons Learned

What I learned from a year of reconstructing Ai

This is the final part in a series on how Automated Insights revamped its organizational structure and operating model. Start at the beginning with Part I.

If you’ve made it through the whole series of posts I’ve written on changes we made at Automated Insights in 2016, you may be wondering how we survived. Looking back, I realize it was a lot of change for the company to digest in a short amount of time. But now that we are on the other side of those changes, I’m happy that we ripped the bandaid because now we are executing at a much higher level and positioned well for the future.

In this final post I’m going to highlight some of the lessons learned from the past year. Some were obvious in hindsight and others not so much.

This wasn’t surprising, but humans have a tendency to be adverse to change. With all the change we implemented, it was the first year in the past five that Automated Insights wasn’t named a Best Place to Work in the Triangle. There was a lot of uncertainty about the changes, especially since they didn’t come from the traditional corporate playbook people were familiar with. Fortunately, everyone reverted to their happiness mean eventually.

After we implemented Squads in the company, it became the favorite scapegoat for any problem someone was having. When I peeled the onion, in almost all cases the problem existed before we had Squads. Because our organizational structure and operating process wasn’t well documented before, it was hard to point the finger. Once we had names for everything, it became much easier to blame. I used a simple heuristic as the first line of defense: was this issue present before Squads? If so, let’s not blame the model and instead focus on how we solve the issue regardless of what model we are using.

We moved from a generic structure where a department would be made up of everyone with a similar role. That means our Engineering department had 15+ people in it with not very clear boundaries of responsibilities. The Squad approach forces focus and more narrowly defines roles. This can be not appealing to some people that like to switch between projects frequently. Ultimately, Squads are a better approach because it forces more accountability and limits the kind of “context switching” that leads to delays and misaligned expectations.

As I talked about in Part V, once we implemented Squads, we saw significant movement within the company. We’ve been averaging roughly 10% of the company changing their Squad membership every month. That’s a significant amount compared to traditional, functional organizations. The result is we can be more nimble about resource assignments and flexible to accommodate employee requests to try different Squads or to be a Squad Leader.

Typically, organizational changes come down from on high. That is, the CEO is the one responsible for the changes or at least is the one that communicates them. With the Squad model, it’s less of a command-and-control approach and more of a distributed decision making process when it comes to changes. Some employees start questioning whether anyone other than the CEO should be responsible for changes. Again, this is more traditional org thinking and something we had to overcome. When 10% of the company is switching groups every month, it’s not reasonable to assume the CEO can run point for all of those changes. In my opinion, the Tribe Leaders are the best group to recommend and approve Squad changes.

This wasn’t a big surprise. I went into the first Ai Guide session thinking that if even 50% of the company engaged with the program that it would be a big success. You have to keep in mind that career development is a total afterthought at most companies, so even 25% would be a lot more than what most companies do. We saw well over 50% engagement in our first 6 month session.

We wanted to make establishing career goals a requirement for the Ai Guide Program. We learned quickly that due to the lack of attention most employees (and companies) give toward career development, this was a much bigger request than anticipated. Also, we stressed that the goals should be measurable in some way so we can track progress. That’s another level of detail that is difficult to come up with. We eventually made defining goals an optional aspect of the program because so few employees could do it. This will be an area we work on in the future. I view career development like a muscle. We have to work it out to make it stronger. Eventually, most of our employees will have goals defined.

Some pretty awesome things happened in our first 6 month Ai Guide session. We had two people that wanted to explore a role change. One wanted to determine if he’d rather be a Product Manager or Developer. The other wanted to explore if he’d rather be a Developer or Data Scientist. Both ended up choosing the Developer path and we subsequently moved them to Squads as Developers. Another person (that I happened to be guiding) was interested in setting up an internal “Intro to Programming” class for the non-Developers in the company. We fast-tracked the creation of the class and he ended up having 15 employees regularly attending his classes. It was deemed a big success by the students at the end of the class. All of these happened (or at a minimum moved much quicker) thanks to the Guide program.

If there is one thing I’d recommend to companies of all sizes is to start with first principles. I don’t know if what we did at Automated Insights will work for you, but if you have a traditional org chart and traditional resource management process and traditional project management process, I think you’ve taken the easy and likely not-optimal path. Take nothing for granted. Read about a variety of ways of operating and structuring the company. Experiment. It’s too important to relegate to the traditional corporate playbook.

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