I have been an engineering director for 14 months now. At the beginning of this year I wrote down my thoughts after 6 months on the job. This note is an addendum to that.
Effectiveness is a muscle you build (and keep)
In my last note I mentioned how hard I had to work to keep up with the demand of this new role. What's changed is right now I literally never think about it. I work at 100% focus from 9 to 6 every day by default, on autopilot.
Being effective is like going to the gym. Painful to build the muscle in the beginning, but once you've built them, maintaining them is relatively pain free, as long as you keep up the workout.
Only A players in your leadership teamIn my last note I mentioned "Value first, aptitude second" as a performance management principle. And I described how between 2 performance problems, I quickly let one with "value" problem go, and "managed to turn the other one around".
Well, a short while ago I ended up letting that positive example leave the company as well.
This is perhaps the most valuable, but also most expensive lesson I learned in past 6 months: you really, really cannot afford to have B players on your leadership team.
The standard you accept is the standard you set. I remember defending this person's performance 6 months ago saying "as a company we should be ok to have folks consistently meeting expectations, albeitly not exceeding much". That was wrong. At leadership level, you only want A players that are constantly striving to exceed and do better. Because this is the group that actually propels the company forward. Having B players will stagnate the company.
Do not procrastinate in fixing people mistakesA corollary to the above is always be swift in fixing people mistakes. If I were to be honest with myself, I probably have known that this is an unfixable performance problem for 6 months already. Yet I continue to procrastinate, and pulled the trigger way too late.
This caused multiple damages: to the individual it was a stressful prolonged 12 months (and deep down I believe they understood it was probably not the right place for them either); for the teams under the individual, they were doing "okay", but just that, "okay". I lost 12 months of opportunity cost of having much better run teams.
You spend 50+% time in your first team, which is NOT the org you directly lead.Your first team is the team of your peers, in my case, it's the team of all engineering directors in the company.
For a while I made the mistake of exclusively focusing on my own domain, thinking that is my primary responsibility, and was fairly passive in the ED discussions (sometimes I even think "gee we wasted so much time bantering on unimportant things").
I forgot what triggered this -- but one day I realised my first team is actually the ED group, not my own reporting line. And my first team actually should be where I spend more energy and effort on.
It actually makes perfect sense: one of the criteria of being a good senior leader is whether you can set up highly functional, self-sustaining organisations; which frees you up to contribute more widely outside of your primary scope.
And to enable that, you really need A players in your own leadership team. My mistake was having B players, which then tied me down in my own organisation, which then limited my energy to do more.
Hold your XFN partners accountableOne day I was complaining to my manager how I had to verify every xfn team's work: from regulatory team's writing quality, to double checking data team's output; and how I'm unsatisfied with the quality and often have to find ways to redo them myself.
My manager said: everyone's outsourcing their correctness check to you. You should send critical feedback.
I was initially taken aback. This exposed a long standing weakness of mine: while I'm generally good at giving my own teams constructive feedback, I have never felt super comfortable giving my xfn partner teams constructive feedback.
But my manager is right: as an accountable executive of my area, I need to hold my xfn partners accountable. Not doing so is enabling B player performance, and again, that's only going to hurt the business.
I went ahead and had multiple feedback conversations with those teams. They were definitely not comfortable to do -- especially as I've never done it, initially everyone's almost a bit shocked as they all thought they were doing a great job. But after the initial awkwardness, I'm now seeing the fruit of that effort as everyone started upping their game.
(It wasn't all roses: there were a few "burned bridges" and I believe I also hurt someone's feeling pretty bad that it probably contributed to them leaving. But I think I still did the right thing and can finally actually count on my xfn partners.)
Embrace ambiguity and long term orchestrationI have always been very comfortable working on a concrete direction, and have historically shied away from "vague" work such as shaping up culture, or running large scale programs that are hard to define success criteria for.
6 months ago I was given a really vague problem of "transforming the engineering organisation to be global first", and frankly I had no idea where even to start in the beginning. Asking my manager did not give me much to work with either (looking back I think what happened is at this level or above, no one would have a sure answer to a problem like this, and everyone would end up approaching it in their unique way).
I ended up trying to breakdown the problem from first principles -- there is organisational change, and there is technical change. For organisational change I talked to a few peer companies and wrote down my thoughts; for technical change I enlisted the help of staff+ engineers. Together we defined multiple workstreams and have regular checkins.
The organisational principle is yet to be executed and proven; but I was pleasantly surprised at how the technical side turned out: initially it was a bit awkward, and I had to rally everyone really hard to do some real work (as everyone technically has a full time job already). But now after 6 months, all the workstreams are happily on track, and this in turn has motivated everyone involved to invest more. I am pretty proud of how it has gone so far.
The lesson learned here is really a simple, "just do it". Don't shy away from vague problems, and you only learn and gain experience points by actually attempting to do it.