I would assume there is no one thing to put a finger on. But there are some signs one can take a note of. Generally speaking, to name a few:
- The ability and willingness of the management to invest time and resources into development of proper work processes and infrustructure (imagine having to code without version control in a team)
- Understanding that things aren't always done the moment they appear to be done
- Realization that many things are done to lower the cognitive load exclusively (why do we have to spend 20 hours refactoring the thing if it already works?)
- Understanding why it is important to lower the cognitive load
- And dozens more
These are merely signs, though. One can put 'dnd' signs on doors, but what difference does that make if the same people who introduce the signs still disturb the people behind the doors whenever they feel like it. (no pun intended, couldn't word it better)
It comes down to understanding the nuances, and mutual respect, I think?
> It comes down to understanding the nuances, and mutual respect, I think?
I think that's a great summary.
Look out for companies that try to manage what they don't understand. It can lead to the 'car mechanic phenomenon'. I call it that because it's like the feeling some get when they get the bill from the car mechanic. They can't fix it themselves, so how do they know if someone's pulling one over on them?
100%. The companies and programs I've been a part of that failed, this is why. I've been meetings and made what to most engineers would be a truism, and been told by leaders that didn't have even a basic understanding of what we were trying to make "you don't know that, that's not true". In similar situations in successful management lead to "ok, I trust you" and then success. If an organization spends too much of its valuable resources on internal mistrust and convincing people who don't know, it's doomed.
- The ability and willingness of the management to invest time and resources into development of proper work processes and infrustructure (imagine having to code without version control in a team)
- Understanding that things aren't always done the moment they appear to be done
- Realization that many things are done to lower the cognitive load exclusively (why do we have to spend 20 hours refactoring the thing if it already works?)
- Understanding why it is important to lower the cognitive load
- And dozens more
These are merely signs, though. One can put 'dnd' signs on doors, but what difference does that make if the same people who introduce the signs still disturb the people behind the doors whenever they feel like it. (no pun intended, couldn't word it better)
It comes down to understanding the nuances, and mutual respect, I think?