For first-time engineering leaders at young startups, it might seem like the answer to all of their problems is to simply get more bodies into chairs. That is until their company gains a bit of traction and some funding. Suddenly, the challenge goes from doing more with less to building a structure that enables a large team to communicate as effectively and move just as nimbly as a small one.
To help make this more of a reactive than proactive process, we recently sat down with two seasoned, local engineering leaders and asked how they know when it’s time to restructure their teams, the approach they take and how they make the transition a smooth one.
“Scope creep” is not just limited to projects. It can also be applied to personnel. Without clearly defined structures, engineering teams can grow until they hit a point where they become too big to move nimbly anymore, which inhibits effectiveness. Vince Molieri, engineering manager at HIMSS, shared the signs that signal when a team is becoming too big and as well as the structure that guides his restructuring.
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
We have been evolving team structures on this project the entire time I’ve been on it and have continuously refined our operating model to catch pain points. Currently, there are many triggers that get us thinking about a new change. Sometimes a team is just getting too big and we start seeing communication gaps become more frequent or decision speed slowing down. Sometimes the team members change and we need to re-evaluate where people can most effectively use their skills.
Our strong retrospective process helps team members voice when things are not working so we can quickly incorporate changes to address that feedback. Team feedback is critical to make minor improvements, too. On our most recent change, we recognized an opportunity to improve our time zone alignment within teams and put people who like working together on the same team. These micro improvements are just as valuable as macro shifts like making new teams.
Knowing that we intended to triple the team over a six-month period, it was clear we needed to create smaller teams with room to grow.”
How did you determine the right structure for your team/business, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
When I started, there was a team of around 20 people working to deliver the MVP release for one area of our platform. At the time, communication and shared understanding was an obvious challenge. Knowing that we intended to triple the team over a six-month period, it was clear we needed to create smaller teams with room to grow. The hard part has been filling the gap between today and our eventual target. We don’t start a new team’s worth of engineers on the same day, so for a time our teams grow and then we hit a critical mass and they shrink again.
My goal has been cross-functional teams of eight, with a product specialist, a design specialist, a quality specialist and five people with other engineering specializations, depending on the feature need. Teams are aligned to features and critical specialties and skill sets are based on the needs of that feature. Team structure is highly influential on software architecture, so we try to be mindful at each team split about mirroring that to the software architecture we think best meets business needs.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
Every change is an opportunity for a conversation. On our most recent change, I prepared a Confluence document outlining the problem to be solved, the options and the proposed path forward. I then solicited comments from the most critical stakeholders to refine the communication and drive clarity, and finally we shared with the whole team to confirm that understanding. Finally, before implementation, I followed up in Slack with a short summary of the change and a call for feedback through retrospectives so that we can continue to improve the implementation of the change.
Even though we moved fast — two weeks from starting discussion of the problem to implementation of the solution — the use of asynchronous communication methods enabled us to quickly capture feedback and develop a pretty comprehensive solution.
Team feedback can be a great indicator of whether an engineering org is designed to scale rapidly. Of course, that feedback won’t be specifically related to growth at all. Rather, engineering leaders will have to read between the lines, like Eric Conner, co-founder and CTO at Vivian Health. For Conner, feedback around unproductive meetings, a lack of direction and ownership, and mounting technical debt are all signs that it may be time for a change.
When did you know it was time to reevaluate the structure of your engineering team? What were the biggest indicators?
We first restructured the team mainly to have more effective planning meetings, standups, and retros. The engineering team had gotten to a size where, though everyone was still sort of working on everything, context was lost in these large meetings. They just weren’t valuable for the team.
Engineers need their time protected to do deep work. Meetings help build context and give direction when they are efficient, the purpose is clear and the right people attend and are engaged. Meetings also necessarily interrupt deep work. Any indication that our meetings were no longer productive was a sign that it was time to restructure.
We looked at problems engineers had brought up during one-on-ones and sprint retros that we thought could be solved with a different team structure.”
How did you determine the right structure for your team/business, knowing that team would see rapid growth in the coming months? And ultimately, how did you decide to structure your team?
We organized the team first into pods focused on shared product initiatives. At the time a few key projects needed to ship: an updated candidate chat and an overhauled candidate profile. This product-focused structure successfully shipped new features but had some shortcomings. The teams felt they lacked clear direction beyond always shipping the next project and the ownership of previously built features could slip. We also couldn’t incrementally pay off technical debt as most engineering work was focused on product.
We felt that cross-functional teams — where members knew the outcome they were trying to achieve but not necessarily the how — might be effective. Any individual could come up with an experiment or feature that might positively impact the business. We now have two initiative teams focused on concrete business objectives, an infrastructure team that improves site reliability, performance and developer experience, a team mandated to support new and existing customers, and a mobile team. We’re excited to grow with this structure for now but will continue to reassess.
What steps did you take to ensure a smooth transition to the new team structure? How did your engineers influence the process?
We looked at problems engineers had brought up during one-on-ones and sprint retros that we thought could be solved with a different team structure. We put together a document outlining the motivation, goals and proposed structure for the teams as an engineer might write a design document or RFC for a new architecture. Any engineer could comment on the proposed structure, and when everyone was aligned and aware we made the switch over.
