A TPL is the window into engineering for non-engineering stakeholders, and a guiding light to engineers on the project. The TPL is key to the success of our operating model.Ī 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. We call this person the “Technical Project Lead” (TPL). We’re all keepers of our process.Įach project has an explicit engineering project owner. If part of our process is a waste of time, call it out. Completing 1,000 PRs in a week doesn’t matter if they don’t contribute to helping the business. We’re ultimately here to solve problems for our users and make Gusto a better business. Don’t hesitate to propose ideas/solutions and challenge ideas/solutions presented to you. Take initiative to unblock yourself early and make judgment calls where it seems reasonable rather than relying on process. Here are the core principles that my team started with to build our new process: Restart with little or even no process, and reincorporate the process pieces that actually solve pain points that arise. If there’s only one takeaway you get from this post, I want it to be this:Ĭonsider declaring bankruptcy on your process. We let go of our preconceived notion of solutions, started with first principles, experimented and iterated. We decided to approach building our team process in the same way we approach product building. My team at Gusto wanted to try something different from the industry norms. Build a process instead of just following one At Gusto, our autonomy empowers us to actively prevent this. Many engineers have been on an agile zombie team before, and we know it sucks. 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. Despite the shortcomings, the team just keeps following the same process. 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. Someone pours their heart and soul into writing robust ticket descriptions, but still ends up explaining the context of the ticket to someone else. Hours of team time are dedicated to pointing tickets and debating estimates, but no one is sure who the estimates are for. The team spends each morning regurgitating what’s on a kanban board while everyone tunes out. Escape zombie modeĪcross the engineering industry in general, it’s common for teams to slip into “agile zombie mode”. Over the past year, my team has developed a somewhat unconventional method that has resulted in better productivity, outcomes, and team happiness. At Gusto, teams have a lot of autonomy on how they work.
0 kommentar(er)
