What you call dysfunctional, I call poorly managed. A poorly managed engineer will go off and keep themselves busy with whatever seems useful. If that isn't useful and it isn't being corrected, it's a management failure. These engineers are actually doing their best and spending a lot of energy on your behalf. If only you could reap some value from that energy.
Here's a few wisdoms from somebody who has worked in startups, big corporate environments and research environments:
1) Good software is produced by individual craftsmen working together on a basis of mutual respect and inter dependent needs and requirements. Somebody needs X to do Y and collaborates with whomever to make sure X gets done so Y can progress. This is true in open source communities, in the research community and within corporate R&D organizations. These three worlds often cross over. Most good engineers will reward good stewardship with loyal service. They will stay and solve your biggest problems.
2) Hierarchical top down planning of good software evolution is impossible and tends to be enormously wasteful in terms of developer frustration, time spend communicating, and time spend communicated what was communicated to the right people. The larger the organization, the more dysfunctional things get.
3) Conway's law is a thing in big organizations; doubly so in multinational companies.
4) Big software organizations behave more like organic ecosystems than like an army.
5) What the business wants, what it asks for, and what it needs are three very different things. The bigger the organization, the less likely these three things are going to be aligned. In light of that, it's best to keep the scope of most projects small and to rotate people so that you spread knowledge around the organization.
6) Successful organizations figure out ways to make the most of what they have to achieve their goals. If life gives you lemons, make lemonade.
7) Successful organizations figure out ways to get the right team to deliver what they need. If your teams are delivering the wrong thing, maybe the team wasn't right or maybe you are asking them for the wrong thing entirely.
8) Poorly functioning organizations hire the wrong people for the wrong job and then fail to use their output to the best way possible. They compensate by hiring even more people. The shotgun approach to software engineering kind of works if you accept that 90+% of your stuff is close to useless. Brooks law is a thing as well.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What you call dysfunctional, I call poorly managed. A poorly managed engineer will go off and keep themselves busy with whatever seems useful. If that isn't useful and it isn't being corrected, it's a management failure. These engineers are actually doing their best and spending a lot of energy on your behalf. If only you could reap some value from that energy.
Here's a few wisdoms from somebody who has worked in startups, big corporate environments and research environments:
1) Good software is produced by individual craftsmen working together on a basis of mutual respect and inter dependent needs and requirements. Somebody needs X to do Y and collaborates with whomever to make sure X gets done so Y can progress. This is true in open source communities, in the research community and within corporate R&D organizations. These three worlds often cross over. Most good engineers will reward good stewardship with loyal service. They will stay and solve your biggest problems.
2) Hierarchical top down planning of good software evolution is impossible and tends to be enormously wasteful in terms of developer frustration, time spend communicating, and time spend communicated what was communicated to the right people. The larger the organization, the more dysfunctional things get.
3) Conway's law is a thing in big organizations; doubly so in multinational companies.
4) Big software organizations behave more like organic ecosystems than like an army.
5) What the business wants, what it asks for, and what it needs are three very different things. The bigger the organization, the less likely these three things are going to be aligned. In light of that, it's best to keep the scope of most projects small and to rotate people so that you spread knowledge around the organization.
6) Successful organizations figure out ways to make the most of what they have to achieve their goals. If life gives you lemons, make lemonade.
7) Successful organizations figure out ways to get the right team to deliver what they need. If your teams are delivering the wrong thing, maybe the team wasn't right or maybe you are asking them for the wrong thing entirely.
8) Poorly functioning organizations hire the wrong people for the wrong job and then fail to use their output to the best way possible. They compensate by hiring even more people. The shotgun approach to software engineering kind of works if you accept that 90+% of your stuff is close to useless. Brooks law is a thing as well.