Many titles are given to our role. I've been called Engineering Manager, Director of Engineering, Senior Director of Engineering and Vice President of Engineering - and when I interviewed at Amazon, they called me a Software Development Manager.
Regardless, I've found that companies think of this role in two very distinct ways:
- You need to architect, peer-review and code full-time
- You need to lead our software engineering department
Amazon and another startup I briefly worked at were very much the former - actually a Technical Team Lead role dressed up in a fancy title for recruiting purposes - where my more usual role has been the latter.
On this blog we'll focus on the bigger role, where you are expected to lead a department of software engineers, with all that entails. Read why I focus on non-coding Directors
As you'll read in the 30 day plan, there are a lot of different disciplines that you'll need to lead, manage or at a minimum oversee:
- Culture
- Engineering
- QA
- Support / Triage
- Recruiting
- HR
- Project management
- Product management
- Cross-team communication / politics
You won't be doing all this alone; I recommend that you form a team with your Lead Architect and Lead PM, as described in Helping Engineering teams work together
Servant Leadership
Although "Servant Leadership" was coined back in 1970 it seems to be a common mantra today, and for good reason.
Our role is not to use our power and manage by enforcing rules and mandates, but to give the power to the team, listen to them, coach them and enable a culture of trust, continuous reflection and improvement.
Our role is very simple - remove impediments, enable the team to produce results, and get the hell out of the way.
Simon Sinek has written some excellent books including one called Leaders Eat Last and has made many videos on the topic of Leadership. Here is one of my favorites that is very relevant to us.
You Are Not An Island
Being an Engineering Director is a lonely job in many ways. You're probably alone in your role at a small-medium company, or kept apart from others day-to-day in larger organizations.
You want to build relationships with others at the company and ultimately foster an open and honest culture where you can all Tell Them Everything, but this can be shocking to companies not used to honesty and candor.
Unless you founded a startup, you joined an existing company with existing politics and communication barriers. There are already pre-conceptions on their and your roles, and "how things are done here" that will take time (and trust) to overcome.
Finding a mentor outside the company can help you, and I've found tremendous value in being a part of a community of similar people.
As a full-time developer myself back in 2000, joining the ASP Insiders and Microsoft MVP community was invaluable. Not only did I find a place to ask questions and get trusted answers, but I met others like me, who shared my experiences.
I'm still a member today, and fast friends with many from those days, 15-20 years later. Together we've built trust in each other, sought advice from each other and grown together.
