// HACKER NEWS — CYBERSECURITY
A Staff Engineer's Guide to Inventing Work
Platform teams are engineering-led rather than product-led. There is almost never a product manager handing you a roadmap, no revenue line to follow, and no market to lose. This means that work does not exist unless an engineer invents it. The continuous struggle is to find ways to increase the value our platform provides to the users of the system. A big part of a staff engineer’s job in a platform team is to figure out what the team should build next - I like to call that “inventing work”. Thankfully, the signals that help us to invent work are already out there, and they arrive from four directions - from the systems, from the users, from your organization, and from the industry. What follows is a guide to reading each of them.
Crashes and their associated postmortems, when done right, are clear signals that tell you what to fix, or what to replace. It is rare for postmortems to point to a new thing to build, but sometimes that does happen if you pay close attention to how users were impacted by crashes, or how they made their processes work while your team fixed a long-running crash. Identifying patterns across postmortems is something teams rarely do as a practice because it is a sporadic source of patterns; make sure you are not missing the big picture.
Crash-led discovery has a major drawback: it biases the team towards the loudest and the most recent failures, not the largest opportunity. Also, it is a maximally lagging indicator.
Cost, in terms of dollars, is an obvious one. The cloud bill makes up for your lack of a revenue north star. But don’t stop there; go beyond optimizing the database query, or investigating how to cut inter-VPC traffic costs. Check the P/L for your business unit if it’s available, or your team’s vendor contracts & cloud bill line-items, or ask someone who has access or knowledge of the cost centers. For each cost center, understand how it benefits your team to “outsource” that function, and what it would mean to pull it into your team’s scope. This investigation also works in the other direction: things in scope that should be farmed out to a vendor, a cloud offering, or another team. The core lesson here is: buy-versus-build is NOT a one-time decision; you are allowed to revisit it as scope, team membership, technology and markets shift.
This is the other cost - invisible to many, sometimes including the ones who handle the toil work. Every team has toil, and it is almost never prioritized. But you already knew this one, so I won’t spend more words to say that toil is an important signal that there is work waiting to be discovered. The trap: your toil is not your users’ toil; fixing the former improves unit economics whereas fixing the latter improves user experience.
I have argued in the past that captive users “do not have the best view of the ideal state of tooling”, and that “over-reliance on user interviews is a bane to platform product management”. Essentially, what I am saying is that if you ask people what they want, they will say faster horses. I continue to believe this is true, but that is no excuse not to talk to your users. Continuous discovery is having an ongoing conversation with your users:
In short, user interviews should stay committed to jointly understanding the problem space. Solution space design is a matter for another forum.
This is my favorite heuristic, and I have talked about it over and again in other places. There’s a serendipitous property that some platforms possess: users press them into service for use-cases they were never designed to serve. You should spend time to understand why users would rather use your platform to solve their problem instead of alternatives (if any), even though it was never designed for solving that problem. Treat overloaded use-cases as prototypes your users built for you, and figure out which of those are worth assimilating. The litmus-check for assimilation is simple: who else among your users has the same problem?
Overload