This post is interesting only as an example of a total lack of facts, comparisons, and perspective.
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.
While I generally agree with the author's thesis based on my own experience leading engineering teams, I also agree with your view point that the author provides no facts to back it up, not even examples of teams he has worked on. This makes his opinions somewhat circumspect.
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.
"Generally" is a bit of a cop out without data, but it's not wrong. If you survey companies to understand their organizational structure, you will see the sample dominated by domain-oriented structures (eg product, business unit, etc) as opposed to functionally-oriented structures (eg skills).
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.
Written by a product manager, I would presume. This design is optimized for product managers and that's it.
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.
Well, it should be obvious that not every feature/user story you develop needs a 40h/week specialist for every part of your product. Sometime you might only need to tweak the UI ever so slightly, or the backend integration could be trivial. Very often you will either have fractional stories in your sprint or underutilize your team. So in a perfect scenario you would share your specialistst amongst teams, but that goes against the typical manager metrics which is "how big is my headcount".
'This is – to use a technical term – bullcrap.' It's moderately inspiring to read this kind of technical opinion from a technical leader.
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.
One way of thinking of engineers is that they exist along two axis, junior => senior and generalist => specialist. So, when hiring, you might say something like, I want my team to be 50% senior generalists, 25% senior specialists, and 25% junior specialists. And, uh, yeah, junior specialists would probably end up being someone who can't really produce much of anything.
But... how is that a career path... specialist vs. generalist?
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?
Well, you can't have a 20-year example in React, but let's say you hire a 10-year expert. Then such an individual might balk at things like, evaluate different frameworks to rewrite our frontend instead in, write an iOS app for us in Swift, write backend endpoints, decide how to make the UI performant considering the frontend/backend/database, spin up a new small service for a one-off tool.
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.
Wow I imagine that candidate didn't get the job... I'd appreciate him if it were a personal policy more so than showing a lack of understanding for the past.
I've read a lot on how other orgs have grown and gone through DevOps transformations, and all of this is echoed in those stories, but it also leaves out other strategies. Would like to see more of a matrix of what strategies are useful in what context and aren't in others.
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?
> My experience is that it takes at least 6 months to reach the “performing” level, and sometimes much more. If staff switch teams more often than that, teams never reach their full potential.
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.
The "performing" part isn't about the individuals on the team, but the team as a whole. Every staff changes (adding or removing) slows down the entire team for a period of time.
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.
Others criteria are sound from the organization's POV, many (most?) of them pushing it to quickly move people.
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.
Designing and growing are different things because design implies having a preconceived plan. Whereas growing entails starting out with broad strokes and then organically iterating.
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.
Is a Bonsai tree a combination of designing and growing? Iterative design? This is all very imprecise terminology.
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.
I just see how organizations grow (as per the definition we are implying here). I've never seen anything "designed" per se. May be something like Microsoft org chart? Curious if you can concretely note an example to exemplify the ambiguity.
Design implies an authoritative, non-iterative mega-deployment. Growing implies an iterative, heterogeneous, observation-laden process with potential for feedback and adjustment. Where humans are involved, the latter is superior, if you want coherency and efficiency.
There is no way one could have picked up what you meant from just saying "Design vs. growth". You realize how general those terms are, right? Something that implies to you may not imply to many others.
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?
Apologies if it was unclear to you. It's hard to know who reads all the comments here and impossible to address everyone clearly. Many people on HN are involved in building companies which means they have experience with this sort of thing and probably understood without explanation. Who designs a team like this? Bigco HR departments, the military, the government, emergency response NGOs, etc.
That helps and I agree with the examples you cite. I think then we're arguing about mostly bureaucracy - they work great for stable work that needs to happen on a long term basis. Not agile. But, they have their purpose. If militaries and governments were formed like startups ("growth" as we define here), they would fail to function well. Hierarchy is important characteristic of militaries and big companies.
We develop everything from fighter jets to fiscal policy through "designed" organizations.
I assume this is based purely from his experience. I wonder how much research has been done on this. Surely Microsoft has tried to do some studies on it?
No discussion of Conway's Law is complete without mentioning the Inverse (or Reverse) Conway Maneuver[0] - knowing that architecture follows org structure, you structure your org to deliver the desired architecture.
More on Conway’s Law at [1]. The adage bears out and while this article could be better, understanding the mirroring phenomenon really is important. And while it’s not a formal proof, I do find the argument that the law must hold to be true.
i worked at an organization recently that has wholeheartedly embraced this approach to Conway's law.
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.
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.