3 ms·

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 pla

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.

MBCook 8y ago
I’d agree with the ‘combination’ option. I was the second person in the team, and the one who hired me was very good. I’d learned discipline at my first job where I worked on (and later solely owned/ran) two systems that handled money. If something went wrong you could trivially figure out how much your screw up just cost the company. So you had to be very careful, which was a great lesson. The people hired after me were generally quite good (to excellent), but even without much experience they came into an environment where production was very stable and we were careful to keep it that way. If the people weren’t good enough they wouldn’t have been capable of keeping up that standard. Some didn’t cut it. I really lucked into a lot of opportunity and fantastic lessons at my first jobs and had great bosses who did good mentoring. I know that’s hard/impossible to replicate on demand. I agree about negative value. Having seen so much through my jobs I can clearly see bad decisions that make the product less reliable being made, or at least horrible problems being ignored because customers aren’t complaining so let’s make tiny feature X instead. It seems like most people in the job just have no idea how to manage software development for the long term and can’t see past short term goals/ideas. That’s probably common across all types of projects/industries, I just wonder if it’s even worse in our industry.

MBCook 8y ago

I’d agree with the ‘combination’ option. I was the second person in the team, and the one who hired me was very good. I’d learned discipline at my first job where I worked on (and later solely owned/ran) two systems that handled money. If something went wrong you could trivially figure out how much your screw up just cost the company. So you had to be very careful, which was a great lesson. The people hired after me were generally quite good (to excellent), but even without much experience they came into an environment where production was very stable and we were careful to keep it that way. If the people weren’t good enough they wouldn’t have been capable of keeping up that standard. Some didn’t cut it. I really lucked into a lot of opportunity and fantastic lessons at my first jobs and had great bosses who did good mentoring. I know that’s hard/impossible to replicate on demand. I agree about negative value. Having seen so much through my jobs I can clearly see bad decisions that make the product less reliable being made, or at least horrible problems being ignored because customers aren’t complaining so let’s make tiny feature X instead. It seems like most people in the job just have no idea how to manage software development for the long term and can’t see past short term goals/ideas. That’s probably common across all types of projects/industries, I just wonder if it’s even worse in our industry.