Don't confuse status and impact
Some work has more impact than other work.
Examples of high-impact work include:
- Shipping features or bug fixes
- Optimizing repetitive, time-consuming processes
- Upskilling or coaching others
Examples of low-impact work include:
- Filling out a timesheet
- Writing release notes
- Jumping on a quick call
Some work generally has more status than other work. Status is harder to define than impact and varies from company to company.
General examples of high-status work include:
- Leadership and strategy
- Talking to customers
- Architecture
- ’Difficult’ engineering, like building complex features
General examples of low-status work include:
- Manual testing and QA
- Writing documentation
- Fetching coffee for someone more important
There is some correlation between high-impact work and high-status work, but it’s very far from perfect. Many ‘strategy sessions’ are high status but low impact. Sometimes fixing some super easy ‘gruntwork’ bug in a login flow has very high impact even though it’s assigned to an intern.
Maximizing your impact by ignoring status
If you’re looking to make an impact somewhere, this means you can often find ‘gold’ in low-status tasks. These are tasks that are important to do, but no one wants to do them because they believe it’s beneath them.
Some of the most effective senior people I know are not scared of low-status tasks. What looks like ‘manual QA testing’ that anyone with a checklist could do is actually often a lot more complicated than it seems on the surface. If the CEO of a company tests their signup flow, they’ll probably notice things that are wrong or suboptimal that generations of manual testers didn’t notice at all.
Technical documentation is another example of low-status, high-impact work. Even in the age of AI, many products have either reams and reams of ‘slop’ documentation, or the bare minimum bullet points that an engineer wrote because the ‘definition of done’ card had a ‘document’ checkbox.
Because technical writers are often paid less than engineers, it’s regarded as low-status work. But because technical documentation is how people find your product, how they form a first impression of it, what they use when they’re just getting started, and what they come back to when they have an advanced use case, having your senior ‘high-status’ people who have both a very good understanding of the product and of the customer work on this ‘menial’ task often gives you very good bang for buck. Or doing it yourself. (Or, shameless plug, hiring my agency ritza.co to do it for you.)