SaaS Developer Priorities
When I started my development career, I thought I was hired to write feature code. What else is there to building a product? I only now realize how wrong I was.
Competing Priorities
This article is geared towards small to medium-sized companies with a running, production-quality SaaS product. If you’re the only developer and don’t have a product yet, this is the time to write feature code. There’s not much more you can do.
For the rest of us, our products are living, breathing entities. They require operations maintenance, support, tech debt payments, bug fixes, and more. This isn’t even counting the feature work customers, sales, and PM are asking for.
So with all this work to do, how can we manage what to do when? How can we as a team agree on our shared day-to-day priorities? This is a critical challenge to solve, especially now that remote work is so prevalent.
The Developer Priorities List
Below is a list I’ve modified from a friend from almost a decade ago. I’ve taken it to heart, and it has genuinely changed the way I work on a daily basis. How I structure my days, weeks, and sprints is based almost entirely on this list. The list is a bit tongue-in-cheek, so please read it with humor.
The List
Fix the build if you broke it
Eat lunch/dinner
Fix blocker issues
Go home and sleep
Help to unblock your coworkers
Review other people's PRs
Update your PRs based on feedback
New feature work (or bugs)
Managing Around Blockers
The key to the prioritized list I share below is understanding the why behind the order. I was initially shocked that features were at the bottom of the list. How could the task I thought I was hired for be the lowest priority? It took me a couple of years to realize the reasons why.
Below is another way to view the list.
Blocks all engineers
Blocks health
Blocks customers
Blocks work/life balance
Blocks others from solving 1+3
Blocks others from merging
Blocks others from reviewing further
Blocks nobody
The core reason features are at the bottom is because feature development blocks nobody. I know this can be a bit controversial (often feature dev blocks new business), but take a look at this list from a teammate’s perspective. You can build features on your own time. Work best in the morning? Evening? At midnight? Great, go for it. New feature development is genuinely an individual contributor task (assuming all requirements are well defined, but that’s a whole other story).
Managing around blockers is absolutely critical to maximizing the effectiveness of your organization. Anyone who has read The Phoenix Project knows throughput for an org is limited by the biggest bottleneck. Synchronous work time (meetings or pair programming sessions) is precious, especially with how many time zones some companies are working across. The list above aligns the team on how they can spend their time within the day and creates a shared understanding around what is the most important.
Shared Ownership
Before rolling this list out, you need to have an open conversation with your team. You can’t solve a problem without recognizing that you have one. What I described above is only what has worked for me so far. Work with your team to come up with a list of how you want to order things.
Are you an early-stage company that is still playing catch up on features? Maybe features are a bit higher on the list. What if you have a more mature product where stability is critical? Then prioritize all bugs higher than features.
The list is just a starting point. What’s important is that the whole team understands the why behind the list’s order. Then everyone can manage their work in their own way (for example, I write code best in the morning and review code best in the afternoon) while still staying true to the company’s goals.
Conclusion
Hopefully, this article has helped you take a new view on how to prioritize work. Though I’ve geared this list towards engineering, you could easily modify it for any other team. This article should be a conversation starter between you and your team. What list will you come up with? I’d love to hear what it is.
If you’re interested in learning more about this article or my other offerings, send me a note at brian@connsulting.io or schedule a time to chat at https://calendly.com/connsulting.