When I wrote you the last time about the myth of multitasking, I talked about our attention limit having a value of only one cognitive task. Today, I want to double-click on that attention-demanding creative task and connect it to the quality of results.
In Mythical Man-Month book, Brooks talks about the importance of execution in software engineering. Much like in any other creative task (writing, painting, etc.), an idea has full of hidden flaws until the execution. Software engineers don’t realize the inconsistencies in their proposals before implementing or at least writing the approach down. Without the execution, the flaws in system design will never surface. The discrepancies in component design will only come out with the coding. It’s especially true with legacy systems. The majority of us work with codebases or projects we didn’t develop. We design new components that fit into systems we cannot 100% comprehend. That’s where I want to take Brook’s statement one step further. Multitasking conceals all the design flaws even deeper.
While reviewing our peer’s code, we remember one thing that needs to be done and jump to it. We fix a bug in a meeting; we refine the next ticket while listening to the all-hands meeting. A Product Manager asks for something urgent that needs to be done now. We pick up multiple tasks with the intention of gaining a more holistic view. With a high workload, it often looks like we have no time and no choice. That’s also what’s expected from experienced engineers, right? Join meetings, finish tasks, drive initiatives, mentor others, and do more simultaneously. Within all this absurdity, we try to move our focus from one component to another, jump from meeting to meeting, and have three-four tasks assigned to us that are currently “in progress.” But if our mind is everywhere, it’s actually nowhere.
“How can I do less while the business expects more from me?” I hear you say. Here is the misunderstanding: organizations want you to achieve more, not to do more. The more you do, the less you achieve. Not output, the outcome. You may finish a small thing here and there while listening to a meeting, but it can only be a small output while the actual outcome awaits.
We can differentiate the outcome from the output by looking at the results. In multitasking, you will definitely produce some work, so your output will be high. And that is the main confusion point. As the output is high, you’re inclined to assume you’re doing a great job. Only when we look at the results of outputs can we understand the impact you make.
If we forbid multitasking, you have to choose one task while the others await. This selection forces you to understand the expected result; hence the task that gives a better outcome precedes the tasks with minor impact. We see these effects only by looking with second-order thinking: instead of “I will do X, and Y will happen,” ask, “what will be the consequence of Y?” to think beyond. Ask yourself why that task matters and what would be the expected outcome. This strategy has another consequence we often overlook and sacrifice for speed: quality.
Multitasking lowers the quality of the work you produce. Software engineering demand understanding tiny details, seeing their effect, planning a solution, and ensuring that the solution works. Because of a high cognitive load, working with multiple contexts in parallel, and shallow focus, multitasking hits hard in every single step, resulting in bugs, poorly written and unmaintainable code, and piled-up technical debt that becomes clutter in the backlog as leftovers.
If we go back to Brook’s argument, the wrongly-gained holistic knowledge results in learning fewer details. That turns out to be missing the intricacies of bad design. The more parallel work you take, the greater the loss of quality on the finished product. While growing in careers, many folks make a mistake and take more stuff on them in parallel. It seems reasonable, but it’s not.
Within all the complexity Brooks discussed, we have no choice but to do things in order. When we stop and try to single-task, we begin to focus, increase quality and outcomes and start growing. It’s hard, true. And yes, it requires saying no and demands better stakeholder management. And that’s one of the reasons why software engineers are in high demand, and not everyone can do this job without dedicated training, focus, and discipline.
Until next time, Candost
P.S. What I’m doing now.
