dein.fr

This is my take on an engineering manager’s priorities at a hyper-growth startup. I quite often forget about them – it turns out a task’s engagingness not always correlates with its importance… Having such a framework does help making tradeoff.

1. Growing the team

The first and foremost priority should be to grow the team. The problem with shipping features fast is that it’s a vicious circle: the faster you ship, the slower you get because you have to maintain existing product and features. You can only hire your way out, growing the team by hiring. This way you can (1) take on more projects (2) better balance the maintenance duties across the team.

It also involves making sure current team member grow in their career and skills. For people who love teaching and mentoring, being in this position is a blessing… For example, in my biweekly one-and-one, I try to avoid talking about current projects and prefer to focus about the mentoring part, because I feel like this is where I can deliver more value to engineers and the company. Our team also has weekly brown bags where somebody teaches us about a specific topic (concurrency in UNIX-like OSes, CPython datastructures, profiling Python code, etc.). It provides a great place for charging our mental batteries: people love to teach and to learn! As an engineering manager, your role is just to provide the environment for this to take place.

2. Maintaining a vision

I’ve always been convinced that a good product is made of 1% inspiration and 99% perspiration, to paraphrase Thomas Edison. That being said, as an engineering manager you have to take the time to think about the vision. Making sure it is shared within the team and trusting your engineers to make sound decisions is much more efficient and powerful than micromanaging.

I particularly like two books’ take on this topic: Guy Kawasaki’s Reality Check and Patrick M. Lencioni’s The Advantage: Why Organizational Health Trumps Everything Else In Business. The strategy is basically (1) to make it as clear as possible (2) to overcommunicate it (pedagogy through repetition). Maintaining the vision (with the help of product managers) helps make sure engineering time is fully leveraged to achieve something big.

Engineering managers also need to spend time aligning their team’s vision with company priorities that can be changing pretty rapidly.

3. Managing projects

Things move very fast in a hyper-growth company, leaving a lot of room for miscommunication and wasted energy. A project manager’s role is basically to keep the ball rolling, spending their time unblocking people by maintaining a constant flow of communication. This is vital for complex, cross-functional projects where interdependencies need to be carefully thought of so that there’s no duplicated effort.

Because engineering managers keep track of current projects and interact with other teams, they are uniquely positioned to provide this context to existing projects, discovering and leveraging synergies.

4. Organizing

The basic premise behind the engineering manager role is that having a hierarchical organization is more efficient than having a free-for-all anarchy. I think they should also be thinking about the team’s internal organization. Should you create subteams to support the business’ needs? Should you experiment with new roles to make the team more efficient?

This is even more the case with hyper-growth startups, where the uninterrupted flow of feature requests and bug reports can be quite disruptive. We experimented with having a rolling support engineer who would be fixing the bugs so that other people can focus on their project. This way people get regularly exposed to the overall codebase – something that can hopefully inform their project’s implementation details as well.

5. Coding

As I said in my previous article Learnings from six months as a first-time engineering manager, I think that managers should keep on coding. This is the best way to lead by example. For instance, if you have troubles convincing other engineers that writing tests is valuable, then make sure to write some when working on a fix, showing why and how that made your more efficient.

Picture from Paul Falardeau