How I Moved Away From A Flat Organizational Structure

Problem

"When I started working for Narrative Science as their CTO, the company was around four years old. There were only about 14 engineers and forty employees in total and because of this, the structure of the organization was completely flat. The engineers all reported up to me and they would all work on lots of different projects at once. However, we were hoping to grow from 14 engineers to 25 in one year, and then another 20 in the following year. This was completely ineffective because I had too many people reporting to me and had to spend all of my time in one-on-ones. In addition no concept of DevOps or QA."

Actions taken

"I decided I needed to add a little bit of structure and approached this in two ways. Firstly, I formed a QA team and a DevOps team, hired a QA manager, and separated the development team into smaller groups. Next, I went through and defined each of the team's objectives. Next, I set up a program to hire people off-campus. We had a nice layer of mid-range engineers with 6-7 years of experience, so hiring recent graduates allowed us to grow engineers underneath them. However, our company didn't have a career path for our engineers so I decided to set up a career ladder consisting of level one, level two, and level three engineers, senior engineers, and managers. I also set up two tracks - a purely technical one and a management track. To determine where people should be on the career ladder, I put everybody's name on a whiteboard and then met with the company's two most senior engineers, as they knew the other engineers more than I did. I explained that we had levels and I asked them to place the engineers into the five different levels. Next, we went through and discussed their attributes and what made one person get a place on a higher level than another person. Once we had talked through these attributes we created a rubric of what it meant to be at one level vs. the other. Next, we discussed what a stretch goal for each person would be, and captured them to put into the higher levels on the career path. I then had to apply this framework immediately to the already-existing organization. As you can imagine, everybody wanted to know what everybody else's level was and there was a lot of pushback where people wanted to know why they weren't at a higher level. There were a couple of instances where I had to change the criteria to make it clearer as to why someone wasn't in a higher level, and I put plans and objectives in place to get people to the next level in the next promotion cycle. The hard part about implementing any new process is implementing it into an existing organization, since something will already be there, even if it's not written down. It's important to explain your reasoning for implementing changes so that you don't completely alienate everyone in your environment."

Lessons learned

"If you follow this process, it's important to make sure that the requirements for each level are clear and that you can back them up with examples. I had to train a lot of the people who ended up with direct reports in terms of having these types of conversations to explain why someone is at a certain level. They can be difficult conversations, but they shouldn't be. If the level is well-defined and you have given someone a detailed performance review, backed up with examples, you should be able to give your reports direct steps they can take to move up a level. I also always ensure that if I tell people that if they take specific steps they will get promoted, and they demonstrate they have taken those steps, then I will deliver on that promise."