Founder & CEO at Hecate
June 10, 2019#coaching #entrepreneur
So far I’ve spent around half of my career in developer roles and the other half in leadership roles, mostly based in Melbourne, Australia. Right now I’m trying to get a startup off the ground building tools to make engineering management easier, but before that I was VP of Engineering for the design marketplace 99designs. My other big role before that was as the first engineering manager for Envato. No one ever knows the name Envato, but they’re the company behind the huge Wordpress theme marketplace ThemeForest and a bunch of other products in adjacent spaces.
Unexpected and rough. I was promoted to manager to fill a void when the founding engineer at Envato left the company. I got the promotion by default: I’d been spending a fair slice of my working week coaching the two most recent hires, doing their code reviews and answering all their questions. The more senior engineer on the team was offered the role but didn’t want it. He then suggested giving me a try as I’d already been doing part of the job and if it didn’t work out they could always find someone else later.
No one in the company at the time had ever managed anyone else before, let alone run a company, from the CEO on down. The upside of the collective naivete was that we had a lot of freedom to experiment and try new things. We ended up on the leading edge of a lot of devops practices not out of any principled decisions but instead because there was no received wisdom to question and it was what felt natural to us.
The downside was that it was incredibly isolating without any concrete support in the role. There wasn’t any mentorship to be had within the company and because I was promoted young in a relatively conservative city I struggled to find a peer group outside of it. Instead I ended up relying on books to guide me through. I remember working my guts out during the day, then coming home for a second shift of reading just so I could try and get in front of the next day.
My day to day right now isn’t super interesting to the prospective manager so I’ll talk about my time at 99designs. Product and Engineering were split over two offices: San Francisco and Melbourne.
Generally my day would start at 6am. Somewhere in my mid twenties I switched from night owl to early bird and tend to wake up then without an alarm. I’d do a first pass through email and slack then. Early morning in Australia is roughly lunchtime on the US west coast so there’d be enough happening already for me to get a sense of the upcoming day.
First comms pass done, I’d do the standard morning routine of shower, breakfast, commute and hit the office sometime between 8 and 9, where I’d loiter around the coffee machine taking the temperature of the team. Mornings were meeting heavy, again to make the most of the time-zone overlap. These were usually strategy or resource related, looking a few months forward through the roadmap to ensure we had all our ducks in a row.
After lunch I’d do one or two 1:1 meetings. I know a lot of managers prefer to batch them to reduce context switching, but I find a full day of wall to wall meetings going deep on personal issues too draining. I found spreading them through the week worked better for me, especially as I could bring a consistent amount of emotional energy to each of my reports.
The rest of the afternoon was generally my alone time. Some days I’d squeeze in some coding. Others I’d be working on strategy documents or budgets. If I ever found myself at a loose end I’d cruise through GitHub getting a feel for what was going into our various codebases. I’d then knock off sometime between 4 and 6 depending on the depth of my todo list.
My motivation for the day to day all came from a sense of impact, of how much we were achieving as a team. It’s a really similar feeling to what motivated me as an engineer but it did take a long time to get it dialed in. The only feeling more exciting than how much you can achieve by making a computer do the work is when you get a bunch of people making a bunch of computers do the work.
The biggest challenge so far was having to essentially learn how to manage a second time after I’d come to understand the need for and value of diversity in tech. I had succeeded in my first management role but in far too narrow a way. My team was all male, mostly white and generally close to my own age. My specialty was in hiring and motivating people who already thought like me, which isn’t much of a specialty at all.
The next time I managed a team I vowed to do better. I’ll be forever envious of those who can naturally empathise with people from all walks of life. It took a lot of time to learn new habits and practices to be able to manage a broader variety of people. I could no longer lead with a very shallow interpretation of “do for them what I’d like done for me”.
At every point I received a promotion, and it doesn’t matter which one, I always thought “finally, I’ll be in the right room to finally fix everything”. I should have stopped being surprised after the first time, but discovering that I can’t actually fix everything with the new authority and awareness that a promotion would bring.
A lot of my drive climbing the ladder was to always try and solve the meta-problem. I wish this code was better, so i’ll try and make the team better, first by coaching, then by hiring. I want to hire better but I’m budget constrained, so now we need to increase revenue, and so on and so on until you’re pulling at the threads of the core business model.
There is no central place where everything can be set right - you need people working together at every level making the best of what’s in front of them to make things better.
In my very first programming role my manager said to me “You can make any mistake you like once. You’ll have my full support the first time you screw anything up. If you’re not making mistakes, you’re not learning, and if you’re repeating mistakes you aren’t either”.
I screwed up quite badly in that role a few times, and true to his word, I was shielded from any negative consequences - at least once at significant cost to him. But when I started coasting and coding recklessly and not learning from my mistakes - the shield was gone.
I’ve since said that exact same thing to nearly every engineer I’ve ever managed. I think it really nicely balances safety and responsibility. It’s not so much advice about being a manager, but it’s been the framework that helped me grow the most and also shaped the way I try and support my own teams.
The first thing I probe into when someone is seeking out the promotion is what their underlying motivation is. I’m always reminded of Gore Vidal’s quote “Any American who is prepared to run for president should automatically, by definition, be disqualified from ever doing so.”
The best managers I’ve known have always been somewhat reluctant. Not so opposed to the role that they neglect the core tasks, but neither so enamored with it that they get caught up in a power trip. If the idea of stepping up comes from a feeling of duty, to the people around you and the outcome of the work, then you’ll do well. If it’s something else, you’ll either do poorly or get burned out - or both.