Talk Isn't Cheap, Let's Collaborate
Seeing The Invisible Work
Today, I want to talk about a type of work that is often overlooked in real-world projects, which I refer to as "invisible work". This concept came up unexpectedly during a catch-up with my colleague Christopher.
For a long time, I've disapproved of people who always insist on holding meetings for every problem that arises. I firmly believed in the phrases "Talk is cheap, show me the code", and "Be the change you want to see in the world". Possibly due to my cultural background, many colleagues I've worked with share this mindset; whenever we face a problem, we immediately begin thinking about solutions and the approaches to implementing them.
We generally frown upon those who simply theorize without putting ideas into action. We're dismissive of those who just sit and philosophize, viewing them as lacking substance and focusing on impractical theories. Experienced individuals, in particular, should be able to drive problems independently and enact change.
I actually had a whole article It’s time to learn to unlearn discussed the “talking too much” problem.
However, if your team only comprises a handful of people, or if you're part of a start-up, the philosophy of "Talk is cheap, show me the code" might hold some validity. In this context, it makes more sense to use your time to solve problems rather than spending it on extensive discussions, especially when you are the one implementing the solution post-discussion. Hence, you often hear the phrase: "I could've finished the work in the time we spent talking."
But as development teams grow to hundreds or even thousands of members, "Talk is cheap" could turn into a misleading proposition. This isn't to undermine the importance of implementation—on the contrary, it's vital. The problem lies in overlooking the significance of the 'other type of work,' which involves planning what to do and how to do it. Unlike the concrete implementation process, this kind of work often becomes 'invisible' and is sometimes categorized as managerial overhead.
In large teams, if a developer's time is predominantly spent working independently, the overall efficiency may dramatically decrease. Suppose you're a developer who has identified a bug in the software. Rather than making the issue known and initiating a deep discussion, you choose to fix it immediately. This results in your efforts having a limited impact, restricted to a small sphere, which could be a waste from the organization's perspective, especially since the problem you encountered might also affect other teams and products.
In contrast, organizing the problem and making everyone aware of it before attempting to fix it might be a more beneficial approach. On the one hand, you could come across better solutions—another team or colleague might have a deeper insight into the problem, and a broad discussion could lead to a more comprehensive solution. On the other hand, even if the final solution is the one you proposed, the time spent on discussions may seem wasted on the surface. However, deeper analysis reveals significant benefits: firstly, you're making everyone aware of the issue (as identifying problems is often more crucial than solving them), and secondly, people learn about your approach to the problem, making you the go-to person when a similar problem arises. In essence, this discussion has a positive impact and should be encouraged.
In larger organizations, those who adhere to "Talk is cheap, show me the code" could end up causing inefficiency. This approach might be useful and necessary for small start-ups, but in larger teams or organizations, it's important to express your thoughts more often to maximize the impact. If you choose to work in silence, it could be detrimental not just for you, but for the entire team and organization.