A New Process To Improve Shipping Output
CEO at Pilot
A lot of teams will struggle with shipping products and features, especially when they a company is just beginning to develop. I have faced this two times, both while working as the head of an Engineering and Product team made up of four or five people, I found that the team was struggling with output and with shipping things. It wasn't because my developers weren't coding, it was more because of our coordination and the incentives the team had.
"If our users couldn't use the feature, then the engineer's work wasn't finished."
I found the team was building things but wouldn't ship them. For example, they would just be waiting in a branch or they would be deployed but hiding behind a feature flag. Because of this, the new features we were developing weren't getting to our users.
We had a process where we would demo features to the rest of the company every two weeks. One of the first steps I took was to ban presenting unfinished work. In addition, we redefined what finished meant. If our users couldn't use the feature, then the engineer's work wasn't finished. This helped to prevent people from getting credit for building something until it was actually live and affecting our users.
We also made sure that we tracked the velocity of the engineering team. However, we did it in a way where we were only rewarding points for a sprint when something is actually shipped. We also started to reward people for shipping features more and celebrated their achievements - this could be a Slack message congratulating or a one-on-one conversation about how well they had done.
We took slightly different approaches to solving the problem. The first time around, we put together a fairly structured process to get things out and to keep the team accountable. There were multiple steps to this process, but ultimately all of the different stages were only awarded points in our velocity tracking when the feature got out to the users.
The second time around, because we also wanted to optimize for the amount of time we were spending on managing the process, we took a slightly different approach. We made the team accountable for features and stopped tracking engineering tasks. In addition, everyone working on the feature (e.g. the designer and the engineer) was made jointly responsible for getting the product out of the door. This helps to incentivize our engineers and designers to help one another.
"Incentives matter, so it's really important to understand what your employees are driven by, what they understand their job to be, and how they are being rewarded for doing their job."
Incentives matter, so it's really important to understand what your employees are driven by, what they understand their job to be, and how they are being rewarded for doing their job. If you structure your development process in a way where engineers are credited for writing code and closing an engineering ticket but don't credit teams for releasing a feature to your users, you can run into trouble.
Both of the solutions I used can be very effective - it's just a matter of how self-organizing you want your team to be. The process that's more like a pipeline can work really well and can be more efficient because engineering can churn out more tasks and, at the same time, design can churn out more tasks. However, the other approach is less structured so requires less time from a management perspective, while still providing good outcomes.
Connect and Learn with the Best Eng Leaders
We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.