Designing Engineering Organizations
jacobian.org
jacobian.org
The lone backing of each opinion is the adverb "generally". There is no mention of any concrete team/company size where issues do/might occur in one or the other setup. There is no mention of successful or failing companies adopting one or the other setup.
And just to mention a single concrete counter-example to the groundless side taken here, take Apple. Apple's organization is _based_ on specialization, for the simple reason that the more specialized teams are, the higher their expertise is. Look at Spotify, Microsoft, and others; they moved away from the simplistic feature-squad model advocated here, because it simply didn't scale.
Certainly, communication across team members, and communication across teams are subjects of attention. It does not mean it should be ignored/avoided. It's like saying "scaling horizontally is too difficult, just stick to scaling vertically"; sure, it's easier, but the power is not the same.
The example you mention (Apple) is a notable one precisely because it's an outlier in this respect. It is interesting! In particular, I understand than iPhone, iPad, and Mac are built by the same people, not split across separate teams.
Even then, Apple still has lots of typical domain-oriented structure. Of the 10 or so people I'vd known to work there, all of them have been in product-oriented teams.
For an example of research-based conclusions about teams, Google's write-ups are illustrative: https://rework.withgoogle.com/print/guides/5721312655835136/
In general, I think Google's research captures something that the author of this post fails to take into account fully, which is that psychological safety of the team members matters is a key indicator towards effectiveness.
1. No communication responsibilities. The product manager owns a team for the product and that's it.
2. Maximal headcount. Need a tenths of a frontend dev? You get one fully for your team!
3. No technical understanding required. You just tell the DB guy to "make things happen" via user story. No engineering manager to argue with, no wholistic constraints to consider. Disk space, bandwidth? What is that? May playlist feature needs to store all permutations persistently for performance!
The greatest admission is the implicit acknowledgement that product managers cannot work efficiently with teams organized by discipline. In any other industry that is the bread and butter of management: Coordinate and plan with other departments. Here we just eliminate this.
And what's the outcome? A coherent product? Far from it. You get a bunch of features glued together by a UI no one really owned. These features are not orthogonal and they definitely don't compose well. Why? Because to do so the product managers of different teams would have to coordinate between themselves. The very thing they just admitted they cannot do efficiently.
1. Product managers should manage products, not teams. Certainly they should not "own their team". Managing their product means deciding what gets built and why. Generally, there is a balance to strike between needs of the company (e.g. make money, support overall company strategy), needs of users (e.g. want to listen to self-made playlists) and technical considerations (how difficult is it to build, can we implement something similar with less effort). Not sure what you mean by "no communication responsibilities", but striking a good balance typically requires talking to a lot of people inside and outside the team.
2. It sounds to me like you're trying to rid team members of as much responsibility as possible. Of course everyone has their strengths, but I don't see why a "frontend dev" cannot help out with backend code or any of the other work necessary to get the product out the door. Which should be the mission of the team.
3. Even if some people don't have the same level of technical understanding as you do, there are still lots of ways they can contribute. For instance, they can sit in meetings with stakeholders so you don't have to. If something is wrong with a user story, don't assume bad intent. Discuss the pros and cons of an approach and suggest alternatives.
"The greatest admission is the implicit acknowledgement that product managers cannot work efficiently with teams organized by discipline. In any other industry that is the bread and butter of management: Coordinate and plan with other departments. Here we just eliminate this."
The whole point of a product team is to bring people from different disciplines together to deliver a better product in less time. This is possible because of more direct communication and less organizational friction. "Departments" organized by discipline are generally plagued by bureaucracy and delays in communication. On the other hand, having a product team sit together in one room enables a completely different level and pace of collaboration. If something is wrong with your DB story, you just mention it, people in the room become aware and find a solution potentially within minutes.
"And what's the outcome? A coherent product? Far from it. You get a bunch of features glued together by a UI no one really owned."
This is exactly what product teams prevent. The whole team owns the product. They talk about what should be done and by whom.
I have heard similar objections/uneasiness concerning delivery-aligned reporting, coming especially from more junior specialists. More so within teams with broader sets of disciplines.
In addition to the need of improving their skillset and receiving tailored career guidance, there is sometimes a strong political component.
... and wait for "junior specialist in everything" :-)
I mean I'm a generalist, and if you look at my 20 years in the industry, I'm a generalist because of the trail of work I've left behind; as in work, all of which needed to happen. For example, in the 2000s, we mostly used PHP and MySQL, today, it's very different. So being a specialist with, let's say, 10+ years experience, would be quite difficult. I'm sure even the C++ people can say C++ has changed a lot in 20 years(?) and are doing things radically different today?
How could I be a React specialist with 20 years in the industry? Forget the past?
In some sense, it's almost an attitude thing, which also reflects in what you've chosen to do in your career. As an extreme example, I have interviewed individuals who made it clear that they were a React expert and would not be willing to work on any legacy services that used jquery, any light backend work, anything.
In SRE/Ops, it seems to work better with two single-disciplinary teams (Builders and Runners) in one department. One team builds systems, another team runs systems. This is because experience leads to efficiency. Scaling a single-disciplinary team (in this context) you get efficiency combined with ability to respond to organizational change. Think of a cabinetmaker versus a chair maker. Or in comparing SW Developer / SRE-Builder / SRE-Runner, an auto engineer, an auto mechanic, and a racecar driver. They are each efficient at a particular thing because of their experience.
But for building and running a product as a whole, you want a multi-disciplinary team to manage the wide range of experience needed to build and run that product. You still rely on outside single-disciplinary teams for things that can be done more efficiently that way. But you can change the product faster/better if a core group has a lot of general knowledge about it.
The trick is to create feedback loops where these different teams feed information and work streams back into each other constantly. You do this to fight silo-ism, and to reduce friction in the value chain.
I think "reporting" is highly overrated. The principle of a self-organizing team is that they will figure out what they need to do. If you start dissolving the "lines" between teams, the organization as a whole will start figuring out what it needs to do. If you think about ecology, this is how natural systems work: there are always boundaries in different parts of an organism, but many of its parts self-determine their actions. Coordination becomes a ballet, not a machine.
And what's often overlooked is how the larger organization affects the value chain. The higher levels of the organization often set the tone for how work gets done for everyone. But different parts of the org may benefit from radically different working models. Are there proven ways to run different parts of the business in drastically different ways, yet still provide clear workflows for them to operate together efficiently?
On one hand, I agree with this, as I have been moved quickly between projects in the past, when I was more needed elsewhere. It helped to keep things interesting but I would have liked more stability.
On the other hand, there is a risk that people get stuck in one place for a while with no mobility, working on something they don’t like. I have seen this as well. Good people weren’t allowed to move, so they quit. As the team was shrinking, the others had to stay. Needless to say that morale was poor.
There is a fine line between the two.
This isn't also about people not moving and denying them career or personal opportunities, just a consequence of team changes. It's a reaction to the idea that once you add more people to a team or an organization, you will see productivity gains almost immediately. It tells you that actually they will take some time, and often, a LOT more time than you initially thought.
A classic one is "do no let any project (and therefore at least part of at least one product) become more-or-less the private domain of its team".
"Private domain" may be anything from "not really documented in written form because no member of the team needs it", to "this team gained enough power by becoming the only one able to run its project, that it now can strangle the org".
Thanks to an adedequate stream of newcomers there is always some knowledge outside of the team (=> high "bus factor"), and more risk and work for any potential warlord.
Still your language is imprecise. Can you give examples?
> authoritative, non-iterative mega-deployment
Like what? Who designs a team like this? What are some concrete examples?
We develop everything from fighter jets to fiscal policy through "designed" organizations.
The classic example is that of a combustion engine. Historically an engine was not designed, but “grown” ie iterated upon through trial and error. The heat transfer characteristics and thermodynamics were (are?) too complex to model, so engineers started out with a basic concept and iterated until they got the desired results.
I believe organizations work the same way. Instead of designing an organization from the ground up (clean sheet), most organizations actually start out organically and roles either expand or contract depending on needs and goals. There’s typically a lot of trial and error because it’s impossible to account for every variable that might affect the outcome. A heavily designed organization is liable to be very rigid, so the pragmatic path is align on shared principles and let each part of the organization organically grow according to its needs and goals.
Grown things can be designed. Designed things can be grown. Designed things doesn't always have to be grown. And lastly, Grown things doens't have to be designed.
All this sounds like Deepak Chopra's lectures.
I agree that design and grown are not mutually exclusive but I merely sought to demonstrate that they are different things.
[0] https://www.thoughtworks.com/radar/techniques/inverse-conway...
unfortunately, the groupings were decided based on a facile and outdated model of the product and were wildly unsuited for the reality of the day. kind of pessimal.
i think a more organic approach is necessary. even in larger organizations. i've never seen matrix (too many stakeholders, too many meetings, unclear unresponsibilities) do well...but surely there are other choices other than functional v product.