As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the straight up wrong choice when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology.
The reasons that get hand waved away in this article are exactly the reasons you can't ignore consistency across teams. There is value in having just one library that multiple teams use to communicate via HTTP to various services, there is value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more.
I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because that is valuable. Letting the folks building the stuff decide which things to build first is much more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them).
Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.
Its interesting trying to figure out from your comment what kind of people you intend on working with. On one hand you conclude that given the opportunity your employees will wake the wrong choice. So if you can't trust them to make good decisions what do you trust them with? If they can't make tooling choices can they make algorithmic choices, if they can't make algorithmic choices can they really decide what kind of language constructs to use.
If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.
I don't have the information to make the "right" choice, because I don't attend the meetings you do, I don't generally care what happens when a new hire gets here, I don't care how the company spends money on writing 3 different client libraries, etc. Those aren't decisions that are tied to my compensation, my quarterly goals, and leadership doesn't come for my head when they find out about the bill they're paying for.
My expertise is in designing and building software, not in organizing teams for optimal productivity. The tools and tech that make the most sense for my project will get me to 100% optimization, but if I pay down a 5% optimization cost to bring all teams in my organization 80% to 90%, a manager should be the one making that choice, not me.
Pretending like everyone has the visibility into the org like you do will get you into trouble, and giving that visibility to everyone will harm their ability to focus on their jobs. I'm not a manager for a reason, I don't want to make those choices, but I need someone to.
Also, not everyone gets to work at Google. Advice like this needs to have value at Medium Sized Company, Inc., because those are the people who are most out in the cold. An Apple product manager has every tool on the planet available to him/her to figure out how best to help his/her team, but the guy/gal managing a dev shop in Carson City might not.
The choices a manager makes are very different from the choices a technologist should be making, and its not about what tools or tech stack you are working with. It is about things like how do I enable my team to deliver, because one thing people love to do is see how they can make excuses for failure to deliver. At the tech level its about how leadership and management makes poor choices, at the leadership level its about how your workers are lazy and unable to perform under such and such a condition. In reality its both parties trying to insulate themselves from failure by having a scapegoat.
Empower your tech teams to do great work, it doesn't require you to be a google or apple, or podunk startup. I have seen empowered teams at 10 man contact shops and 100,000 fortune 100 companies. If you run into a company that tries to tell you something else run away, you will find politics and infighting alongside terrible technology and an inability to deliver
If you let your teams individually choose their tech, they will be empowered to duplicate work, and they won't be able to cross pollinate or provide expertise/support to any team that's picked a tech stack different from theirs.
If the teams are working on similar problems, and if the teams actually work together they will stabilize on a singular stack. There will be cases where work will be duplicated, and there will be cases where tech components need to be refactored because the stack has changed, but you will end up with a very well known and understood set of tech primitives that your services are built out of.
There are lots of reasons why you may never hit that state of everyone self selecting the same or a very similar stack, but they are never technical and they always indicate a team structure problem that is going to cost you way more if you don't deal with it then the amount of duplicated work you might encounter
Comments
As a person who this article is saying should be empowered to have more choice, choice is a dog whistle for Not Invented Here. The people you employ to build your software will often make the straight up wrong choice when given the opportunity, and a lot of that time the "choice" will be to homebrew a solution that already exists elsewhere, because it's perceived as simpler than taking the time to understand an existing technology.
The reasons that get hand waved away in this article are exactly the reasons you can't ignore consistency across teams. There is value in having just one library that multiple teams use to communicate via HTTP to various services, there is value in members of different teams being able to work across projects due to the similarities in infrastructure. If each team has their own client library for communicating with a service, that's work you've paid for twice, or more.
I clicked on this article thinking it would be about choice within the prioritized stack on what to build and when, because that is valuable. Letting the folks building the stuff decide which things to build first is much more valuable than letting them pick between Postgres and MySQL, or memcache vs. redis, etc. (just examples, don't get too wrapped up in them).
Sure, we can sit here and come up with exceptions to choice, and yeah I do like being able to choose my IDE, the OS I develop on, etc., but those choices are totally different than which relational database I use, or which web framework I develop with. There, I don't think choice is good, at least not for everyone. Maybe this is written for my boss's boss, I dunno. But as for me, the dev writing the code, I don't really want me (or my colleagues) to have all that much choice.
Its interesting trying to figure out from your comment what kind of people you intend on working with. On one hand you conclude that given the opportunity your employees will wake the wrong choice. So if you can't trust them to make good decisions what do you trust them with? If they can't make tooling choices can they make algorithmic choices, if they can't make algorithmic choices can they really decide what kind of language constructs to use.
If I can't trust you to make a good choice on which technology to use why do I think I can trust you to make good choices in other aspects of your job. If you don't feel confident to make a technical choice then what you are telling me is you don't understand, and don't want to learn. Not really a desirable quality.
I don't have the information to make the "right" choice, because I don't attend the meetings you do, I don't generally care what happens when a new hire gets here, I don't care how the company spends money on writing 3 different client libraries, etc. Those aren't decisions that are tied to my compensation, my quarterly goals, and leadership doesn't come for my head when they find out about the bill they're paying for.
My expertise is in designing and building software, not in organizing teams for optimal productivity. The tools and tech that make the most sense for my project will get me to 100% optimization, but if I pay down a 5% optimization cost to bring all teams in my organization 80% to 90%, a manager should be the one making that choice, not me.
Pretending like everyone has the visibility into the org like you do will get you into trouble, and giving that visibility to everyone will harm their ability to focus on their jobs. I'm not a manager for a reason, I don't want to make those choices, but I need someone to.
Also, not everyone gets to work at Google. Advice like this needs to have value at Medium Sized Company, Inc., because those are the people who are most out in the cold. An Apple product manager has every tool on the planet available to him/her to figure out how best to help his/her team, but the guy/gal managing a dev shop in Carson City might not.
The choices a manager makes are very different from the choices a technologist should be making, and its not about what tools or tech stack you are working with. It is about things like how do I enable my team to deliver, because one thing people love to do is see how they can make excuses for failure to deliver. At the tech level its about how leadership and management makes poor choices, at the leadership level its about how your workers are lazy and unable to perform under such and such a condition. In reality its both parties trying to insulate themselves from failure by having a scapegoat.
Empower your tech teams to do great work, it doesn't require you to be a google or apple, or podunk startup. I have seen empowered teams at 10 man contact shops and 100,000 fortune 100 companies. If you run into a company that tries to tell you something else run away, you will find politics and infighting alongside terrible technology and an inability to deliver
If you let your teams individually choose their tech, they will be empowered to duplicate work, and they won't be able to cross pollinate or provide expertise/support to any team that's picked a tech stack different from theirs.
Doesn't this just encourage silos?
If the teams are working on similar problems, and if the teams actually work together they will stabilize on a singular stack. There will be cases where work will be duplicated, and there will be cases where tech components need to be refactored because the stack has changed, but you will end up with a very well known and understood set of tech primitives that your services are built out of.
There are lots of reasons why you may never hit that state of everyone self selecting the same or a very similar stack, but they are never technical and they always indicate a team structure problem that is going to cost you way more if you don't deal with it then the amount of duplicated work you might encounter