Leading Projects – As a Software Engineer
Project management is the responsibility of a manager. Project “leadership” is the abdication of that responsibility to individual contributors.<p>This antipattern typically begins with the engineer being &quot;volun-told&quot;. The manager will frame leading a project as a growth opportunity, a chance to learn about people, the power to push the envelope in their org. Once the engineer submits, the manager will take a back-seat. They adopt the mindset of a passive referee: sitting on the sidelines as the engineer wrestles with the complexities of aligning people with technology. They&#x27;re here to &quot;guarantee the success of the project&quot;, they can&#x27;t get caught up in the little details!<p>Sure, the engineer will question why she or he is responsible for reading, writing, communicating, coding, and basically doing the manager&#x27;s job. But the manager will link to a litany of excuses, they&#x27;ll offer vague assurances, they&#x27;ll encourage the engineer to exercise more leadership!<p>Eventually, the engineer encounters an insurmountable obstacle: the structure of the organization. No amount of &quot;influence&quot; on behalf of the engineer will make this project succeed: the engineer needs authority to make substantive changes. The engineer dutifully raises this blocker to the manager, at which point, the manager says that the engineer need to be accountable for their own actions. The manager once claimed the engineer could “delegate upwards” but now the manager doesn’t sound happy.<p>At this point, the engineer realizes that they were &quot;empowered&quot; without power. That &quot;accountability&quot;, as the Dutch say, is responsibility minus authority.<p>The engineer finds a way for the project to &quot;succeed&quot; without the manager doing their job. The project achieves its objectives, the engineer (may) rise, and the org takes one step away from its goals. After a few hundred cycles across a few years, these unmanaged projects have created a product disassociated from reality, and therefore unusable.<p>The cycle ends with the engineer exiting: hopefully with a firmer understanding of power, and some useful technical skills for his or her next job. The manager, on the other hand, has let their technical and managerial skills atrophy. They are now semi-obligated to disseminate their rationalizations in books and blogs, in a bid to maintain  their current position within the org.<p>All in all, an unfortunate but natural pattern in the lifecycle of an organization.