3 ms·

I find this a result of pervasive command and control structures which inevitably lead to low trust environment. Something breaks, so the manager naturally thi

I find this a result of pervasive command and control structures which inevitably lead to low trust environment. Something breaks, so the manager naturally thinks he must add a control that will prevent the person or a from ever being able to do it. Very soon nobody can do anything without approvals by managers so far removed from actual decision that they don't even know the names of components being subject to change. The change then must travel from the only people that know what the change is but are absolutely barred from ever seeing production environment to people that being so focused on operations don't have time to actually understand what the change is. Once you are being treated as untrustworthy it will show in the rest of your work. Why code correctly from the start when you are not deemed trustworthy to do it correctly and there is lengthy testing and approval process to make sure you are not going to bomb your company? The correct step is to recognize, that introducing more controls can very soon lead to low trust between employees which is self-fulfilling prophecy. When you are not allowed to do something because you are not deemed trustworthy to do something, then soon you have no experience and then this serves as a proof that the initial decision was correct.

thinkingkong 8y ago
Trust is important but if you trust people who arent capable of doing a job that trust is misplaced.
tensor 8y ago
On the flip side, it seems that many young devs think that they should be allowed to do anything they want, without oversight whatsoever. I don't know of any other industry where junior people have this sort of arrogance. Usually people recognize they are junior and work to both learn from and gain the trust of their seniors. In development land, the attitude is "seniors are old, useless, and outdated" and any form of oversight at all "removes trust." E.g. A young dev suggests building their own database. After being told politely that this is an enormous task full of seriously hard problems and that it's not feasible to try, they yell about their "ideas being shot down" and that the work environment "lacks psychological safety."
- lmilcin 8y ago
  That's generally true. What is important, though, is how the very young devs are molded the first time they come to an organization. I have long experience working for various enterprises. One outlier company I worked for is Intel. Intel or at least the organization I worked for seems to be aiming to hire almost exclusively fresh out of university just to be the first one to "mold" the young engineer. Young engineers are immediately treated as adults trusted with their projects. Managers (not all, but I would say majority) seems themselves as shepherds rather than commanders. They will ensure projects are assigned to engineers and that engineers create value and they will try to debug if there is any cause of concern but will not assume the typical "single point of contact, single point of decision and authority on everything" role seen in most corporations. This of not true of all managers at Intel but it was very striking to me when I joined the company with some 15 years of experience in dev under my belt. Junior engineers seem to adjust to this immediately and seem to genuinely try their best to do best and try to seek wisdom which there typically is a lot of in the close vicinity.
MBCook 8y ago
I’ve been in both situations. I really liked the high trust environment. We knew what we needed to do and we did it. It worked great. But I had really good people on my team. Some of the other teams weren’t like that, or had a very different definition of when something was ‘good enough’, and the results were predictable. I’ve also been in the ‘high control’ environment, and it’s hard to get anything done at more than a snail’s pace. It helps tamp down issues from people who need supervising (due to inexperience or quality) but it puts a very low cap on everyone. There is no way to prove yourself enough to change things much. End result is everything moves slow, including necessary fixes that would speed up development. Of the two I think the first one is far better, but you really have to be careful to get good people with the right attitude. I do think there are people who prefer the right controls because it absolves them of some responsibility.
- lmilcin 8y ago
  Now, the question is, were they good people because they were hired well and this enabled high-trust environment or were they good people because high-trust placed on them caused them to rise up to the responsibility? I personally think, with no experience yet to prove it, that it is a mix of both. Meaning, you need people capable enough to react to the trust placed on them (meaning, really, normal people) but then the trust placed on them causes them to further improve. I think most people react positively when given genuine trust, feedback, reward/punishment, encouragement. It is also my opinion that most dev managers bring NEGATIVE value and their teams would function better without them except when there is extreme disproportion in experience and the command/control manager can carry the team that is not really allowed to do any high-leverage tasks. These are most miserable teams I have observed in the past. This happens because most people get corrupt very quickly. Once they are promoted they suddenly get to think they must be better than their team and their decision must also be better than everybody else in the team and so they should be taking all decisions. The team feels powerless peons, stops feeling responsible for the project, morale sinks, new hires are immediately indoctrinated that this is how things work around here. This happens extremely quickly, in matter of days even, and requires much, much more experience to fix. Managers that are capable to understand and fix this are typically promoted further assuring development team stays miserable.

thinkingkong 8y ago

Trust is important but if you trust people who arent capable of doing a job that trust is misplaced.

tensor 8y ago

On the flip side, it seems that many young devs think that they should be allowed to do anything they want, without oversight whatsoever. I don't know of any other industry where junior people have this sort of arrogance. Usually people recognize they are junior and work to both learn from and gain the trust of their seniors. In development land, the attitude is "seniors are old, useless, and outdated" and any form of oversight at all "removes trust." E.g. A young dev suggests building their own database. After being told politely that this is an enormous task full of seriously hard problems and that it's not feasible to try, they yell about their "ideas being shot down" and that the work environment "lacks psychological safety."

lmilcin 8y ago
That's generally true. What is important, though, is how the very young devs are molded the first time they come to an organization. I have long experience working for various enterprises. One outlier company I worked for is Intel. Intel or at least the organization I worked for seems to be aiming to hire almost exclusively fresh out of university just to be the first one to "mold" the young engineer. Young engineers are immediately treated as adults trusted with their projects. Managers (not all, but I would say majority) seems themselves as shepherds rather than commanders. They will ensure projects are assigned to engineers and that engineers create value and they will try to debug if there is any cause of concern but will not assume the typical "single point of contact, single point of decision and authority on everything" role seen in most corporations. This of not true of all managers at Intel but it was very striking to me when I joined the company with some 15 years of experience in dev under my belt. Junior engineers seem to adjust to this immediately and seem to genuinely try their best to do best and try to seek wisdom which there typically is a lot of in the close vicinity.

MBCook 8y ago

I’ve been in both situations. I really liked the high trust environment. We knew what we needed to do and we did it. It worked great. But I had really good people on my team. Some of the other teams weren’t like that, or had a very different definition of when something was ‘good enough’, and the results were predictable. I’ve also been in the ‘high control’ environment, and it’s hard to get anything done at more than a snail’s pace. It helps tamp down issues from people who need supervising (due to inexperience or quality) but it puts a very low cap on everyone. There is no way to prove yourself enough to change things much. End result is everything moves slow, including necessary fixes that would speed up development. Of the two I think the first one is far better, but you really have to be careful to get good people with the right attitude. I do think there are people who prefer the right controls because it absolves them of some responsibility.

lmilcin 8y ago
Now, the question is, were they good people because they were hired well and this enabled high-trust environment or were they good people because high-trust placed on them caused them to rise up to the responsibility? I personally think, with no experience yet to prove it, that it is a mix of both. Meaning, you need people capable enough to react to the trust placed on them (meaning, really, normal people) but then the trust placed on them causes them to further improve. I think most people react positively when given genuine trust, feedback, reward/punishment, encouragement. It is also my opinion that most dev managers bring NEGATIVE value and their teams would function better without them except when there is extreme disproportion in experience and the command/control manager can carry the team that is not really allowed to do any high-leverage tasks. These are most miserable teams I have observed in the past. This happens because most people get corrupt very quickly. Once they are promoted they suddenly get to think they must be better than their team and their decision must also be better than everybody else in the team and so they should be taking all decisions. The team feels powerless peons, stops feeling responsible for the project, morale sinks, new hires are immediately indoctrinated that this is how things work around here. This happens extremely quickly, in matter of days even, and requires much, much more experience to fix. Managers that are capable to understand and fix this are typically promoted further assuring development team stays miserable.