<story><title>How to drive away your best engineers</title><url>https://blog.hulacorn.com/2021/09/08/how-to-drive-away-your-best-engineers/</url></story><parent_chain><item><author>23B1</author><text>Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company&amp;#x27;s hiring and resource management, and a perfect understanding of the software&amp;#x27;s requirements.&lt;p&gt;These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but anyone primarily responsible for &amp;#x27;labor&amp;#x27; vs. &amp;#x27;management&amp;#x27;.&lt;p&gt;The &amp;#x27;best engineers&amp;#x27; empathize with the perspective of &amp;#x27;management,&amp;#x27; that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.</text></item></parent_chain><comment><author>dasil003</author><text>Maybe it&amp;#x27;s because I&amp;#x27;ve always straddled the line between IC, EM and leadership roles, but in my mind engineers &lt;i&gt;are&lt;/i&gt; managers.  They are managers of software systems.  The software systems are producing some economic output just as human or animal labor does in other domains or historical contexts.  When you write code and deploy it to a production system, you are responsible for the behavior, cost and other implications of doing so.&lt;p&gt;Although I believe managing people is generally the harder of the two overall, managing software systems is uniquely demanding of being able to zoom into deep technical details and then back out to understand the big-picture implications and where different layers of abstraction may have failed.  To call oneself a senior software engineer I believe you need both the technical understanding as well as the big picture view of what business value your code produces.&lt;p&gt;Many software engineers don&amp;#x27;t want to think that way; they look to the Product Manager to tell them what to build, the QA Analyst to sign off on releases, the Ops Engineer to tell them what broke, and the Engineering Manager to prioritize their time.  And of course those asks do align with the job descriptions and are not wrong per se.  The problem is that the SWE is in a much better position to foresee the majority of problems, and can save the company as well as their team a tremendous amount of pain by trying on different hats and thinking at a higher level.  Not all company cultures make this possible, but IMHO it is the key to the highest performing teams.</text></comment>
<story><title>How to drive away your best engineers</title><url>https://blog.hulacorn.com/2021/09/08/how-to-drive-away-your-best-engineers/</url></story><parent_chain><item><author>23B1</author><text>Like many engineers, the author of this article assumes all engineers are ethical, and perfectly suited to the assigned task. The author also assumes unlimited budgets, perfect control over a company&amp;#x27;s hiring and resource management, and a perfect understanding of the software&amp;#x27;s requirements.&lt;p&gt;These are the same complaints I hear from inexperienced engineers over and over and over again – and not just engineers, but anyone primarily responsible for &amp;#x27;labor&amp;#x27; vs. &amp;#x27;management&amp;#x27;.&lt;p&gt;The &amp;#x27;best engineers&amp;#x27; empathize with the perspective of &amp;#x27;management,&amp;#x27; that running a company is probabilistic, and that managers, co-workers, and other departments – like finance, recruiting, product, and marketing – are also duty bound by challenging constraints often beyond their control.</text></item></parent_chain><comment><author>astura</author><text>This article could be a parody with how shockingly naive it is.&lt;p&gt;The purpose of work is to solve business problems, not personal amusement and self-actualization. Business problems exist in the real world and have significant constraints. Many people will be much happier if they understood this.</text></comment>