At Spotify, engineering squads are cross-functional and self-organizing. The developers who make up each squad have end-to-end responsibility for what they build, in an effort to reach high alignment coupled with high autonomy. They rely on small but frequent releases — among other strategies — to achieve this.
NYC company Kustomer has taken a page from their book (or rather, a sheet from their music). Engineer Manager Oren Bukspan emphasized the importance of maintaining flexibility while encouraging individual ownership throughout the software development life cycle.
“To help us scale with these values, we changed from function-specific teams (front end and back end) to Spotify-inspired cross-functional squads (or ‘skuads’) in mid-2019,” said Bukspan.
The shakeup is intended to limit wasted work and increase product impact. Fellow NYC engineering leaders explain how introducing similar strategies, like regular release cycles and consistent iteration, has benefited their teams.
Leadership at EquityZen champions process iteration. Senior Director of Engineering Shanon Levenherz said that his team explicitly calls out any implementation unknowns before moving forward with a pull request. As a result, developers can work smarter and at a consistently steady pace.
Give us some insight into your team’s software development life cycle.
EquityZen engineering leverages a custom development workflow that facilitates predictable delivery of high-quality software. All of our features and fixes start with a problem statement, which is similar to a user story template. It’s comprised of use cases, expected versus actual behaviors and success metrics or KPIs.
Our process is nine steps. It includes a triage and stakeholder consultation, business and technical design (with optional proof of concept), scheduling and implementation via two-week sprints, quality assurance, user acceptance testing and post-deploy measurement.
Our stakeholder consultation ensures that all parties are on the same page. Our business and technical specs strive to uncover all unknowns before any code is written. QA and UAT ensure high-quality output, and post-deploy measurement compares our predicted KPIs against actual business impact.
Just as we iterate on software development, we also champion process iteration.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
We standardized this process in early 2019 and have made small tweaks over the past year. Just as we iterate on software development, we also champion process iteration. We commonly try new things, often based on team feedback gleaned from bi-weekly retrospectives.
While there have been many benefits, increased engineering throughput has had the biggest impact on the organization. By leveraging consistent, use-case driven specifications, team members don’t spend unnecessary cycles understanding business requirements. Our technical design and proof-of-concept phases provide the time needed to understand and ideate on complex technical challenges and scope definition.
In turn, the resulting implementation tasks are well defined and straightforward. By the time team members start coding, surprises are minimized and engineers can focus on what we do best: writing clear, idiomatic and performant code.
Kustomer’s engineering team works in two-week sprints. Engineering Manager Oren Bukspan said they aren’t picky about where great ideas come from and that necessary preparation is a result of cross-departmental teamwork. Developers have made a recent shift from function-specific roles to expertise-based need fulfillment.
Give us some insight into your team’s software development life cycle.
On Kustomer’s engineering team, we optimize for frequent releases to create value for our customers continuously. We emphasize flexibility and continuous improvement, empowering every teammate to take ownership. We embrace collaboration and automation to limit toil and wasted work.
A new idea at Kustomer can come from anywhere: customers, prospects or our own team. Software engineers, product managers and designers work together to prioritize projects, understand requirements, scope and architect work. They break large projects down into smaller, independently releasable chunks.
Engineers work in two-week sprints to develop features, automated tests and documentation. Every pull request automatically triggers tests in continuous integration, where engineers solicit a review from teammates. Once code is merged to the master branch, we automatically deploy that code to our staging environment. When needed, QA engineers help run additional tests. Engineers finally release their own code to production using our custom Slack bot, often multiple times a day.
We always strive to maintain flexibility while encouraging ownership.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
The core themes and values of our SDLC stem from our earliest days as a company. We always strive to maintain flexibility while encouraging ownership. To help us scale with these values, we changed from function-specific teams (front end and back end) to Spotify-inspired cross-functional squads (or “skuads”) in mid-2019.
These skuads are organized by product area. They are empowered to act as mini startups with dedicated product managers, designers, engineering managers, front-end engineers, back-end engineers, site reliability engineers and test engineers, who all sit together.
Skuads become experts in their product areas and own related bug fixes and tech debt. This enables everyone, regardless of role, to make informed decisions and have substantial impact and influence in their domain.
As an engineer, there will always be new problems to solve. Cockroach Labs’ Associate Product Manager Emily Horing makes sure her team stays flexible and can quickly respond to any new information throughout the SDLC.
Give us some insight into your team’s software development life cycle.
At Cockroach Labs, we release a section of our database software every six months. To do this, we map out our major initiatives and big features based on our company objectives and feedback collected from our users. Then we do a mini-release every month of the cycle to test new changes and get customer input. New problems to solve crop up all the time, so we always maintain a healthy degree of flexibility. That way we can respond quickly to new information throughout a cycle.
We do a mini-release every month of the cycle to test new changes and get customer input.”
How and when did you decide on this particular structure, and what benefits has your team seen as a result?
Though six months may seem like a long time, in the database world, this is a rapid pace of change for mission-critical software. We decided to run our releases at this cadence so that we can provide value to our customers faster but avoid making it difficult for them to keep up to date with the latest version.
