It occurred to me recently that while I’ve seen a ton of material intended for managers on how to lead, that audience represents only a small portion of the engineering workforce. The majority of us working in engineering fields are in non-management roles, striving for mastery, autonomy, and purpose in a technical capacity. While most of us work in organizations designed to support us in our growth, ultimately we each bear the responsibility for our own development and happiness, and knowing how to make use of (or work around) the organizational structure we operate within can be a challenge. Just as leadership in a technical organization is a skill, being managed is also a skill. As @mipsytipsy asked in her excellent “Management for Anarchists” thread: “Where are all the books on followership?” (Julia Evans’ “Help I Have a Manager” zine is a fantastic resource in this space, but I think we need more!)
Though the “I” in IC stands for “individual,” software engineering isn’t performed in isolation. We rely on our more experienced peers to learn from, our more junior peers to question our assumptions, our direct managers to provide us opportunities and resources to grow, our upper management to set a vision and resource our teams, and our cross-functional partners to help shape our roadmap based on business and customer needs. Each of these groups also has their own set of goals which sometimes conflict with ours, making our lives more difficult.
As an academic-turned-engineer with now several years of experience across companies at various stages of growth, learning how to operate successfully inside an organization presented a steep learning curve for me. This blog is meant to be a collection of strategies that I have found personally helpful for operating as part of an organization. While I hope for the content to be relevant to a wide range of engineers, it’s informed by my own unique set of experiences and as such may be inherently biased towards those at a middle level of seniority in a medium to large organization. I also recognize that the strategies I offer might not work for everyone, nor are they the only way to be successful.
Finally, one point of clarification: while this blog is intended as a resource that’s specifically for non-managers, that doesn’t mean that it’s for non-leaders. Leadership is a broad term and usually is a key part of a senior engineer’s role in some form, such as setting technical direction for the team, mentoring more junior teammates, or having autonomy to tackle larger and riskier problems. My hope is to make it easier for ICs to focus on whatever part of their role they value most.
Andrea Heyman 