Scaling the Engineering Team at Vivun, Part 1: From Early Startup to Growth-Oriented Organization

From its inception, Vivun has always been a company filled with extremely talented people driven by a passion to make a difference. “We, not me” is a one of the core values of our company. But even with the best and brightest team members, Vivun has still had to overcome numerous challenges as we continue to grow. What follows is a history of our engineering team structure and the process of transitioning from our early startup days to a growth-oriented organization.

Special thanks to Randy Walsh, Jared Sutton, and Deepika Jha for their contributions to this post.

Early engineering at Vivun

In its early days, Vivun did not have a dedicated product team, and there were limited resources. Without a dedicated product team, our expert founders stayed very close to every project to satisfy our early customers.

Our scarce resources were only assigned to the most important projects. In this project-based model, heavy scoping up front was needed to provide more predictability to customers. After each project was completed, teams disbanded and their members were assigned to the next prioritized project.

This project-based mode of operating had its advantages when resources were minimal since it ensured they were only assigned to the highest priority projects. As Vivun’s engineering resources grew, and as we started to face more scalability and product stability challenges, the company transitioned into a multi-product operation that needed to evolve.  

While the project-based, waterfall approach was effective in delivering a variety of projects to satisfy customers, it had some drawbacks. This approach resulted in constant context switching between projects that often weren’t related to each other. Because engineers had to pivot between product areas without specific feature focus, there was less satisfaction and ownership than with more focused feature teams.

Our structure also left us with less opportunity to accumulate domain insight. Additionally, there was an inability to quickly iterate to improve products based on customer feedback, since projects to implement new product features followed a lengthy approval process that culminated with CEO approval.

This arrangement resulted in less collaboration between product, engineering, and design since engineering resources weren’t assigned until after the approval and team formation process were complete, leaving product managers with no one to collaborate with in the early stages of a project.  In some cases, projects were completed by a single engineer which allowed little room for collaboration and feedback from other team members.

Growing pains and challenges

The problems associated with a linear waterfall approach were exacerbated as we expanded our engineering team. Planning projects and feature improvements became a lengthy process as we tried to front-load all of the requirements and designs while doing our best to determine dependencies and risks. This, combined with limited communication between the people involved with the project, led to delays and refactoring. We were missing the agile benefits of adaptability, alignment, continuous improvement, and customer feedback throughout the process. 

Product fixes and technical debt also became a source of frustration for the engineering development team. Frontend and backend engineers would regularly be assigned bugs to diagnose and fix mid-sprint. Not only did this create scope creep and context switching, but it also led to confusion around work prioritization for the engineers. We were missing the ability to assess the severity, determine the level of effort, and prioritize the work against other development work. With limited agency, some engineers felt they didn’t have a voice in the process and were simply there to “chop wood and carry water.” 

We began to realize that we needed mission-driven, cross-functional feature teams to drive thinking on solutions, prioritization, and how to organize around those efforts. We needed to organize ourselves for shared discovery and collaborative product shaping by product management, design, and engineering (including QA, BE, FE, Data Science, Data Platform, and Project Management). Vivun needed feature teams that could own a space (product area, components, and tools) long term, drive their own priorities, and iterate quickly to improve products based on user feedback.

One experiment, one project

Up until the second quarter of 2022, the vast majority of our projects were executed using the waterfall method—including the addition of automated calendar tracking for PreSales teams within Hero (known as Calendar Intelligence). Due to lingering customer reported issues and unclear timelines, some customers wanted to turn off the beta feature for Calendar Intelligence, which alerted us that action had to be taken promptly. 

Instead of transitioning the entire engineering organization from one process to another, a cross-functional and self-organized agile pod was created with a sole focus on the Calendar Intelligence project’s deliverables. Forming a self-organized agile pod with different functional domains embedded in the team allowed for increased collaboration, better communication, and a sense of responsibility for the product and deadlines.

Team members also felt empowered to make their own decisions and solve problems more efficiently. A prioritized feature set roadmap, localization of decision making, and resource control enabled the team to make immediate decisions to address issues without having to seek internal approval or go through a staffing process. As a result, the team continued to deliver prioritized feature sets with incremental value and the business felt confident to roll out Calendar Intelligence feature sets to all customers in three months of forming the agile pod structure. 

As new teams continue to form at Vivun, each member of the team has the flexibility during their agile transition to adopt and modify scrum ceremonies that fit their needs. Above is an example of our virtual-collaboration using Figma to discuss the team mission and agile mode of operations. 

Crowdsourcing a new path

Once we realized we needed to evolve into a growth-oriented organization with multiple feature teams, we needed a way to change our process to a new team-based approach. We also recognized we needed bottom-up feedback to evolve. What better way to approach this challenge than with crowdsourcing?

Instead of a top-down approach with leadership hammering out a new process and then rolling it out, we decided to do things differently and put things in the hands of those who would most be impacted, and eventually form our new feature teams.  When we announced the rationale behind making this change to the technology team organization, we identified process committees to “crowdsource” ideas and input from every discipline, including: Engineering, Product, Design, Security, and QA. Two process committee working groups were formed, each with a representative from each discipline, and they produced a non-prescriptive playbook that was shared with the feature teams to be used as a starter toolkit.

The first process committee working group focused on incorporating insights from peer feedback and Vivun’s process experience to date in order to recommend how we should operate in teams going forward. This working group also drew upon our own recent experiment to create a feature-based team to complete one of our priority initiatives–Calendar Intelligence.  By empowering this group to develop and recommend their own solutions for our new way of working, we ensured ownership and transparency throughout our transition process.

Since collaboration and bottom-up feedback were key to our approach, this team-focused working group did not prescribe a set of rigid agile principles for teams to follow. Our objective was to give each team a toolbox, not a rulebook to be successful.

The working group determined key questions teams should answer for themselves when forming into the new feature teams model. For example: What is our mission? What are our values? What rituals do teams need? How do they define the definition of done? What makes for a good story?

These questions were prepared for all new feature teams to consider, and then decide among themselves how to implement them in their team charter.  With the help of designers on this team, the team-focused working group created a fun, interactive, and guided charter using Figma, which would eventually become the basis for each feature team’s individual charter and way of operating.     

The second working group focused on how we should function across teams after the team-based model was implemented. This group focused on identifying areas where consistency is important. The “cross-team” working group paid special attention to areas that would span teams after we transitioned to the team-based model.

For example, the cross-team committee proposed consistent role descriptions from team to team. This committee also tailored a quarterly Program Increment Planning process to ensure priorities, roadmaps, and dependencies were coordinated across teams every few months in order to prepare our Quarterly Backlog. Notably, instead of top-down choices driving our roadmaps during Program Increment Planning, we realized roadmaps should be driven at the team level. There were several other cross-team processes this team addressed, including how to handle: Program status reporting across teams; coordination with security on key priorities; bug triage and classification; and onboarding.

Transparency and communication were key aspects to this entire process. Not only did we crowdsource our efforts in each working group by having representatives from every discipline across the technology organization, we also ensured open communication throughout the process. In addition to delivering the non-prescriptive playbook to guide team formation, there were three key events to ensure transparency along our path to organizing into feature teams:

1. The first was our kickoff event to announce the rationale behind creating feature teams to the technology organization and the formation of process committees.   
2. About a month later, another event was held where process committees shared their proposed process changes. At this time, guidance was provided for teams to form and start work on their team charters.  
3. After another month, this process culminated with each new feature team introducing its members and sharing its mission, values, and scope ownership. 

Until now we have mostly described the history, context, and growing pains Vivun experienced as a growing organization. In the next blog, we’ll focus on the implementation of our solutions to these. As many know, Agile can take a myriad of forms and what might work well for one organization with a specific culture might not be best suited for another organization with a different culture. With our next blog, we’ll describe the Agile flavor that Vivun chose to adopt and is implementing right now. We’ll talk about how it is working for us and what our secret sauce is!