Should you empower teams to make their stack choices? I've seen chaos breaking out for a year in a major development organization with 500 devs when most teams suddenly were allowed to make some choices that better should have been made centrally. Yes, they were faster but they were faster going nowhere. And then there are all these aspects that go beyond the development phase - long term maintenance, behavior of software in the field / training field engineers and moving people across teams.
Good technical leaders know where choice is called for and where not. Managing these trade-offs requires a perspective that goes beyond the agile team.
Sure this requires an "architect who codes" type person to be involved (which can get expensive), as opposed to some ivory tower powerpoint architect but is typically worth it.
There's a fine balance between allowing choice and setting standards. There's productivity gains as well from having some standards -- you can built tools which leverage standards, so long as they aren't too restrictive.
e.x. In the world of microservices, you end up needing a lot of telemetry to keep things running smoothly and figure out what goes wrong when your call is four levels deep. Doing so is hard without having a standard to which your services must adhere to. It's easiest if you have a base application which takes care of that for you. That, however, becomes hard if you have the combinatorial explosion of [languages] x [frameworks].
That doesn't mean you shouldn't entertain new choices, (hey, team X wants to use Go.) but there should be some discipline. It boggles my mind when individual engineers prefer to speed up their development for the short-term vs. the overall organization.
I currently work in an environment where there is virtually no central technical management. There are groups of 2-4 developers who roam around their department's problem space, making whatever choices they want.
If someone doesn't like the interface on one microservice, they fork the code and make a new one. This leads to 5 microservices that accomplish the same thing, and 5x the maintenance burden whenever something changes. I've derisively called these "nanoservices", but I need a more offensive term.
People intentionally choose techs that no one else in the company has used, trying to cement their position and hedge up potential competition or unwelcome cooperation. They also select technology for the best PR effect, being able to say "We're being like Google today". The result is a whole mess of different stuff running throughout production, each needing its own backup system, etc., which, to be honest, does not always get installed.
It's a disaster.
The author's contention is that giving more choice to teams is better because it makes them feel more ownership in their product. That's fine, but do recognize that this is a psychological solution to a management problem. The job of the manager is to actively control the psychology of employees and the structure of the organization such that employees are happy to do things that lead to cooperation, not to allow employees to always get their way.
Without a central coordinating force and everyone's acknowledgement that some compromise and sacrifice is necessary, everything falls apart quickly.
Normally, people don't do this a) because they don't want to be required to deal with the cruft or b) because they believe someone will observe their bad behavior and stop it. They don't really have to deal with the cruft, and it's clear now that no one in this organization will hold them accountable, so why should they waste time and energy trying to build a consistent platform?
re: Conway's Law, the organization's communication mechanisms are loose and ad-hoc; there is no central coordination. Consequently, the software is coordinated on a loose, ad-hoc basis between small teams. The same featureset will be implemented 4 times by 4 different teams, not because they can't talk (there is an office where most people hang out together all day, and people do generally keep an awareness of what the other group is working on), but because they'd rather just do it the way they want to do it.
It's not that no one ever ends up sharing anything. It's just that instead of having a discussion and making consistent decisions about the platform, they just do what they want, because they can.
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.
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.
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.
I agree that total anarchy is bad in the workplace, but don't you think that the people using the tools should have some input in choosing the tools?
The best standardization I have seen grew out of a team who was empowered to make decisions, made good decisions, showed how their decisions were good for the entire origination and helped everyone migrate to one solution which turned out to be pretty good at solving everyone's problems.
If you as a leader find yourself pushing a standard tool set to a team who is hesitant to adopt it the problem is most likely you.
The truth is that for most types of applications, there are several technology stacks that would be perfectly adequate. You get into the tradeoffs, and unless the benefit posed by a specific thing is immediately obvious, these are a matter of subjective judgment. Great technical minds will have differing subjective judgment; no one's judgment is exactly same as another's.
People also usually do not understand their own motives. This is the origin of fads. Everyone suddenly agrees that THING_Y is the best, and then, the next year, everyone suddenly believes it's THING_Z now. If someone can present a dense, semi-passable argument in favor of it, the rest of the uptake comes down to marketing. This is true no matter how smart you think you are.
If you have a technician who prides themselves on always knowing about new technologies, and that's their reputation, it's likely their primary motivating factor will be continuing to propagate that self-image. They might not even realize it.
They will come and say "There is a new tech called TECH_X and it allows us to do these amazing new things!" As long as TECH_X has some value proposition and isn't a blatant or obvious bad fit (meaning obvious and blatant to everyone), their argument is plausible enough and they'll run with that.
They think they're doing this because they learn all the new things and it gives them a competitive edge. In reality, it's because they view themselves as cutting edge, they want everyone else to view them as cutting edge, and need to feed themselves and everyone else some proof validating that desirable conception.
The difference between "political schemers" and your average employee generally comes down to their naivety around the universality and importance of these functions. Which is another danger -- the less-naive employees in the ranks will be actively working their own angles here to attempt to manipulate the psychology of the people around them. This can and does invade technical choices. You can make the best arguments in the world for your stack, but if you have a political competitor, they will work to undermine you, often in non-obvious ways. If they feel now is the time to strike and they can embarrass you, they'll do so; if not, they'll agree and subtly work to sabotage your plan.
There's another type of employee here; the type who wants to keep his day job on cruise control, and will oppose anything new because it would make his short-term daily existence more difficult (and perhaps long-term if the improvement could reduce inefficiencies so much that he becomes redundant), regardless of organizational benefit.
There are many arguments to be made in favor of keeping the status quo, so he will look OK; if your new stack is a wild success, he will be able to say "Oh, I just needed some time to come around" and if your new stack is an abject failure (which happens much more often than people wish to admit, and even more often, it's made to appear an abject failure by political competitors regardless), he will be able to say "I told you so".
People are naturally self-interested and will behave that way all that time. Management must look outside of the individual goals of the employee or team and consider what is in the long-term interest of the organization.
tl;dr This is naive; a purely democratic approach doesn't work because people's goals and values don't necessarily align.
So given people with differing goals and values they come to different conclusions about how to pursue those goals. Unless you hire sociopaths most of your employees will want the firm to do well and work with functional tech stacks that accomplish the stated goal of the company. However people in tech leadership don't always share that goal. They make decisions based much more on personal utility then the average worker. They might sign that sweetheart deal with a vendor because they see it as an avenue for a career change in the near future, or they might want to make sure no one below them starts to outshine them so they keep the stack something they understand ( knowing full well that someone not in leadership has much more time to persue learning ), or they know if they force an outdated but well known stack they can hire cheap.
In general none of those conditions are good for people actually doing the work and they know it which is why they push back. It gets propagated up the stack as naivete or fad chasing, but in general its leadership insulating their position ahead of the company or their co-workers. Those leaders fail and those companies fail. When decisions like this are pushed down from on high look out, its generally a sign of bad culture and a bad company
As a result its slow, messy and difficult to maintain. Would be nice if managers prevented small teams from choosing any technical choice they felt like.
That requires knowledge, experience, and good technical & business judgement. Unfortunately not everyone has these qualities. Refusing something simply for keeping things as they are is not a sustainable strategy in technology. Decisions have to be made smart, and they have to contribute to the incremental improvements.
The gamedev stuff I've helped tackle fundamanetlaly required mostly C++... and a little C, and some x86/ARM/PPC for debugging, HLSL 3-5/GLSL ES/PSSL/<custom shader DSLs> for porting graphics, at least two shell scripting languages for CI servers (Bash, and Powershell or (ew!) Batch), Python (for various modeling tools)... Java, Objective C, and C++/CX for platform specific APIs... MSBuild, Makefiles, Gradle, Ant... and that's just the languages! The tooling front is no better.
A handful more language choices that theoretically could've been avoided (e.g. C# for tools and server stuff, ActionScript for UI) is really not that big a deal in this context. You can add pointless layers of cruft, but I've only seen it once - a Python script used to hack up the result of a C++ program. Even then they had a reason: some of the C++ didn't get checked in, so we couldn't even build the C++ program. (A happy ending: With a little reverse engineering of the resulting binary output, I was able to re-implement the missing C++ bits, implement the Python-script 'fixes' more cleanly in the original C++, and add my own necessary changes on top of that.)
