Some people create work. Some people solve work.
Hey, ChatGPT, given the following blog post, write it in longer form, providing plenty of examples of people in both groups, and how can one move from one group to another:
My frame of reference is startups and small multidisciplinary teams that operate with little red tape. Everyone’s expected to get stuff done, and move the business forward.
In this environment, I’ve noticed a trend amongst the people I’ve worked with:
Some people create work, some people solve work.
Some people create work. They’re the developer who takes an open issue, starts solving it, and creates two new PRs that others must thoroughly feedback, or argue against at the expense of their own tasks. They’re the solver who implements the MVP of a big new feature, resolving a critical business need in record speed, leaving the pieces for someone else to fix down the line. They’re the dev who’s constantly fixing the same problem. They multitask, keep a lot of things open and eventually finish half of them. They’re the new dev who must be reminded to not implement a new frontend state management solution, because consistency and reasons. They’re the PM who comes up with new ideas every other week, resulting in endless discussions.
Then there are people who solve work. Things get better when they are around. They know nothing worthwhile is easy, yet that excites them: if it would be easy, anyone would do it. They’re the dev who closes issues in such a way that the core problem is solved and doesn’t come back. They will go ahead and refactor a scheduling service because that extra week of work was needed to close what seemed to be a small “one hour” issue. Now it’s done. They’re the PM who solves work before it even reaches the developers, protecting them from political distractions. They’re the customer success agent who doesn’t ask permission to do what’s right for the customer. They’re the people who single-task — they get annoyed by unfinished projects, and ignore everything else until they get this big thing is off their plate for good. They prioritise according to business needs.
It may seem like it’s obvious who is in the “creates more work than solves” camp, but it’s often not. They might be the junior engineer who’s not improving despite repeated feedback, or they might be the staff engineer who’s happy to talk about architecture and suggest three ways to tackle a problem without guiding the team towards the best solution. They might even be the CEO who micromanages everything, leading to a lot of wasted effort. All create more work.
Whenever you talk to people who solve work, they bring peace and order. People who create work bounce things back to you, and ask you to lead the project of fixing their problems.
The kicker: someone’s ability to create vs solve work is not a boolean. It’s a sliding scale.
This year, be the one who solves work. As for your colleagues who create work, send them here for some good old fashioned reflection.
There are two types of people in the workplace: those who create work and those who solve work. In a startup or small team setting, where there is little bureaucracy and a focus on getting things done, these distinctions become especially apparent.
People who create work are often well-intentioned but can cause problems by generating more tasks for others to complete. For example, a developer who takes an open issue and resolves it, but also creates two new PRs that require feedback or debate, is creating work for their colleagues. Similarly, a project manager who comes up with new ideas on a regular basis may lead to endless discussions, causing more work for the team. A developer who multitasks, leaving multiple projects unfinished, or a new developer who introduces new solutions without considering consistency, can also create more work.
On the other hand, people who solve work bring peace and order to a team. These are the developers who find permanent solutions to problems, the project managers who handle issues before they reach the developers, and the customer success agents who prioritize the needs of the customer. They may spend extra time refactoring a service or prioritizing tasks based on business needs, but the end result is a more efficient and effective team.
It’s important to note that an individual’s ability to create or solve work is not a fixed characteristic. It can vary and change over time. For example, a junior engineer who is not improving despite feedback may create more work, but with effort and reflection, they can learn to solve work more effectively. Similarly, a CEO who micromanages may create more work, but with a shift in leadership style, they can become a problem-solver.
In conclusion, it’s important to strive to be a problem-solver in the workplace. If you find that you tend to create work for others, take time to reflect and try to shift your focus towards finding solutions rather than generating more tasks.
