I have been a technologist for well over a decade, working in roles such as software engineer, software architect, team lead, and most recently, CTO of a small startup.
While I’ve certainly had to deal with the more managerial sides of some of these roles, it’s fair to say that I’ve been decidedly on the Maker side of the Maker vs Manager equation.
Even as a CTO, my time and tolerance for politics and meetings has been fairly low.
It’s been a lifelong passion of mine to figure out just what exactly does it mean to be productive. Over the years, I’ve incessantly asked myself the question: what can I do to make the most of my time and add lasting value?
As a young and fairly junior software engineer, that question seemed like a fun one to answer. Beginning to understand the answer to it, though, has helped me immensely to make the leap forward with my career and grow my skillset1.
What follows are my observations on productivity. After countless conversations with individuals in the industry and creatives/makers in general, I believe that these observations apply to many, if not most, of us.
Deep Focus is Key: To produce my best work, I need long stretches of uninterrupted time.
The Cost of Context Switching: Interruptions aren’t just time-wasters. The mental effort to refocus after an interruption (the “switching cost”) can derail an entire day.
Urgency is Rare: The vast majority of interruptions are not urgent and could be handled asynchronously.
Misaligned Systems: Many workplaces unintentionally undermine productivity with chaotic open offices and tools that encourage constant communication (like Slack).
Why is observation #4 the case? It’s hard to know for sure.
One theory is that most of these tools and systems are chosen by the people in charge. These people, almost inevitably, fall into the Manager camp. They thrive on meetings, and can’t fathom why anyone would need quiet to get work done. They equate real time communication and meetings with “collaboration”. That makes anyone asking not to be interrupted the bad guy! Why would you not want to be collaborative and a team player?
Another theory is that we don’t have (or don’t know how to use) the right tools. These tools should, minimally, facilitate the following:
Visibility should be clear. At a glance, it should be obvious what everyone is working on. This provides managers or team leads with the necessary assurance that work is progressing well, eliminating the need for frequent status meetings or a barrage of “How’s the project coming along?” Slack messages.
Communication should be effective, allowing for the exchange of information and requests for help. Messages should be read and responded to without the need to interrupt the other person unless there is a truly urgent matter, which is often rare.
Attempts to tame our existing tools have been made. Many organizations have rules or best practices for using Slack. For instance, some companies clarify that immediate responses should not be expected when sending messages. While this usually helps, there’s a recurring observation that delays in responses on Slack can induce anxiety. It’s almost as if the tool itself is unfit for purpose, but that’s another complex issue we’ll not delve into right now!
So, here they are, my four observations about productivity. As mentioned earlier, they may not be easily achievable. However, understanding what works and what doesn’t, along with the conditions under which our brains function best, can make a significant difference.
Is the current state of work truly optimised for deep focus and uninterrupted creation? Let’s keep this conversation going. Let me know your thoughts on how we can better bridge the gap between how developers work best and how workplaces are often structured.
[1] I never did imagine how much more relevant the productivity question would become as our family grew. When you have small children, your available time becomes ever more limited and catching up after work hours is often not a viable option!
This article was first published on The Serverless Mindset.
---comments powered by Disqus