At Gusto, teams have a lot of autonomy on how they work. Teams can define their own processes. Over the past year, my team has developed a somewhat unconventional method that has resulted in better productivity, outcomes, and team happiness.

Escape zombie mode

Across the engineering industry in general, it’s common for teams to slip into “agile zombie mode”. The team spends each morning regurgitating what’s on a kanban board while everyone tunes out. Hours of team time are dedicated to pointing tickets and debating estimates, but no one is sure who the estimates are for. Someone pours their heart and soul into writing robust ticket descriptions, but still ends up explaining the context of the ticket to someone else. The team decides exactly what to work on during the next sprint but then, inevitably, an unforeseen obstacle pops up and invalidates all the planning. Despite the shortcomings, the team just keeps following the same process.

The last thing any eng org wants is for teams to slip into "agile zombie mode", yet industry wide it happens time and time again. Many engineers have been on an agile zombie team before, and we know it sucks. At Gusto, our autonomy empowers us to actively prevent this.

Build a process instead of just following one

My team at Gusto wanted to try something different from the industry norms. We decided to approach building our team process in the same way we approach product building. We let go of our preconceived notion of solutions, started with first principles, experimented and iterated.

If there’s only one takeaway you get from this post, I want it to be this:

Consider declaring bankruptcy on your process. Restart with little or even no process, and reincorporate the process pieces that actually solve pain points that arise.

Start with principles

Here are the core principles that my team started with to build our new process:

• Have an ownership mentality. Take initiative to unblock yourself early and make judgment calls where it seems reasonable rather than relying on process. Don’t hesitate to propose ideas/solutions and challenge ideas/solutions presented to you.
• Focus on outcome/impact, not output. We’re ultimately here to solve problems for our users and make Gusto a better business. Completing 1,000 PRs in a week doesn’t matter if they don’t contribute to helping the business.
• Keep the process lean. If part of our process is a waste of time, call it out. We’re all keepers of our process.

Have an ownership mentality

Each project has an explicit engineering project owner. We call this person the “Technical Project Lead” (TPL). The TPL is key to the success of our operating model.

A good TPL is responsible for coordinating with ICs to make sure everyone is working on the right thing, keep a close eye on progress/trajectory, and communicate proactively about the project. A TPL is the window into engineering for non-engineering stakeholders, and a guiding light to engineers on the project.

Focus on outcome/impact, not output

Traditional X-week sprints and point estimates are often misused to track output and in reality we don’t care about the output. Does a PM really care that the team knocked out 20 story points this week? Probably not. What they’re actually trying to understand is “are we on track to deliver this customer value?” and a good TPL should be able to answer that without all the ceremony.

Everyone on the project (not just the TPL) should have a holistic understanding of the project by working cross-functionally (aka, with product and design). They should understand what problems the project is solving and how this bubbles up into company goals. A project is not just about code - it’s about delivering value to the customer. We’ve found that when we’re in alignment with each other and TPLs are engaged, we share an understanding of our priorities and the timeline.

Keep the process lean

We encourage TPLs to choose their own project management tool/process. We’ve used Jira, we’ve used Google docs, we’ve used Github Projects, we’ve even used nothing. Since coordinating and watching the timeline is a TPL’s responsibility, they get to decide what best helps them coordinate, track progress, and keep a bird’s-eye view. For example, I typically use Google docs for its flexibility but if a TPL on my team said “I want to use Trello for my next project”, nobody would bat an eye. It’s also up to the TPL to meet with their project’s ICs as they see fit.

Putting the principles in action

I recently worked as TPL for a multi-month refactoring + feature project that involved 5 engineers. Our process enabled our team to quickly and successfully land this complex project.

First, I aligned with my product manager about why this project was important and what value we were trying to drive for our customer. We had recently built a performance management feature and customers wanted to be able to build custom, reusable questionnaires. To unlock this, we also needed to tackle some tech debt. Building this holistic understanding as a TPL was essential and sharing this understanding with ICs on the project is equally important.

Next, I created a Google doc so I could map out the actual steps we’d need to take to deliver that value. These were not incremental tickets - they were logical chunks of work that could be assigned to one person. I also included milestones in my planning. These milestones were anchor points for me to calibrate if we were on track. For example, during the project I’d realize “well I thought we’d be at this milestone by now, but based on how fast we’re moving and where we’re actually at, we probably need to push the timeline back by a couple weeks”. Whenever we realized a milestone needed to be moved I would surface it to my stakeholders right away.

Here’s a screenshot of what tracking this actually looked like. It’s certainly not the typical kanban board! The nice part of using a Google doc is that it’s really easy to change. As we got deeper into the project and we learned new things, I iterated on the doc.

At the end of each week I pushed out a status update in Slack to stakeholders. These updates kept the whole team aligned on where we were at in the larger picture. It also was a great way to celebrate the progress we were making, a critical component to team morale. Here’s a screenshot of an EOW update I made.

When a chunk of work was nearing completion, I would have a quick call with the engineer responsible for that work to chat about what they should pick up next, why, and clarify the scope of the work. This call would typically take 5 to 10 mins. Rather than trying to figure out the exact sequence across multiple engineers (which can break down very quickly), sequencing on-the-fly reflected the fluidity of actually building software.

Outside of what I’ve outlined above, there are a few meetings we adopted that are worth calling out:

• Weekly kick-off meeting. We use this time to align with product/design on new customer insights, metrics, and what they’re thinking about next. It also serves as a last-resort place for updates and coordination if people are confused. But, with a communicative TPL, that part of the meeting usually goes like this: “Any questions on the project?” “Nope.”
• Social standup 2x a week. We almost never talk about work here. This is valuable time to build relationships for a cohesive team.
• Team retro every 3 weeks. Retros are useful to make sure we don’t become stagnant as a team. Our process is a living thing that we need to keep reflecting and iterating on.

This process has completely changed the way my team builds impactful products for our customers. We chugged along proactively communicating timelines, coordinating as needed, and celebrating our progress on our way to the finish line.

Making the process work for us, rather than working for the process

My team has successfully operated with this model across multiple projects with different TPLs. We get good ROI from the time we invest into our process and ICs have a ton of maker time. Even though it’s good, we’re still constantly iterating on our processes. For example, we recently saw that small tasks were falling off our radar in between large projects, so we started keeping a lightweight backlog in Google Sheets.

While this process works for my team, it might not work for yours. It might even stop working for my team in the future. The ideal process can really vary depending on the company context, team makeup, etc. Telling you to just follow our process would be pretty hypocritical, but I hope this post gives you food for thought on what a different process could look like as well as some guidance on how to go about finding your own.