There are some problems every company faces, no matter the size or industry. Issues like incorrectly assigned responsibilities and poor or overwhelming communication can slow teams down. In this article, we’ll explore three simple rules that can help you tackle these common challenges and get your organization on track.
In This Article
Single Responsibility
Every developer who knows about design patterns has heard of SOLID principles - five simple rules to follow when writing good code. It's an extremely popular subject, so popular that my article about SOLID principles in React is one of my most-read pieces, despite the abundance of similar content out there.
We're not going to examine these principles today, but we will briefly touch the first one, the S. The S in SOLID stands for Single Responsibility Principle, which states that one piece of code should have one and only one responsibility.
The reasoning behind this is quite simple. Managing two or more tasks at once is difficult - not for the computer, but for the developer. The code becomes harder to read, more challenging to test, more difficult to reuse, and the chances of introducing bugs increase.
The question isn't why we have this rule for code, rather, why companies don't embrace this principle when assigning roles to employees?
I'll say it again, it's not the computer that finds it cumbersome to run code that does multiple things simultaneously, it's the human brain which struggles to understand and maintain it.
In fact, this isn't specific to code. Generally, humans are terrible at multitasking. Period. For this reason, companies should not assign two or three different responsibilities to the same person. Each person should have one and only one job.
Are you a manager who recently assigned a new area of responsibility to your best and most reliable employee? Congratulations, you've just found the quickest way to make them fail.
With great responsibilities comes great meetings
Communication
A company can have everything figured out when it comes to roles, workloads, and required tasks, yet still fail miserably at delivering their products. The main reason for this is often a lack of or poor communication. Effective communication is critical for any company, regardless of its size.
There are many important aspects of communication at different levels. To keep this brief, we'll focus on two critical concepts:
- Pulling vs pushing information
- Avoiding single-person communication bottlenecks
Pulling vs Pushing Information
Information must be available. Without appropriate information, a team cannot work effectively, resulting in major time losses. However, how information is received matters significantly. This includes not only the medium (Slack, email, or in-person communication) but also whether the recipient requested the information or had it pushed to them.
There's no absolute right or wrong way to handle information flow - whether it should be pushed to someone or whether they should seek it themselves. When recipients aren't aware of information they need to know, the information holder must proactively share it. However, if people know how to access the information they need, there's no reason to push it to them.
This sounds simple, but it rarely works this way in practice. Most of us receive numerous irrelevant emails daily. Many of us are automatically assigned to email lists and Teams groups that don't concern us.
Meanwhile, product issues arise due to information gaps, and we blame others for not sharing essential information with us. We wonder why we weren't invited to meetings which were highly relevant for our work.
Though challenging, this problem has viable solutions. The most important step is communicating what information is available. Every company and team should have a central location where people can discover where to find specific information. This might include contact lists, collections of links, or an overview of available Slack channels.
Once people know where to find information, the approach should shift to an information subscription model. Everyone can subscribe to the information they deem necessary, and then as soon as there is new information on that topic, they will get notified about it.
There's one small but critical detail here which must be mentioned though - you must push that source of information to all employees, making sure they know how to find and use it. If they don't know that they will stand without any information at all.
Avoiding Single-Person Communication Bottlenecks
Large companies have many roles, and each role comes with specific responsibilities. Product Owners (POs), for example, are responsible for their products. While it's important that POs know everything about their products and stay informed about developments, this doesn't mean all product-related communication needs to flow through them.
POs interact with many stakeholders. In large organizations, they might communicate with function owners, system verification engineers, designers, and others. As developers, we should communicate directly with these stakeholders rather than routing everything through the PO.
If all information flowed through the PO, it would create a significant bottleneck. Just like with scaling hardware resources in production, communication should scale horizontally, not vertically - meaning it's better to have many direct conversations between team members than to funnel everything through a single person.
Dependency Elimination
A few years ago, I was convinced communication was the key to success for large companies. However, it turned out to be only half the key - the other half being dependency elimination.
I could continue discussing why communication is important, but the truth is, communication fails. Books about communication will tell you it's a shared responsibility between sender and receiver, with various disturbances in transmission. While this theory is true, communication will ultimately fail, often massively.
One reason for this failure, beyond miscommunication, is poor retention of information and inadequate follow-up actions. The learning pyramid, a visual model showing retention rates across different learning methods, illustrates this well.
Learning pyramid
As you can see, people remember only 5% of what they hear, meaning your colleague will forget 19 out of 20 things you tell them. They retain about 10% of what they read, so even when writing Slack messages you would need to send them each message ten times.
Combining hearing, reading, and visual elements improves retention somewhat. Group discussions (read: expensive meetings) can achieve 50% retention. However, since half the participants are likely checking their phones, the effective retention rate drops far below that.
See the pattern? Communication is essential but inefficient. There's only one way to avoid miscommunication, lost messages, and information that never reaches its destination: dependency elimination - the bulletproof way to avoid communication by removing the need for it entirely.
For developers who might have wondered why we've focused so much on human interaction, let's return to technical scenarios. Imagine if you:
- never had to request a feature from another team again
- never had to be blocked by another team's bug again
- never had to miss a delivery because of a failed PI planning
- never had to explain to other developers how they should implement APIs
These aren't merely communication issues - they're communication dependencies you should minimize or eliminate. After all, don't you want your API lean and efficient?
How To Eliminate Dependencies
"But Dennis, you can't just stop communicating and solve all issues, that would be absurd." Yes, it would. But you can minimize the need for communication.
A good architect thinks about this. They detect important data flows and ensure services communicate only when necessary, through simple, understandable channels, preferably based on subscriptions rather than pushing or periodic polling.
The same principle should apply to team and management structure. Unnecessary communication and dependencies between teams should be eliminated. In practice, this can be done in several ways:
- by moving responsibilities and products between teams
- by implementing appropriate team structures (cross-functional teams, silos, etc.)
- by ensuring teams are self-organized, taking responsiblity for work instead of asking others what to do
- by letting people subscribe to information they need, rather than overwhelming them with irrelevant information
- by having clear responsibilities so people know who should do what
- by ensuring each person has one and only one responsibility (reducing the amount of dependencies they can have)
Does your company have features blocked by other teams? Then the solution in the first bullet-point might be what you need, letting the team which is blocked taking ownership of the dependency which blocks them.
Are your testers overwhelmed because developers aren't testing their software adequately, causing bugs to bounce back and forth between development and testing teams? The second point about team structure might be your answer. After all, what testing team would be overwhelmed if there wasn't a separate team to report bugs to?
Bugs would still exist, but testers could verify them directly with greater knowledge about what they're testing. They wouldn't need to hunt for requirements to understand how each application should work. Just as you wouldn't want a developer working on dozens of applications, why expect that from a tester?
Although cross-functional and self-organized teams might sound similar, there's a difference in the meaning. A cross-functional team handles work which normally spans over multiple departments (development, testing, production monitoring etc.), while a self-organized team takes responsiblity to manage their own tasks rather than waiting for orders from managers.
By being a self-organized team, the communication and interaction to other parts of the company can be reduced, together with the benefit of building a very strong team which have control over their products.
Regarding the fourth point: how many of your emails truly interests you? How many Slack or Teams channels do you read thoroughly? Conversely, how many people actually read your messages in the general channel?
The reality is there's too much information, and people rightfully focus on what's relevant to their job. As discussed earlier, people should ideally search for information they need and subscribe to relevant updates. The only required communication should be explaining how to find this information.
Finally, the last two points about having clear responsibilities and only one responsible per person brings us back to where we started with the Single Responsibility Principle. Each person should have one clear job. Why? As discussed in the communication section, people become bottlenecks when handling too much information. Messages get stuck with them instead of reaching their intended recipients.
Reducing individual responsibilities reduces dependencies, ensuring information reaches its proper destination and allowing people to focus on what they were actually hired to do.
Top comments (14)
I've not heard these points put this way before; this article is extremely compelling and very resonant for me.
In my team (~30 people right now), I try to ensure that we align our objectives by forming groups to work on particular problems and then forming subgroups within the larger groups. We generally try to work on the principle that no one is an island, which means knowledge is actively created and shared between at least two people at every stage - sharing information with someone, anyone, makes it easier to communicate that information more widely if necessary. I'm going to reflect on the points you make here and see if we can extend our practices to make things more focused and non-dependent.
My first, gut-instinct response to "[team of] ~30 people right now" was - WOW, that's not a team! But I'm mistaken. Words depend on their definitions and what's a team for me might not be the same for others.
It seems you are taking the right steps to facilitate such a large group of people; I take note and if I ever fall in that position, will try something similar. Though, still, I think I'd refrain calling it a team. :)
Glad you liked it :) Your way of working makes sense.
It's a good point with the islands, especially with the "created and shared between at least two people part". The "created" word is important there.
I used to encourage knowledge sharing a lot before, people telling other teammates what they have done, but what I later realized was that it was ineffective and didn't actually work as well as I imagined. By instead involving more people in the actual work (the "creating") they can learn naturally by doing, which is way more effective than listening to what others have done.
This is a mind blowing article, thanks 🙏.. But mind us, that in most cases it's not always the fault of the employer who assigned these task to one particular seen to be perfect 'staff' ; but in most cases this so called 'I knows it all more than any of my colleagues staff' lobbies for these task and responsibilities just to gain "recognition" not knowing that the so called recognition is killing him/her slowly. I believe in Decentralizing every task and making it labor divisive for smooth runing of any organization where every individuals will have time to think, relax their brain, brain storm and come up with a meaningful conclusion for better decision making.
Great article. It's about general fault, rather than specific scenario, which is cool. Straight to the point.
I can add one more thing in "Avoiding Single-Person Communication Bottlenecks" section (purely by chance my brain shortened it to ASPCoBo, which sounds like some C# tool). If you read information, then no other people involved. But if you confuse to clearly answer what is right behavior for feature/bug/process/etc, then you write knowledge, which is more expensive operation (like programs 😅).
Great to hear you liked it :)
I do like your ASPCoBo abbreviation, should standardized 😄
Nice article and good tips! Really all these problems seem unsolvable but you have a solution.
Great article!
An interesting read, but please change the title, unsolvable problems cannot be solved, it's in the name
Glad you liked it :)
Let's say you have problem with a bug in a feature of your software, which you realize have there is no possible solution for. What you then can do, is to go to the customer to ask what their needs are, what issue your feature was supposed to solve.
Then you take the decision to delete the feature as a whole, and instead implementing another solution which solves the customers true need even better. Then you do have solved the problem. Not the bug, but the problem which was the reason to why you thought you had to solve the bug in the first place.
Now think about what this article says. You have a problem with communication not working well in your organization, and you realize that there is no possible way to solve communication, there will always be lost communication and misunderstandings - it's an unsolvable problem.
Then, what you do? You see, one way to solve the problem you have, is to eliminate the communication. That way, you did solve the problem you had with the unsolvable communication issues in your organization, although you never found a solution to how to handle communication effectively.
That's exactly what this article is about, so title should be pretty accurate :)
Thanks! That's a great insight!
Please let me know if you like this kind of content :)
Love it!
It's thoroughly refreshing to see something different than "20 open source tools EVERY developer MUST check out NOW !", or the umpteenth AI tools article (the omnipresent AI overload honestly makes me feel jaded these days, lol, as does the "listicles" epidemic) ...
This site (dev.to) is about software development, but software development is not just about "coding" - communication and organisation plays a BIG role in software projects.
So yeah ... more of this, please!
Thanks for positive feedback 😀 I agree that there are way too many articles about all the same thing everywhere. I like to post some unique stuff, but when deviating too much from the mainstream it will be noticed as severely decreased read count.
However, I'll be holding a lecture about soft skills later this month, so I will be posting another article with similar topic as this one around the end of month. Actually, topic is very much what you pointed out there about software development not only being code.