As a company grows and its product evolves, product and engineering teams must morph to handle the increased scale of delivery and changing product suites efficiently. While individual engineers’ technical skills are crucial to successful scaling, the organizational structure that they work within also plays an incredibly important role.
So how do you know when your technology organization is due for a change-up? And how do you execute such a change without compounding any existing efficiency problems and avoid giving your engineers whiplash?
We spoke with executives, people leaders and tech team heads at mid-sized tech companies that have experienced multiple organizational iterations as they have grown. In the responses below, they offer advice on the role of senior team members, how to avoid common scaling pitfalls, the role of generalists versus specialists and plenty more.
Gordon was pregnant with her first son in 2011 when she created Babylist, an all-in-one baby registry that straddles multiple retailers. The company has experienced rapid growth over the last few years and is currently in the process of splitting its generalized software engineering team into functional teams. The goal, Gordon said, is to give engineers more long-term ownership over major systems and parts of the company’s code.
Babylist has also adopted the Shape Up method for product development, a six-week development cycle first pioneered at collaboration software company Basecamp. During the Shape Up cycle, a small team of developers and designers define their own work, meeting cadence and scope. There’s no manager carving up tickets on their behalf — it’s up to the team to figure out how they can meet each six-week objective.
What are the most important considerations for leaders looking to scale out their technology teams?
Why would technologists work for you? Today’s market is very competitive for hiring great engineers. They can work anywhere. After founding Babylist, I asked myself what would make me work here in the long term, rather than growing at all costs or simply quitting when times were hard. As a result, we’re really serious about building for the long term at a sustainable pace, which we believe leads to better work, less burnout and less team churn. The key thing I didn’t see at the time is that building a team this way also helps us bring on great people. We have team members who have experienced really long hours (often due to poor executive leadership) and really appreciate that we offer market salaries for reasonable expected working hours.
At Babylist, our team is balanced between senior and early-career engineers. When we hire early-career engineers, we evaluate for some technical skills but we equally weigh testing for trajectory and if they are going to be an energizing person for the senior team members to coach. We evaluate flexibility, project management, growth mindset and experience working in small teams through challenging situations.
“During the project cycle, a tech lead helps the team break down their work so that work can happen in parallel and dependencies are minimized.”
What role should senior engineers and other team members play as the team scales?
The main role of a tech lead at Babylist is to keep projects moving. During shaping, the tech lead identifies critical systems and features that need to change in order to deliver upcoming projects. They know the easiest and best ways to get things done in our systems. During the project cycle, a tech lead helps the team break down their work so that work can happen in parallel and dependencies are minimized. The tech lead writes some code but mainly delegates and enables others to write the software while serving to unblock them and raise the quality bar.
PulsePoint uses real-time data to unlock and activate health insights, which it says helps marketers execute privacy-focused targeting and analysis in a post-cookie world. Across a career spanning two decades and several leading tech companies, Morselli has assembled a checklist of “red flags” that tell him when it’s time to change team structure. These include team members focusing on why something can’t be done, rather than how to make it happen; roadblocks and bottlenecks existing across an organization in key decision-making areas, leading to slow execution; and team members who are confused about their current roles and responsibilities.
As head of PulsePoint’s people operations, Morselli has learned that existing team members have an important role to play as a team scales. They “know what it takes to succeed at the company” both in terms of skills and culture, making them handy partners in talent acquisition. They can also serve as effective mentors to help new colleagues “navigate specific norms, methodology and internal processes of the company, helping them ramp quickly and contribute in a shorter time frame.”
What are the most important considerations for leaders looking to scale out their technology teams?
The most important consideration for leaders looking to scale their technology teams is strategic clarity. Teams should build out a three-year strategic operating plan with key deliverables and milestones, so an organization can appropriately cascade down the technical requirements and expectations which can then be translated into sprint cycle planning. Without this, the process of designing new models and developing and sourcing the right people cannot even begin.
Once a three-year plan has been created, it is then further broken down into one-year cycles. A responsibility assignment matrix is then developed for each initiative in the cycle. This brings clarity and structure to the roles team members play to ensure that everything a team needs to do is taken into consideration. Using this system (sometimes called ARCI or RACI) every task, milestone and decision are listed with clarification on who is accountable, who is responsible, and, where appropriate, who must be consulted or informed. In the case of businesses that are scaling too quickly, all too often little time spent thinking this process through results in poor alignment across teams and unnecessary bottlenecks in execution.
“As the business scales and more nuanced deliverables come to light, generalists often give way to specialists.”
How have your team’s requirements (and its role within the larger org) changed as the company has grown?
Scaling organizations must change their approach to organizational design and team building. In a startup phase, team members are often required to wear multiple hats and contribute their skills in a generalist capacity. This nimbleness allows organizations to deliver maximum results with smaller teams — especially when the product roadmap is much more linear. However, as the business scales and matrixed and more nuanced deliverables come to light, generalists often give way to specialists — those with a far deeper understanding and expertise in a specific area or discipline. This allows for deeper focus, resulting in accelerated growth and faster execution on specific deliverables.
In addition, the organization must begin to add managerial layers to manage its growing teams effectively. This is sometimes challenging on the tech side, as technical proficiency does not always translate into managerial excellence. It’s therefore important to understand the career progression of your technology professionals — outlining both technical and managerial career ladders as viable career paths. Finally, thought must be given to developing “leaders of leaders,” those former supervisors and leaders of individual teams who, as the team grows, must in turn manage other leaders rather than individual team members.
One of the early pioneers of desktop 3D printing technology, MakerBot has stayed busy in the 12 years since it rolled out its first printer in 2009. Last summer, the company launched CloudPrint, a platform that combines remote server technology with its 3D printers to allow collaboration to continue even while team members are working remotely, away from printers.
The product “totally transformed our backlog, both in new features and technical debt,” Puder said in an interview with Built In. The company needed to adapt its underlying platforms and cloud infrastructure to handle “massive” user scale and complex cross-platform integrations, which rendered much of the team’s technical debt obsolete. To accommodate the workload associated with this project, Puder said it was imperative that his senior engineers work at “eye-level” with their teammates, as it contributed to overall success while simultaneously helping engineers develop their skills and build their careers.
As your organization grows, how do you know when your team structure is no longer fit for purpose?
Two of the most defining events in the sprint cycle are the daily standup and sprint planning. They can tell us a lot about the efficacy of team structure. If your team is too large or the team composition isn’t working, standups may go on longer than ideal. Or, in planning meetings, discussions may be disjointed and collaborative consensus difficult to reach. If this is the case, then a reevaluation would be essential to the success of the team and each of its members. For example, although our shift to cloud-based printing unified the print and cloud software teams, they remain as independent scrum teams to leverage the ideal balance.
What are the most important considerations for leaders looking to scale out their technology teams?
The ratio of staff to vendor contract engineers and the methodology for their collaboration can sometimes be an afterthought rather than a well-planned strategy, due to the nature of tech teams’ ever-changing priorities and shifting roles. Should the respective teams be siloed or unified across projects? Should each team get assigned sprint stories based on expertise, or should the story assignments be interlaced equitably across teams? The latter choices may create a multiplier effect on innovation while driving knowledge-sharing and individual growth. These decisions not only shape the effectiveness of the team but also the engineer’s sense of ownership — ultimately impacting retention.
Mark43 makes software to power computer-aided dispatch, record management systems, analytics and property and evidence platforms for more than 120 police departments and government agencies. Brydges oversees the company’s computer-aided dispatch platform, which combines fields like data analytics, mapping technology and telecommunications. Her engineering division has tripled in size during her tenure and taken ownership over key areas like the company’s location services and data transfer product.
Among her many recommendations for leaders looking to scale out an existing engineering team, Brydges recommends standardizing the way teams plan sprints, triage bugs and perform other common tasks; investing in the growth of individual team members; and ensuring that leaders bring a level of energy and enthusiasm that will help set the tone and buoy morale among the wider team.
As your organization grows, how do you know when your team structure is no longer fit for purpose?
I think it is time to change when the processes and team structure the team has in place are no longer an aid (and are an impediment) to helping the team achieve its goals. A team of five engineers needs a different structure than a team of 20 engineers. It is important to take a step back and think about the constraints the organization is facing (Is work happening slowly? Is product stability degrading?). If the cause of those constraints is due to team structure, that means it is time to update the structure.
“As engineers become more senior, it is important for them to use their technical expertise to help mentor and drive consensus on important architectural decisions.”
What role should senior engineers and other team members play as the team scales?
As engineers become more senior, it is important for them to use their technical expertise to help mentor and drive consensus on important architectural decisions. They should have strong interpersonal skills, as the ability to collaborate well with other stakeholders is a key quality for a senior engineer. They should have strong time management skills and be able to prioritize their work effectively. Ultimately, you need to be able to delegate to them, and those traits should make you comfortable in doing so.
