What would you do in the first 90 days of an Engineering Manager role? — Step 2/3
I wrote about my survival plan for the first 90 days in a new role in a previous post. The first step is to find the right problems to solve. The second step is to plan and execute a solution.
Step 2: Plan and execute a solution
The first step is about classifying and prioritising the problems to solve. A happy, motivated team produces sustainable, high-quality work and can solve most technical problems. I’ll focus here on problems that impact the team’s wellbeing since my strong belief is that teams can’t solve problems well if they don’t have the capacity. Either that bandwidth is misused by context switching or conflicts suck up some of it.
First, it’s good to assess the stage of wellness and motivation the team is currently in. I found several ways of classifying team stages, looking at interpersonal relationships and productivity.
From a psychological point of view
Tuckman describes the behaviours of team formation in terms of Forming, Storming, Norming and Performing. Each stage has a particular focus: facts, emotions, values and actions, and each requires different handling.
From a managerial point of view
The thing to look at is the connection between learning a complex project and remaining connected and motivated.
In stage one, people join the company but are not familiar with the project they will work on. Their level of enthusiasm is high, and they have an ‘I can do this’ mentality.
In stage two, they are still unfamiliar with a project’s nuts and bolts but quickly become disillusioned as they struggle with their tasks.
In stage three, folks start to understand the project and have clarity of purpose, which leads to enthusiasm levels picking up again as they start making a significant contribution.
The fourth stage is when they know the project well but become disconnected and feel they are not learning anything new.
As a manager, I’d have to shift gears between hands-off in stage one and three and hands-on in stage two and four, offer coaching and direction, reshape the scope of work and responsibilities, or assign folks to a new project.
From a software delivery point of view
I found an interesting classification in a book called An Elegant Puzzle which describes functional stages in massive companies like Uber.
Falling behind
A team could be “falling behind” for many reasons, most often bad scoping/planning, bad processes or lack of direction. Sometimes there‘s a genuine need for more specialised resources, for example, if a company is looking to deliver a Machine Learning project, but there’s not enough expertise in-house. One solution is to make room for people to learn new things and pull folks from other teams. While I’m a big fan of the first approach, I prefer to hire new talent rather than temporarily disrupting well-functioning teams which have already gelled and are productive.
More engineers, more problems. More deployments, more strain on the tools, more line management.
Hiring is not the Holy Grail and often causes a dip in productivity as engineers and managers now spend their time interviewing and training new joiners, which can take weeks to months, depending on how straight the hiring pipelines are.
Treading water
A team is “treading water” when they are consistently delivering features. Prioritising features to quickly launch and iterate leads to an accumulation of technical debt. It can get so bad that the only way forward is through massive rewrites and several migrations from old systems and coding practices to new ones. I’m yet to accept the “traditional wisdom” that this a necessary evil of all early-stage companies. I’ve seen cases where start-ups have taken a more enlightened route from the start without burning through their cash.
The best solution I’ve applied is to incorporate paying the technical debt as soon as features pass user validation and become permanent dwellers of the product. For example, I’d start with one sprint dedicated to bug fixing and maintenance for every two or three feature sprints.
Repaying technical debt
In larger scale-ups, teams can stay in the “repaying debt” phase for longer. New architecture groups are formed or brought in to guide large migrations from legacy systems to new platforms, and new specialised site reliability teams are formed for ongoing maintenance. I’ve been in a company placed under a “feature lockdown” while these things were happening. For the business side, this sort of work starts to look like a black box, so I’d strive to find time for the team to complete the migration and manage stakeholders’ expectations to prevent a backslide from too much impatience.
Innovating
The most exciting stage a team can be in is innovating. Innovation requires creativity and two ways of managing the passing of time. High creativity under high time pressure is akin to a Mission. Launching a new feature unblocking users to pay or fixing a crucial bug in a page to drive up conversion are good examples. High creativity under low time pressure is akin to an Exploration. Identifying new revenue streams and features to go along or learning how to make the systems “smarter” are longer-term innovations. In the innovation phase, I’d beat the drum of the value add to the business to avoid stakeholders’ scepticism of short-lived “research projects”.
Team topologies for decreased cognitive overload
Team Topologies talks about four types of teams and three types of interactions between them which are needed for modern, performant technology organisations.
The book also highlights the importance of bounding a team’s cognitive load. Instead of (re-)designing software architectures with a technology-first view, e.g. monolith vs microservices, we should start with a team-first view, size the sub-systems and place software domain bounds that fit a team’s cognitive load capacity: identify the business domains, break the complex ones into sub-domains and assign two to three to each team. This is a continuous process.
Rule of thumb: Each complex indivisible domain should be assigned to a single team and that should be the only domain they work on.
The reason is that solving hard problems takes time, focus and strict prioritisation to avoid large volumes of simple tasks disrupting the flow of solving important but difficult problems for the business.
Cognitive load means “the amount of mental effort being used in the working memory” and comes in three forms:
- Intrinsic cognitive load relates to the knowledge needed to solve a task, e.g. creating a new method inside a class or a new service.
- Extraneous cognitive load is about the context of the task, e.g. configuring and deploying the service.
- Germane cognitive load relates to deep knowledge and special attention aspects, e.g. improving a service's performance or making it more observable.
There are many benefits to limiting cognitive load, including:
- A shared mental model of the system the team works on (fewer mistakes, more coherent code, more predictable performance)
- More cognitive space to take up more challenging tasks instead of creating more teams with more interactions when the software complexity increases, increasing human complexity on top; collaboration doesn’t come for free!
- Github & Microsoft Research explains that preventing burnout and increasing work satisfaction and happiness is crucial for high-performance.
Based on their industry analysis, the book's authors recommend this approach as the only sustainable, safe and fast software delivery.
“When cognitive load isn’t considered, teams are spread thin trying to cover an excessive amount of responsibilities and domains. Such a team lacks bandwidth to pursue mastery of their trade and struggles with the costs of switching contexts.” — Team Topologies
I won’t be able to solve all the problems at once.
Sometimes the new role requires solving multiple problems at the same time, and the temptation is to try to please everyone. As I’ve learnt as a founder, trying to solve too many problems at once is a good way to fail. Instead, it’s simpler to prioritise a single problem/team, solve that first and move to the next.
There are no “One size fits all” solutions, and the best ones come from the bottom up.
Finally, I reserve the right to be wrong when choosing a solution and change my mind in the presence of new evidence. In hindsight, with new information, my decision could be proven wrong, but I find that indecision is the most costly of all decisions.
A better way is to start small and involve affected teams in providing feedback on the proposed solution. This doesn’t mean making decisions by committee — which is another form of indecision — but incorporating different viewpoints into the final one. Then measure the results, adjust, rinse, repeat.
Continue to Step 3— Measure the results and iterate.
