What would you do in the first 90 days of an Engineering Manager role? — Step 1/3
I had an interesting conversation with a friend on Monday, about the first 90 days of a new leadership role. I started with a few mental notes and ended with a written series by Friday. I wrote about leadership and empathy based on my experience at Touco and before. I’m curious to know how other peers in the industry relate to it.
If you’re wondering why I’m qualified to give well-meaning advice, aside from being a tech lead and manager in my many startup adventures, I have formal management training and I’m a certified Project Manager.
“Where’s the API documentation…for humans?” — J. Stainer
I find that the first 90 days of any new leadership role are both exciting and terrifying for the same three reasons.
Reason 1: Move the needle
I’d expect to become a net contributor of value to my new organisation.
Reason 2: Hit the ground running
I’d have to do that while getting to know my new organisation well enough to understand its current and upcoming challenges.
Reason 3: First impressions matter
I’d have to make my skill set known within the organisation, create relationships, build trust and earn the respect of my peers.
My 90-day plan has three simple steps, inspired by the “Build, Measure, Learn” of the Lean methodology. Initially, I wrote everything in one post but after some good feedback, I’ve decided to keep things readable. The first step is to identify the right problems to solve, the second is to plan and execute a solution and the third is to measure the results and iterate.
Step 1: Find the right problems to solve
1.1 Observe and listen to discover the most important problems to solve first.
It’s a given that often what people say and what they do is different. I find that active listening and direct observations are the best way to discover the real pain points. Hence, I’d start by getting to know my direct team as well as other peers. I’d ask their permission to shadow them for a few days to notice their biggest challenges and how they’re currently solving those.
1.2 Clarify the vision and the company values from the senior leadership.
I’d first clarify the vision of the product and the company values from diverse peers, engineers, product managers, marketing, HR and even the CEO, if possible.
A great way to test how well the vision and values permeate all the levels of the company is to ask at least ten different people what their company stands for.
This is a clear indicator of whether the “sales pitch” is clear and consistent or there are misalignments and miscommunications.
I found that often companies struggle to keep an active communication channel between Product and Engineering. As a result, the biggest ‘Why’s of each remain obscure. For instance, Engineering might not understand why Product has chosen a particular quarterly objective. Or perhaps Product doesn’t have a clear understanding of why a technical solution can deliver great gains with less effort, much better than another.
On the topic of communication, I’d also like to bust a self-perpetuating myth, that engineers are not good communicators. In fact, I’d say most engineers spend 30% of their time actually coding and 70% designing and communicating the solution.
1.3 Collect a list of problems sorted by cost and urgency
I could get into a team that’s under a great deal of pressure from tight deadlines. This potentially indicates lots of important problems to solve. I found that in these pressure-cooking cases, focusing on some quick, short-term wins helps relieve the pressure, offers a sense of immediate accomplishment that raises morale and kickstarts a new cycle of ‘can do’ attitude.
I’d expect most companies to have this in the form of a Backlog that is periodically refined and prioritised. Still, I might find it interesting to dig a little to either confirm or add to that Backlog.
For example, I’d ask a few engineers what is the one thing they wish they could spend a day fixing, then giving them the day to do it. This not only establishes trust but also sets a tone of delivery from the start.
Since the Backlog is always a work-in-progress, I’d look to prioritise problems in the following order:
1. Problems that affect users directly
Users don’t buy products because they want to give money to the company but because the product is a means to an end. If the company fails to deliver that value to its users, it becomes hard to justify its existence.
In terms of technical challenges, slow loading times, wrong/missing features and high error rates that impact the user experience are usually the ‘Hair on fire’s to look at.
2. Problems that impact the team’s wellbeing
One of the biggest problems I’ve struggled with is the amount of context-switching engineering teams are exposed to. This is a clear sign of abnormal communication, for example, having too many channels to request changes or meaningless meetings.
If I had a magic sorting hat, I’d class meetings into either “do or else die” or “not at all”.
Engineers dislike being dragged into ad-hoc meetings with either a flimsy or a humongous agenda, where folks don’t have the time to prepare. Worst of all is when those end without clear actions or decisions. I found that involving the team in agreeing on the structure and cadence of the meetings leads to best results.
At Touco, we went through several iterations of defining the right meetings and cadence, to refine the backlog, to plan sprints, retrospectives, team get-togethers, All Hands etc. All these decisions were written up in a collaborative document then explained and shared with everyone in our team.
We ended up with “No Meetings Fridays” for everyone, to alleviate the video conference overuse triggered by the first lockdown, and “Internal Meetings Mondays” for our exec team to keep us focused.
During the first lockdown, we also pioneered a “Walk and Talk” style of meeting, for both exec and team 1:1s. Encouraging people to go for a short walk while talking on the phone without video helped alleviate stress and promote a healthy lifestyle. I had previously trialled a version of it with fellow founders, as a park-run challenge to meet, jog and discuss startups. More recently, my husband has also rolled out this technique to his teams, which makes me confident that it’s a good thing for remote teams.
3. Important longer-term problems
I can think of many good problems to solve, for example, lack of visibility in the developer community, lack of diversity in hiring, lack of training and coaching programs, lack of clear career ladders etc. All of these require long-term investment from the company.
For these, I’d think about writing up a series of Strategy and Vision documents to outline how we’re going to approach them.
A Strategy is a grounded document for a specific challenge, which explains the trade-offs and actions to be taken to address that challenge. To avoid the classic big initiatives which turn into “really busy 12 months delivering nothing useful yet”, I’d break them down into independently deliverable chunks which bring value sooner and give everyone a sense of moving forward.
A Vision document is a more aspirational write-up, enabling individuals who don’t work closely together to make decisions that fit together purposefully. I’d focus particularly on explaining the “Why”s of strategic directions in all areas of the organisation that contribute to that vision. This is why I find it important to build cross-functional relationships from early on in the role.
Versioned documents like this can become the breadcrumbs that help us trace (and debug) the decision-making process leading to the current company’s priorities, engineering culture and values.
Continue to Step 2 — Plan the appropriate solution.
