The best teams are multipolar

Usman Ismail
Sep 2, 2018 · 4 min read

At the thousand foot view the job of an engineering manager is easy; get a list if tasks that need to be completed, order them in terms of priority and then start chipping away until they are done. Throw in a little expectation management and planning and you are done. Specially in today’s Agile world, where planning horizons are not expected to be very long. However, once we start unpacking these tasks the picture gets a little more complicated. Today I would like to unpack the prioritization aspect of an engineering manager’s role. Specifically, I want to dig into the concepts of comparability and ordering.

There is an implicit assumption that engineering tasks are comparable and part of a partially ordered set if not a totally ordered one. How many times as a manager have you been asked by your peers or managers; “What is your highest priority right now?” and how many times has your answer been two or more tasks rather than one. This is not a failure or prioritize but an indication that a software engineering team’s backlog is at best a partial order and often many tasks are not comparable at all. If pushed you may be able to pick one of these tasks you may be able to as your absolute number one priority. However, in your head you still know you have get these tasks done ASAP otherwise many things will start falling apart. I would argue we need to explicitly understand that some tasks are not comparable and plan to deal with such situations.

There are two major sources of difficulty in comparing tasks:

First, having multiple independent goals for your team. For example, my current team at Wealthsimple is responsible for, among other things, building software for: preparing tax statements, audit reports, storing and presenting all transactional data for Wealthsimple clients. Some of these tasks are comparable against each other. For example we may needed to compare the priority of the work required to support a new tax statement type vs the work required to automate an audit report. In this case we can see the due dates, first quarter of next year for the former and the date of the next audit. However, how do you compare the tax statement work vs a new feature to better expose transactional data to clients? If you use due date as a guiding metric than the tax work will always win as the UI work has no explicit deadline. If you use client satisfaction, engagement etc as a metric the UI work will win. (Except the 2 days before tax filing day when users actually care about tax statements).

Second, contention between internal and external goals. This can also be understood in terms of importance vs urgency or feature vs technical debt. External parties will always care more about features that can make an immediate impact. Internally to your team you will put relatively more weight on operational improvements and mitigations that allow you to scale. For example, how do your prioritize re-architecting data pipelines to support existing features in 12 months (when the user-base has doubled in size) vs feature work vs automation for operational efficiencies. We would much rather be worrying about scaling problems before our systems are creaking at the seams. However, automation will help give us more time to focus on big system redesigns. Similarly, without ongoing feature work we may never get the 2x or more user growth. It is my contention that attempting strict ordering between these tasks is a fools errand. We can come up with some convoluted metric to order these tasks but plans based on such a metric will be thrown by the wayside long before completion.

Instead I propose that the most high functioning teams will be multipolar. At the very least every team should have a leader focused on external deliverables and a second focused on setting technical direction and keeping an eye on technical debt. Several larger organizations such as Amazon and Electronic Arts (EA) already staff teams with both engineering managers and Technical Product Managers (TPM). In smaller organizations without the resources to staff both these positions the TPM role can be given to a senior engineer. However, in the later case its important to make the additional expectations being placed on the engineer explicit to the engineer and engineering manger. In addition, the engineer must be given the freedom and resources to execute the longer term technical vision.

Generalizing further, If we expect a team to execute and deliver multiple independent streams of work then each stream must have its out advocate/owner or Directly Responsible Individual (DRI). Project Planning and Technical Design are just two of the deliverables of the team. If the team is responsible for multiple features planning for and designing each of those features is its own deliverable. A subset of these deliverables can be allocated to all or many members of the team. The DRI will be a natural future Engineering Manager once the team grows and needs to split. Furthermore, the DRI can keep focused on the long term vision of the sub-system or project where as the Engineering Manager needs to keep a close watch on the external deliverables, dependencies and short term efficiency of teams’ execution.

This mental model transitions the team from Leader and Followers to colleagues responsible for different deliverables: Project Planning, Technical Vision, Coaching, Communication and Team Culture for each of the streams of work that the team executes. On truly great teams the engineering manager role should be little more than managing external communication, managing culture and coordinating between team members. In such teams Each member of the team from the most junior to the most senior will have at lest one or two areas in which they are solely responsible for outcomes.

Usman Ismail

Written by

Engineering Manager at Wealthsimple

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade