- Toil: “Toil is the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” Google SRE Book
- Product Development: The process of deciding direction, scoping, building and launching products. For the purpose of this post - software products. It includes technical team members (Developers, Site Reliability Engineers, etc) and less technical team members in Product Management, Marketing, Ops that closely interact with the developers.
For a quick bit of background if you haven’t been following the Site Reliability Engineering trends (not a slight, there’s so much to keep track of these days!) - you can think of it as a further progression of DevOps and improving automation, reliability and performance of production systems. One of the key items that gets targeted in the SRE world is reducing toil through automation. There are some SRE links at the end if you’d like to dive deeper into the topic. Having an understanding of the mindsets should benefit your career if you’re in the software world and somehow came across this page.
There is an ample amount of “manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly” type work that bogs down product development teams. Asana shared in their S-1 filing that “Today, 60% of knowledge workers’ time is spent on work about work.” Most individual contributors trudging through this type of work think it’s just a required part of the job. We’ve spoken with product managers that think there’s no other way - “you just have to put in the hard work” is something we’ve heard countless times.
Leadership and Management often fall prey to thinking that toiling work is unavoidable - someone has to do it. Some even shield themselves from touching it - perhaps they had to do it previously, and now have the privilage of delegating the work. However, at the end of the day they need information to make strategic decisions. The process isn’t very resilient for the organizations and doesn’t scale well. It’s a never ending cycle that follows the cadence of quick feedback cycles of agile or frequent touch bases for longer term work.
- Within a team
- Up the management chain
- Across the organization to other teams
- Externally to customers
- Externally partners
- Often locked in 1:1 communication. Knowledge does not diffuse well across an organization.
Manifests itself in Emails, Chat messages, 5 minute meetings that actually last 30 minutes or more. Pulling other team members of task to get an answer. Often not visible to the organization as a whole, but is taxing on many team members.
The cycle time for answers here is generally the shortest and most distracting. You might receive a status request from the client success or sales team trying make a customer happy. Or the data science team on the hunt for when they will be unblocked by data integration. Or finally, a founder or executive trying to close a big contract. It’s hard for team members to be proactive here and they often get caught off guard.
UPS/FedEx style tracking numbers and links that can be proactively shared with stakeholders that automatically pull data from code repositories, other tooling and deployment environment metadata.
- Do we support X across our Web, iOS and Android Offerings
- How do we stack up against competitor Y in features A, B & C.
- Knowledge typically does not diffuse beyond product management org
Generally manifests itself in spreadsheets full of project mananagement tool links, red, yellow, green cells and unstructured data.
Compared to status updates, these requests often grant a little more heads up, but are often much more tedius, laborious and fraught with outdated information and errors. Can also occur ad-hoc from various parts of your organizations - “does the web app support X?”
We think teams should label their code bases against structured feature definitions. Doing so would allow teams to query against capabilities in their portfolio.
One Time use Presentations
- Roadmap presentations & progress against deliverables
- Gap analysis result deep dives
- Sprint review slide shows
This one depends on the culture of the organization.
Structuring Data for Status Updates and Gap Analysis will help automate the generation of presentations.
Creation and Updating of Tasks
- writing up tickets
- updating status updates between tools
- dragging tickets between swim lanes
- pulling tickets into sprints
We’re working towards a world where you do not purely update a status for work. Your work should update the status for you. Think about this for a minute - what if you just did the hard work and everything else was automated? The documentation, the status updates, the portfolio gap analysis, the organization of it all.
The outputs of these manual exercises are impossible to compare or measure over time against one another.
In 2020, teams shouldn’t be toiling away at quickly outdated or disposable Status Updates, Gap Analysis & Building Presentations. Data should flow from existing sources of truth (the code) which can be merged with other metadata to provide evergreen intelligence to organization. We can automate this.
Particularly over the last 10 years, product development culture has become more agile, and in doing so, less tangible, quantifiable or measurable. Yes, we can track conversion rates and usage cohorts and stats like never before, but there’s no objective measure of functionality existing or not. We’re working to fix that so you can have your cake and eat it too. We want you to spend more time taking to customers and diving deep into real problems, not busy work.
We are scratching the surface of what we think is possible, join us for the adventure. We’d love to hear your thoughts on this, join the discussion in the Twitter thread