What would you do in the first 90 days of an Engineering Manager role? — Step 3/3

In a previous post, I wrote about my survival plan for the first 90 days in a new role. The first step is to find the right problems to solve. The second step is to plan and execute appropriate solutions for those problems. The third and final step is to measure the results and iterate to get satisfying results.

The Lean Experiment Map, one of my favourite tools from Business School

Step 3: Measure the results and iterate

Testing proactively is the bread and butter of entrepreneurship. I know first hand that the most costly solution is the one that we build entirely before it’s needed.

So rather than spending all my 90 days writing strategies in isolation, I’d much prefer to work with my team and fellow managers to come up with ways to run and measure small experiments.

Set good goals and metrics

There is a lot of good literature about the art of setting good goals and metrics to go along. The most useful approach I found is to define them in a clear, actionable way.

Fuzzy goals are very dangerous for three reasons:

1. They are often not grounded in reality, either too ambitious or not ambitious enough.
   I’ve been in a company where, as a software engineer, I was made to perpetually feel “not good enough”, no matter how hard I worked at achieving my objectives. Later I found out that this was the company’s way to encourage people to prove themselves. It’s the kind of company I’ll never go back to. Wins, no matter how small, should be celebrated properly.

At Touco, we gave Tacos to everyone in the team for every small win.

1. They don’t tell you anything about where you are now and how hard you’re trying.
   In one occasion, someone from the business side took a quick look at my team’s goals and deemed them complacent. The lesson was that it’s unlikely for people to estimate well how hard things are, without doing them first. Having at least a starting point and an idea of how fast things are expected to move is very helpful.
2. They don’t set a reasonable timeframe to accomplish them by.

To avoid this sort of goals, I’d structure each to have five parts:

1. A target: What do we want to achieve?
2. A reason: Why do we want to achieve this goal?
3. A baseline: Where are we starting from today?
4. A trend: What are our current bearing and velocity?
5. A time frame: By when do we aim to accomplish this goal?

“We want to decrease the rendering time (p95) of the basket page to 300ms in order to drive up conversion and increase our Q3 revenue by 5%. This increase will enable the company to break-even and unlock a milestone for our next round of investment. In Q1 our users (p95) were waiting 400ms for the page to load and that time has increased to 600ms by Q2.”

To define good goals, especially in a larger organisation, I found best to work closely with other leads and managers, to align ourselves with the company’s strategy and share the set of metrics agreed with the teams. This is especially important because accomplishing a goal is rarely done in isolation. For example, decreasing the loading time is a shared goal between backend, frontend and design.

I like to keep these goals in a public space like a dedicated Slack channel or an internal wiki page. It’s also good to start a new planning session by reiterating the goals and the progress so far, to avoid surprises when it’s too late to make changes.

While many books and articles out there describe solid ways of doing all these things, I find that perhaps the hardest bit is maintaining good morale and high enthusiasm in the team during transitions. Good changes don’t happen overnight, so convincing everyone to have patience and resilience while keeping self-confidence up is essential.

The Design Thinking mindset, which describes five key behaviours, could come in handy.

1. Create confidence. As a leader, I’m expected to create the confidence that I have big ideas and the ability to act on them. Sometimes, this gets explained as “fake it ‘till you make it” but the point is that becoming good at fast experimentation is more effective than expecting to find the right solution the first time.
2. Learn from failure. I’d rather think about designing experiments that allow me to learn new things, and filter out things that don’t work.
3. Embrace ambiguity. Although hard, I’m giving myself permission to explore lots of different possibilities in the search for the right solution (which rarely presents itself as such).
4. Keep optimism and empathy at hand. Optimism with a healthy dose of realism has kept me going from a rougher start in life to where I’m now. I know that to find good solutions, I need exposure to different people, problems and time to process them.
5. Iterate, iterate, iterate. Involving the people I design the solution for and iterating over their feedback is the only way to validate my thinking.

Hopefully, this was useful to read. I’m keen to know how other peers felt about their first 90 days and what approaches they found to work well.

I also wrote about the importance of having Emotional Intelligence as a manager, for diversity, inclusion and better conflict management.