This is the last post in the blog series about team patterns and it’s all about self-managed product teams.

At first this team pattern looks similar to the product team pattern, but unlike the product team pattern there is no engineering manager directly responsible for the team’s work.

This pattern also looks a little like the matrix team as the people on the team report to a manager outside of the team, but unlike the matrix team there is no common theme for the engineers who report to an engineering manager.

That is, a single manager is responsible for a diverse group of engineers working with different technologies (e.g., C++, Android, Node.js) and different products areas (e.g., billing, orders, customers) — and there’s no guarantee that two Android Engineers will report to the same manager or that all people on the Orders product team will report to the same manager.

In this team pattern, the manager is less of a traditional manager who directs and supervises work — and more of a career counsler and coach who can advice the engineer.

In this team pattern the leadership of a team can be split into three separate roles:

• Product Manager: This role is focused on product leadership, such as talking with customers and preparing product road maps.
• Engineering Manager: This role is focused on people management, such as recruitment, career guidance, building culture, finding and fix interpersonal issues.
• Lead Engineer: This role is focused on technical leadership, such as technical best practices, mentoring, and anticipate the future technical needs of the team.

An real-world example of this team pattern is described by Josh Tyler, who is EVP Engineering at Course Hero, in his fine book Building Great Software Engineering Teams; at his company Course Hero, an online learning website, they’ve organized their teams according to their product areas:

On each product team they have a Lead Engineer who takes care of technical mentoring and guidance, define best practices, and make sure they are followed.
The Lead Engineer works closely with the Product Manager to scope projects, prioritize tasks, and give the team the context necessary to be successful.

Where it starts to divert from the product team pattern previous example is that the engineering manager’s role is independent from the Lead Engineers.
The Engineering Manager is responsible for a group of engineers across multiple product teams. The Engineering Manager is no longer involved in technical leadership and
doesn’t supervise the work of the Lead Engineer, but is focused on people management, such as finding and fixing people-related problems.

The roles of Engineering Manager and Lead Engineer are completely independent. So it is possible for a Lead Engineer in one product team to report to an Engineering Manager.
This engineering manager may be part of another product team — as a hands-on engineer — and report to another Lead Engineer for technical matters on that team.

But what do Course Hero do when they have a person who is both talented in people management and technical leadership? They considers those rare people to be precious gems that should be treasured and see them as people with executive potential. But still then, they recommend that the person starts by focusing on one of the two paths (i.e., Lead Engineer or Engineering Manager) and then master the other one later.

Strengths

The self-organized product team shares many of the strengths we have seen in the other team patterns.

But a distinct strength is that splitting the engineering manager role into two opens up for a genuine two-track career model with a track for managerial leadership
and another for technical leadership. This is important as most first-rate engineers are not really interested in traditional management, but are deeply passionate about technology, so in this
team pattern they have a career path where they grow without losing their technical edge. This will also make it easier to attract and retain highly skilled technical people
as you don’t expect them to become a traditional manager (and lose that all-important technical edge) or force them to report to a incompetent manager who overrides
their technical decisions due to authority, and not merits.

It may also make hiring easier, which should not be underestimated in a competitive job market, as finding a single candidate who excels in both technical leadership and people management is really tough.

Weaknesses

At first sight the clear definition and separation of product, technology, and people leadership roles look attractive — as it makes it real easy to figure out who to ask:

• Should you upgrade to the latest version of Angular? Ask the Lead Engineer!
• Do you dream of becoming a Full-Stack Developer? Talk with your Engineering Manager!
• What’s the most important feature to work on right now? Ask the Product Manager!

The risk is that in real life many problems doesn’t fit neatly into one of these categories…

For example, the CEO thinks that the team is not developing fast enough:

• Is that a product thing? Maybe the team is focusing on low-value, low-visible features?
• Is it a engineering thing? Maybe there is too much technical debts or poor design?
• Is it a people thing? Maybe the people on the team lack skills in the technologies used or their motivation is low?
• Is it a mix of these? All of these? Some of these?

This will make the debugging of the problem harder — as the debugging may spans multiple areas of responsibility owned by different people — it will make finding and fixing the problem take longer.

From a manager perspective: The primary weakness is that the manager is often no longer involved in engineering, neither as a lead nor as a individual contributor, and if this is the case then his or her engineering skills can quickly deteriorate as things are evolving pretty fast within computing these days (it’s a Red Queen’s race!) and the manager is in high danger of fast becoming a dinosaur that suggests solutions that made perfect sense… on mainframes! Or thinking that ASP Classic and React are more of less the same… I mean they are just web development frameworks, right? 😉

The knock-on effect of losing one’s technical instinct is that it can lead to poor judgement.

Of course, these risks can be mitigated — especially with good collaboration and some general curiosity about what’s happening in one’s field — but left unattended they may turn into issues.

That’s it! I hope you enjoy this little blog series on team patterns!