Managing difficult software engineers
This article is depressing, because it evokes a simplistic and dismissive management-style that I have found to be quite common.<p>Rather I find that people develop workplace behaviors that are rational responses to what they can see from their vantage point, and most of the time they have the organization&#x27;s interests at heart, as well as their own, just as managers do. For example, <i>sometimes</i>, engineers procrastinate on releases and deliverables because they intuit negative consequences that will impact them more than others, once the release happens.<p>When workers are entrenched in workplace behaviors that are not aligned with the needs of the org as a whole, I believe it is important to start from a position that they have a good reason for behaving as they do. Then we walk them on the path from how they behave now, to how we agree they need to perform, by establishing a current routine that over time, shifts into a routine that is mutually aligned. It&#x27;s a two way street of learning, where also bottom-up issues are addressed along the way, and incorporated into how the team functions as a whole.<p>Low-competence managers like to oversimplify the work of getting stuff done, because they want to feel like they have the answers, but in a serious endeavor that has domain experts in the team, insight-discovery does not happen primarily top-down.