There are some problems every company faces, no matter the size or industry. Issues like incorrectly assigned responsibilities and poor or overwhel...
For further actions, you may consider blocking this person and/or reporting abuse
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 😄
Great article!
just wow ♥️.
Nice article and good tips! Really all these problems seem unsolvable but you have a solution.
Thanks! That's a great insight!
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 :)
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.