What Does a Software Engineering Director Do All Day
The job of an engineering director has always been somewhat opaque to me. I'm relieved to find that no golfing is involved.
Authenticity has to be at the core of everything you do as an engineering director. Without it, the job will squeeze the life out of you. I've seen this happen to plenty of people over the years - as soon as you "go along to get along" once, you do it twice, then before you know it the whole day is some strange subterfuge where you're playing a made-up character.
If someone says "there isn't really a typical day," it's a huge red flag. If an engineering leader can't model some semblance of normalcy, what hope do their employees have?
Here's how I structure mine.
Coffee and Three Things
I sit down with coffee, notebook, and pen. I write down tasks I believe to be "important" for the day, then look at each item and ask: "If I didn't do this today, how bad would the damage be?" If the damage is less than doing wrong by my people or losing significant money for the business, I cross it out. I do this ruthlessly until I get my list down to three items.
I flip to a fresh page and write these three items at the top with a small dot to the left of each. Even if a meteorite hits Earth, I will accomplish the three things on my list, making a small "x" through the corresponding dot when complete. I am undefeated in this pursuit.
The Meetings
There's a mostly-full roster of meetings every day, but the most important are 1:1s. I try my best to steer these toward career and leadership development instead of having such a tactical focus. There are separate meetings and channels to focus on the day-to-day of the job but this is an opportunity to develop the next generation of leaders, whether they be management focused or high-level IC focused.
It's a huge antipattern to turn these into status updates - you get some good results quick but then lose your best people. So important to focus these on the kinda stuff you don't get to talk about during all of the other meetings you're having for technical stuff. People first.
Status updates should primarily be done asynchronously. If you have a one-hour status meeting with four leaders, each will give about a 15-minute status update. That update is generally of high-value to the person who called the meeting. It's generally of lower value to the other three leader participants.
My status meetings are fast. Six participants giving updates across a 30 minute meeting is the norm. This has a bunch of positive effects:
Each participant comes prepared since they'll only have the floor for a couple of minutes
Nobody rambles or indulges in technical discussion that's completely irrelevant to the other attendees. If there needs to be a deeper discussion it's, "I'll tag up with [person] and [person] and we'll come back with multiple solutions."
Participants don't resent having a status meeting
Participants get enough context on what their peers are doing
Focus
I book off focus periods on my calendar and I treat them like meetings. These are only flexible if there is a genuine (actually genuine) emergency. Keeping these focus periods sacred is essential. The tendency as a leader is to get pulled into the day-to-day of everything. If you don't resist that pull, you'll diminish the greatest asset you bring to the table as an engineering director, which is your creativity.
I almost exclusively use these focus blocks for developing strategy. I don't mean sTrATeGy in the McKinsean superficial sense of the word. When I refer to strategy, I am talking about developing the way in which you will simultaneously advance the goals of the business while developing your workforce. The term "strategy" is massively overused to refer to some handwavy bullshit pie chart nonsense. It's not. Strategy is a human engineering problem that has more and less optimal solves. Just like in software architecture there are tradeoffs for every decision.
I take this part of my job very seriously. The best value I can provide the business is to develop and execute an excellent strategy.
Negotiate
This is probably my favorite part of the job. My father is a prolific salesman and this left a huge impression on me when I was growing up. I love negotiating. I won't really toot my horn about most of my abilities — I'm a good but not prolific engineer, I sometimes fumble on project management, and I can never tell if someone's joking or not — but I will say that I am both great at negotiating and I love doing it, what a blessing!
Those "tradeoffs" I mentioned above? It's my responsibility to ensure that those tradeoffs roll the right way. What's the right way? Depends on the situation. Again, just like in software engineering, sometimes the solution to a bottleneck is to get a more powerful computer. Other times, the solution is to spin up a bunch of tiny networked computers. It just depends on what the tradeoffs are given the situation.
I don't have enough time or mental bandwidth to make every decision in my department, no engineering director does. Instead of being the blocker on all decisions, an engineering director assumes responsibility for all decisions made. If a decision with a really bad outcome is made anywhere in my remit, it's my responsibility, even if it's not my fault.
Back to Authenticity
You can't fake any of this. Your people will see right through manufactured enthusiasm for status meetings or pretend focus time. If you're not genuinely invested in developing your team, optimizing for efficiency, and thinking strategically, don't bother. Find a different job. The eyes, Chico. They never lie.