> Ask your team to perform tasks that resemble work. Common examples include presentations, diagrams, and ticket management. I'm as salty as the next guy, but in my experience it has been the sub-par employees who are the ones that don't do this. Ticket management is not busy work, it's a necessity for everyone to keep updated. Presentations and diagrams are tools to communicate. I can safely say that by far the most…
I say this because there always seems to be those who don't need this. And it's the ones who need this who never seem to produce as much or are able to solve the problems on their own.
So I ask. If you could hire people who need this "communication" or hire people who don't need the "communication" and they both can get the job done, why would you hire those that require time consuming processes.
Good teams don't need Jira, good teams don't need power points, good teams don't need all the hand holding. These are tools to include those who can't and often bring minimal usefulness to the table.
Poor communication is code for "I have no clue what I am doing and am going to blame others for why I am not useful, but I don't want to admit to others I have no clue what I am doing.". Next time you find your self thinking somebody is poorly communicating, try this in stead. Say "Hey, I don't know what I am doing, I am lost, where can I start? More often than not this "poor communicator" is going to be able to direct you to a task that will not only make you useful, but also not require much more than 5 minutes of exchange and as a result you will probably learn something that will make you more useful in the long run.
> in my experience it has been the sub-par employees who are the ones that don't do this.
To directly call this out, the sub-par are often the ones doing all this stuff, because they simply can't do the actual work. Sub-par is probably not fair, as a good manager will build a team with a few of these folks to tend the toil. So they are useful in a way.
Also you all can think back on the time that you hired somebody and they knew more than just about everybody about how the product works and should work within just a few weeks. This person clearly did not need the documentation, they simply read the code -- the code is the documentation -- and the quicker folks stop thinking like tis anything else other than a big manual the faster they will be able to learn new code bases and become useful. The constant translation between weird human social ideas of what is good communication and a solid structured communication such as code its an incredible waste of time.
Just remember, your job is to write code to tell a computer what to do, and if you can't also read that code to figure out what the program should do, you might be computer illiterate which makes you less valuable than somebody who can both write and read code in the same manner as the systems that will consume it.
If you have ever had somebody tell you "it's like you compile the code in your head" you will know what I am talking about.