When Melvin Conway introduced the idea of team structure influencing the systems they build in 1967, he probably didn’t think tech companies in Colorado would still be figuring out how to apply it in 2020.
Yet Arthur Nisnevich, CTO of Backbone, said that when engineering teams are struggling to adopt Conway’s Law — an adage that states software architecture tends to mirror organizational design — it’s time for a restructure.
Before moving desks, however, he shares the plan with engineers to ask about their work and preferences. Having teams with compatible personalities is just as important as teams with balanced workload and skill sets.
From there, Greg Keller, CTO, said it’s important that engineers have room for growth. At JumpCloud, teams employ Scrum Agile methodologies, with each team composed of a range of expertise working together independently on a single product. A front-end engineer working next to a back-end engineer, for example, provides the opportunity for both engineers to learn from each other.
And though there’s no one-size-fits-all approach to change management, Colorado tech professionals said there are some best practices for reorganizing a growing engineering team: Begin with communication and transparency.
Nisnevich said his engineering teams follow stream-aligned patterns, as outlined in the book “Team Topologies” by Matthew Skelton.
When did you know it was time to reevaluate the structure of your engineering team?
As a big believer in systems thinking, I tend to look at the current constraints and bottlenecks in the business to determine when it’s time to reevaluate team structure. If the root causes of those bottlenecks tend to be team-related, then we’re probably due for a reorg.
When workload is improperly balanced, when walls between teams hinder critical information flow or if we feel like we’re constantly fighting Conway’s Law, it’s time to think about restructuring.
How did you determine the right structure for your team, knowing that team would see growth in the coming months?
We aim to follow the stream-aligned patterns outlined in “Team Topologies” by Matthew Skelton. Most teams align to the same stream of work such as a singular product (or tightly coupled feature set), market, or business unit. These teams should be fairly independent, able to work quickly and with minimal dependencies on others. All other kinds of teams are there, in turn, to support the work of those stream-aligned teams.
Rather than applying basic models like back-end vs. front-end, we tend to look at other kinds of heuristic methods for determining team boundaries and sizes, including experience level of individuals (a balanced approach is key), cognitive load (can we fully understand the system we own?), and the need for personnel support from PMs and engineering managers.
Stream-aligned teams are intended to be long-lived.”
What steps did you take to try to ensure a smooth transition to the new team structure?
Rather than doing some sort of “big reveal” of a new org structure, it’s important to shop around your plan with engineers as well as other key stakeholders while it’s still being developed. Their input will help uncover hidden variables that you may not be aware of. For example, there might be one developer who is the only one that really understands a particular subsystem or certain designers that don’t work well with certain engineers. Though it’s fine to make minor adjustments over time, you generally want to avoid the whiplash of moving people around too frequently. Stream-aligned teams are intended to be “long-lived” even if some of the individuals come and go.
CTO Todd Benge said that as TrackVia grew, they restructured the engineering team to provide centers of excellence. Originally, each team was based on skill sets such as front end, platform, iOS, Android and QA. From there, teams move toward an integrated model that allows for growth opportunities.
When did you know it was time to reevaluate the structure of your engineering team?
Like most early-stage companies, we started out as a single team and we hired senior engineers with broad skill sets to work on all aspects of the product. Back then, we needed the versatility to move people to different roles and responsibilities as needed.
We largely rely on feedback from our employees and customers. We’ve invested in creating a highly collaborative culture where anyone with an idea can table it for consideration.
How did you determine the right structure for your team, knowing that team would see growth in the coming months?
As the company and the product grew, we knew we wanted a structure that provided centers of excellence. We moved away from full-stack engineers and built out specific teams based on skill sets including front end, platform, iOS, Android and QA.
We also wanted a structure that provided great growth opportunities for engineers to try and learn new things. We’re currently evolving toward a more integrated team approach following the two-pizza team model, empowering the team with the tools it needs to take a project from inception to delivery. This approach provides opportunities for engineers to improve their skill sets and develop team chemistry.
We’ve always worked to establish a culture of continuous collaboration and empowerment.”
What steps did you take to try to ensure a smooth transition to the new team structure?
We’ve always worked to establish a culture of continuous collaboration and empowerment. Therefore, we solicited feedback from our team about their challenges and what options we have to make improvements. We also adapted the SDLC multiple times, empowering the teams to develop the process they believe will be most successful for our environment and company.
Developing and deploying JumpCloud’s directory-as-a-service product took over 12 feature teams, including separate DevOps and DevSecOps teams. After creating multiple features for the JumpCloud product, the team grew from fewer than 20 engineers to more than 140 engineers across multiple teams. Keller said it was clear they needed to hire more engineers who specialized in various expertise including operating systems and security.
When did you know it was time to reevaluate the structure of your engineering team?
Prior to launching our directory-as-a-service product, we were like most startups: we were extremely small and all engineers were essentially full-stack. All participated in DevOps chores and all were well-versed in security practices. Our transformation to what we are now came after we broadened the feature set and it became clear that specialization in various engineering disciplines was required.
For example, while full-stack engineers could help navigate the inner workings of our AWS-deployed platform, most did not have the expertise to work against the macOS, Windows and Linux operating systems at the level we needed. Thus we hired experts to help us with the set of features we need to do our work on those operating systems. The same applied to security engineering. Further, we needed logical ways for teams to interoperate continuously across this singular platform. We are now a high-performance shop with rigorous CI and CD demands, but people stepping on each other’s toes in the early days had us look for ways to orchestrate team boundaries, common interfaces and better automation and deployment processes.
How did you determine the right structure for your team, knowing that team would see rapid growth in the coming months?
By the time JumpCloud moved into a range where customer and revenue growth enabled our Series B round, we knew that velocity mattered. While we were an extremely efficient yet small team at the time, there was clearly a directive from our board to leverage that capital, hire great talent, and help broaden and deepen the service and do so quickly.
We could see an instant correlation from feature adoption to revenue and our roadmap was a mile deep. To do this effectively, we did move to a ‘feature team’ model. Teams would essentially form around key functional areas including device management, SSO services, Cloud LDAP services, Cloud RADIUS services and so on.
Further, we wanted teams to create harmony and deep expertise so we employed Scrum Agile methodologies. Teams incorporate the blend and mixture they need for their specific area. Generally, a platform-oriented team will include full-stack engineers, SDET resources (often matrixed across teams), UI engineers and assign TPM and PMs (also, matrixed between teams). Our Agile coaches will also participate in the ceremonies across the various teams every day.
Teams incorporate the blend and mixture they need for their specific area.”
What steps did you take to try to ensure a smooth transition to the new team structure?
We had strong participation from our amazing product and engineering management staff during this whole transitional process. Deep collaboration was required to parcel out the platform into logical feature segments, then cluster teams that logically mapped to those feature segments based upon desire, skills and passion for certain areas.
Our product is unique in that way due to it being an extremely broad set of technologies to provide companies secure access control and device management for their employees. Therefore, engineers can find themselves interested in other areas where we applaud transitions to go learn new technology and solve fairly different and difficult problems.
 (1).png)
