A few months ago, I wrote an article about how we designed our organization as a matrix. If you haven’t read it yet, I can wait here while you check it out. This is your spoiler alert.
If you didn’t follow that the link, here’s a quote from the previous article: “Our org structure is inspired by Spotify’s famous culture video, but contorted a bit to reflect our collective experiences at small and large companies. In a nutshell, the Transfix tech team is a large cross-functional, and mostly flat, matrix. While our reporting structure is based on an individual’s core competency (Back-end and Infrastructure engineers report to a Back-end and Infrastructure engineer and Front-end engineers report to a Front-end engineer), our product tracks are based on a set of roles necessary to complete the work effectively. For instance, any given track will have members from each competency (Back-end, Front-end, Product Design, Project Management, etc) represented and that cross-functional team will move as one unified group through the product roadmap they’ve all agreed on.”
This gave us the ability to flex our organization to meet emergent needs while providing continuity of management. Of all our organizational principles, this structure followed our “favor fluidity over rigidity” rule and it succeeded in giving us a very malleable organization, one that allowed us to flex as needs arose in our fast growing company. If we had to, we could redirect people to new projects based on the primary need of the entire organization. Have a big project to complete? Not a problem, just move people from team to team to get it done. Because you’re a smart reader, you see where this is going from the title alone. Since I wrote that previous article, we began to notice chinks in our organizational armor.
I wasn’t receiving complaints from the people on the team. I could just see it in the their eyes. There was exhaustion and not the good kind of exhaustion from doing complicated and hard work. It was the exhaustion you see when individuals on a team have to do too much interpersonal yak shaving. Writing software, the core job of a software engineer, had become too taxing and it was taking a toll.
It was incredibly hard for a simple feature to get out the door because we found ourselves in an all too common collaboration overload situation. Our wish to create continuity meant that the managers in the tech organization had to maintain expertise over 5-6 different priorities across 5-6 different tracks and at any given time would have to switch contexts to help one of their engineers out or discuss an ongoing project or upcoming release. For individual contributors and product managers, it manifested differently with questions of who was responsible for what. It didn’t lead to finger pointing, but ownership was sufficiently muddy that it became hard to move as quickly as we’d like. Even worse, personal and team success became elusive because a matrix, by its very nature, diffuses responsibility across the collective.
Before I continue, let me do a short review of our organizational tenets:
Focus to Finish: There is only one #1 priority, so let’s ensure we are always working on the right thing.
Grow Every Day: We must provide the opportunity and support (both through our organizational structure and our relationships) to help every individual achieve their own personal goals for growth.
Favor Fluidity over Rigidity: Don’t succumb to the tyranny of sameness. Allow the organization to flex into new areas as needed and give everyone the opportunity to gain new and valuable experiences.
Empower and Entrust: Every individual, from Lead Engineer to someone who’s just getting started in their careers, is trusted to do the right thing and given the space to do so.
Don’t Forget the Small Things: Focus our efforts on large projects (80% of our time), but don’t forget to spend time fixing small things for big impact (20% of our time).
What we realized is that only one our tenets was served well by our organizational structure, Favor Fluidity over Rigidity. The others weren’t…at least not in a meaningful way. Worse, the implicit reasons for becoming an engineer and building an amazing team (ship great product and build great software) had become too hard for an organization of our size (35 and growing).
So, even though I put the matrix structure in place and wrote an article espousing its benefits, we chose not to escalate our commitment. We reset in a matter of weeks. We made the switch to a more traditional structure where a product team has individual contributors, a product manager, and a lead engineer and that cohort is responsible for the code they write and the product they produce, lock, stock and barrel.
Additionally, we set about creating clarity around what success looks like. what was difficult to do before became very easy. Product Managers built the metrics for product success with their dedicated teams and Lead Engineers began reporting on and tracking team performance metrics. We now track:
Cycle Time: Time between the start of work and production deployment.
Review Time: Time in code review.
Velocity: Sprint commitment vs completed work.
Open Bugs: Bugs created versus bugs closed.
It’s now easy for managers and team members to see trends clearly over time and we can, as a team, talk about ways to improve how we work free from the overhead of excessive collaboration. Essentially, by reorganizing, we have given teams the ability to focus on their code, empowered them to succeed by laying out a picture of success, supercharged their learning because we’ve removed the need for redundant meetings, and finally allowed them to claim ownership over their own bugs with complete clarity.
We have lost a bit of our fluidity, but we have gained a faster development cadence and code quality has grown significantly. Our prime directive has always been to build great products and great software, and the organization should hold that above all things. In the hierarchy of needs, it comes first and when you get that right, you can then layer on everything else.
I’m glad we switched to the more traditional structure. It has made it easier to work. The organization just gets out of the way. More than anything, I’m proud of the team for evolving. We are going to try things, even at an organizational level, and sometimes those things won’t work, no matter how much we want them to. We need to be ready to call it, learn, and then evolve. After all, what’s the point if we’re not getting better (that applies to me too).
The Featured image is IBM’s first organizational chart. You can find a description of it here.