Solutions to common engineering management problems — Part 1/2

Previously, I wrote a mini survival guide for the first 90 days in a new engineering management role.

In this two-part series, I’m looking at a few types of engineering management problems I faced and suggest some solutions I applied.

Here I’ll address scaling and prioritisation problems. Next, I’ll look at communication, team bonding and diversity problems.

Photo by Karla Hernandez on Unsplash

If you’re wondering why I’m qualified to give well-meaning advice, aside from being a tech lead, manager and technical founder, I have formal management training and I’m a certified Project Manager. I’m also part of the CTO Craft mentoring circles. I recommend their community for any aspiring or existing CTOs. It’s a great network with thousands of the best leaders in tech.

I group engineering management problems into the following categories:

• Scaling problems
• Prioritisation problems
• Communication problems
• Team bonding problems
• Team diversity problems

Scaling problems

Scaling problems come in many flavours: technical challenges, team size problems and hiring issues. I’ll leave the technical challenges to another post, to keep this one reasonably readable.

Team size problems

The industry recommendation is to have teams of six to eight engineers for each Engineering Manager (EM). Smaller teams have little redundancy, so a skilled manager knows to plan the capacity to compensate for time-off. Aside from capacity, I found, more than once, that a small team will have a rough start because there aren’t enough people to smooth away strong individual preferences. In most cases, time and mediation is the answer.

A short story. Once upon a time, I was hired in a small team where the existing engineers didn’t see eye to eye about what design pattern to choose for our new app. Shortly after I joined, the PM told me I somehow made the team a friendlier environment. I think she meant that I was able to mediate.

I applied one of my favourite techniques. I “fixed” people with free coffees and listened to them, individually, to figure out what was making them unhappy. They were (and still are!) brilliant senior engineers and wanted to improve our code in meaningful but different ways. Once everyone understood that we smoothed out our differences and became “The Dream Team”.

I did that instinctually, before any training. Later, I repeated the experience as an academic representative, and I was unexpectedly recognised and awarded. Touco offered me plenty of other occasions to apply it, so this is a working trialled and tested technique. If you want to know some more tips on allocentric conflict management, I wrote them here.

Tech startups tend to quickly explode in size after each significant funding round. To grow a new team, the best is to split an existing team, then add people to each. This way, the existing members convey the team’s agreed practices and uphold standards when onboarding new folks.

“We’re growing so quickly that every six months we’re a new company.” — someone at Uber

Adding new individuals to a team disrupts the team’s bonding process. This means that the manager needs to account for this bonding time (aside from other things like onboarding and training) and communicate it upstream. Not doing that will most likely result in questions like “We’ve just hired 5 more people, why isn’t the software delivery speeding up but slowing down?”.

I believe that, for more sustainable growth, companies should follow scaling phases with consolidation/gelling phases. This better maintains the culture and moves people from Survival Corner to Performance Mode (some stuff I learnt in Techstars).

Hiring problems

Every order of magnitude of engineers also needs a new layer of management. Managers need to be kept mentally sane as well.

“More engineers, more problems” — everyone in a startup

As I mentioned in my previous series, more engineers create more commits, more deployments, more load on the development tools, more defects and recalls, more incident management etc. etc.

Aside from these technical challenges, hiring also brings a huge overhead. Trained engineers and managers are now busy:

• sifting through applications
• creating and updating interview guides for all sort of new roles and levels
• interviewing new candidates
• onboarding, coaching and training the new engineers
• finding the right teams for the new joiners
• managing career ladders for the folks already in

Speaking about career progression in engineering and design, check out this brilliant tool called Progression.app created by an ex-colleague!

All this, while feature development and product improvements continue to run smoothly (or not so).

At Touco, I came in as the second co-founder. We grew from two to seven full-time permanent employees and an array of satellite contractors and freelancers from abroad and the UK. It might not seem much, but we didn't have a talent acquisition team to help. Everyone who joined came through our network.

I had all the past lessons to guide and scare me into planning the onboarding process a little bit. I did what I know best: document everything.

These titles are revisionary, but I think I’ll use them next time :)

• “How not to kill ourselves in the first week. Pull Requests best practices.”
• “How to make a smaller mess. Coding principles for front-end & back-end”
• “How to avoid the blaming game. QA your own work. Friends can help.”

It took me a few days but I wrote some initial “survival guides” then we continued to contribute to as a team.

Prioritisation problems

This group of problems is a personal pet peeve. I wrote about them as the first thing to look into. I learnt “from the trenches” that the lack of good prioritisation from the business and product first and the engineering management second leads to a world of pain.

I’m touching on two areas:

• problem discovery and selection
• setting good goals and metrics

Problem discovery and selection

Creating and applying good loops of Problem Discovery → Problem Selection → Solution Validation is hard and requires strong Product Management thinking.

I learnt this skill practically, in Zinc, Techstars and Touco, as well as formally, from Customer Development and Lean Startup. Acing that class resulted in, sadly but fortunately, eliminating many of my “great startup ideas” early on.

My daily dose of entertainment, monkeyuser.com

In a nutshell, I strongly believe that:

• Problem Discovery starts with the User’s jobs-to-be-done, pains and gains and the company’s mission/vision.
• Problem Selection accounts for the Company’s needs, like surviving the current round of investment, hitting the targets for the next round, competitor analysis, cost of testing the solution and solution ROI.
• Solution Validation is very tricky. I prefer experimentation over extensive analysis. Probably a professional defect, since writing code is usually about short feedback cycles — it works or it doesn’t. I found it’s good to have both.

In accelerators, they advise you to write a regular Newsletter and share it with a group of selected people. This way you get to dry-run your thinking and solutions, to see if it gets people excited and to clear out unknown gotchas. I still receive some of those newsletters from fellow founders and it’s lovely to see their progress.

Courtesy of productboard.com

Goals and metrics

As I wrote before, good goals are composed of 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?

Courtesy of S. Jackson, Data Science Manager at Facebook via towardsdatascience.com

I believe that many goals a manager deals with are about increasing team wellbeing and developer productivity. The latter means how well a team performs in all the steps that make up the typical software development cycle:

Code → Pull Requests → Ready commits → Deployments → Bugs → Code

We can assign a metric to measure the velocity of each transition in a given period of time:

• Coding rate: how many lines of code are changed
• Code review rate: how many Pull Requests (PRs) are reviewed
• Deployment rate: how many PRs are deployed to production
• Defect rate: how many incidents happen after deployments
• Recovery rate: how fast bugs are discovered, code reverted and production restored

I haven’t found a single tool that can do all the above in one, rather than manually pulling these metrics from lots of other tools like Git, Jira, New Relic, OpsGenie etc. If you know of one, let me know in a comment. If not, here’s a free startup idea 💡[Edit] I’ve recently stumbled upon LinearB, a software delivery intelligence platform, which comes close to what I had in mind. It’s worth a try.

Aside from software development goals, as managers and leaders, we need to seriously look at wellbeing and diversity problems. These are not “soft problems”, as they impact a company’s bottom line quite hard.

We need to set ourselves a new set of goals and metrics if we are to change the face of tech to a more diverse one. We should at least start listening to what the diverse side has to say.

Read here my thoughts on setting different goals and metrics for a meaningful impact on diversity and inclusiveness.

In the next post, I’ll discuss the communications, team bonding and diversity problems someone in an engineering leadership role will likely face.