I heard a term fairly recently, and I love it. That term is single-threaded. If you search for this term on the Internet you’ll mostly hear about it in the context of software process execution or CPU execution, where only one task or command is worked on at a time. But I’m not talking about computer processes, I’m talking about applying this idea to your work processes. The idea is to only have a single point of focus, and not get caught up in lots of context switching or distractions.
The term was explained to me in this context, about people and tasks and to-do lists, and I realized it was a good way to describe some things I’ve learned to do.
I’ve said it before, and I’ll say it again now (and I’ll probably say it again tomorrow), but I’m busy. My todo list is long, really long. But my previous stress came from not just the length of the todo list, it’s the fact that it never seemed to ever get shorter. I was never getting anything crossed off the list.
When I sat back and looked at how I worked during the day, I found myself trying to multitask and context switch so much I never made real progress on any one task. I would have a spreadsheet, a presentation slide deck, an IDE, my email, and about 10 web browser tabs open and I would be constantly shuffling between them. When I learned to become single-threaded in my todo list, I would pick one item and only work on that item until it was complete.
This took a lot of discipline because I was so tempted to flip over to another task, especially if I got an idea in the back of my head on that task. It was also stressful at first because it felt like I was letting those other important tasks fall further behind. But over time I realized that by focusing on a single task at a time I actually got that task done! And my to-do list started to get shorter instead of longer. My stress level also went down because once I got that single task done for the day, I could feel like the day was a success. Even if I didn’t get anything else done that day, at least I got that one task completed.
As I learned about the concept of single-threaded, I realized that this term also applies to my preferred method of software development lifecycles. I am a fan of short, immutable, goal-based Sprints. Every Sprint should have a singular goal, and that goal needs to be very concrete, in that the software or end-user can now do something that it couldn’t before. And I like Sprints to be immutable because a very common piece of feedback I received when I was a people manager was that people did not like having unclear or ever-changing priorities. By having an immutable Sprint, the developer can have clear priorities and not feel like they have to keep changing what they are working on. And lastly, Sprints are short to offset the immutability. If a customer or product owner wants to change priorities, then you can tell them they are more than welcome to do so…in the next Sprint, which is probably only a few days away at that point.
Single-Threaded Decision Maker
I heard a quote one time, I can’t remember where, but it went something like this:
“Nothing important was ever decided in a meeting of more than three people.”
It’s like that old joke about being designed by committee. Effective decisions are made when there is a clear decision-maker, and that person makes the decision. The role of everyone else is to provide data and information to the decision-maker and maybe give their opinions. So for example, the Product Owner in a Sprint Project is the single-threaded decision-maker for the priorities for a project. The developers and stakeholders can all provide their opinion, but ultimately the Product Owner decides what gets worked on. This (theoretically) speeds up the velocity of the decision making and also reduces the probability of competing priorities.
I really like this concept, this idea of being single-threaded, and have successfully applied it to several aspects of my work. I hope that this can give you some ideas on how to make your work more effective and successful as well.