Enabling choice for Agile delivery Scrum teams(tonymaley.com)
tonymaley.com
Enabling choice for Agile delivery Scrum teams
http://tonymaley.com/choices/
12 comments
I, for one, want to see something beyond the shiny-toy syndrome when I talk to a team member about why we need to use the tool/technology/framework/library in question. I'm all for personal improvement, and every technology, regardless how different it is, that we learn/become familiar with makes us better professionals. But sandbox to production is a long way. Keeping things simple has its merits.
I don't have a choice: I must use a broad array of tools and languages.
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.)
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.)
He seems to be ignoring long-term maintenance costs. If you're building a $0.99 app then sure let the team pick whatever they want. But if you're building a huge SaaS web application with an expected 20 year lifecycle then that cuts the range of sensible choices way down.
Choices break naturally on time and platform boundaries. New projects should review stack choices, and enforcing cross-platform stacks is usually too brittle.
Too much chaos and choice and you slow down because everyone has done the same things in slightly different ways.
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.
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 work for a shop with more than 200 devs. Over the years we had multiple efforts to standardize the libraries, platforms we use only to very limited success. While things like CI software and IDE got pretty much standard without any intervention to this day there is no consensus for library x to do y. The overall sentiment resonates with me and what I've seen at my workplace
Creating software is about making the right decisions at the right point in time. Any decision by nature restricts choice. It is precisely the job of CTOs and architects to make decisions about partners, platforms, tooling and frameworks and to refrain from making these decisions at other times.
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.
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.
I would add that one way to gently enforce the stack when the system is getting built from scratch is having a solid end-to-end "POC"/"skeleton"/whatever you want to call it built by a senior architect before the rest of the team is brought in.
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.
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.
I agree, thats where the absolutes come in. Some choices need to be made centrally and the teams must stick to them, this is where choice can really work, when the lines are drawn and the structure clear.
I think the problem is that individual teams will make decisions that make sense for their own individual team. These decisions may not make sense for the larger organization as a whole (ie. having every team working in a different programming language) as they don't have the birds eye view of the organization.
Creativity leads to anarchy.
In my experience the team should be free to make whatever technical choice they want. The only reason you get dictation from on high about what choices should be made is because your technical leadership lacks the technical depth to advocate for a common stack that is actual useful. Every time I have seen an origination talk about standardizing on some language or framework and its hasn't grown out of the engineering community at that company its been because leadership didn't have a strong technical background and they were making choices based on marketing material, sales reps, or consultants.
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 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.
You assume that everyone in the company is acting rationally, and that everyone has the same goals and values. This is usually not the case.
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.
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.
What you have just described is the political reasons for not giving your employees agency in making their own decisions. Technically, while each stack might provide similar value proposition, familiarity and experience with a given stack are an organizational value that even given two equals would cause any rational person to pick the known and understood stack. Essentially you nailed the facts with your first line. If everyone is rational and had the same goals these things sort themselves out. Problems arise when people are not acting with the same goals or values, and on occasion they are not acting rationally ( it has been my experience that differing goals and values are so frequently the cause that assuming irrationality is just noise you can ignore )
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
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
>Technically, while each stack might provide similar value proposition, familiarity and experience with a given stack are an organizational value that even given two equals would cause any rational person to pick the known and understood stack.
This is not at all the case. There are many rational arguments to be made for abandoning an outmoded-but-already-in-place practice or stack, regardless of the knowledge base that already exists in the company. Many people could and would suggest a conversion to a new platform in good faith. Sometimes this would be the right decision, and sometimes it wouldn't; it really depends on the particulars of the organization.
> If everyone is rational and had the same goals these things sort themselves out.
People are not always going to have the same goals. You can't limit your organization to a subset of people who are all ideologically aligned.
Also, people frequently don't understand their motives for something; that is, they ascribe some rational-sounding reason to behaviors they are biologically driven to perform. They may fully believe their goals are aligned, but come to find out, they're not.
>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.
Sure, and since there are many tech stacks that would do well, this doesn't mean anything. People can disagree. When they disagree, the subjective judgment on the tradeoff must be passed up to a central authority.
>However people in tech leadership don't always share that goal. They make decisions based much more on personal utility then the average worker.
You're grossly overestimating the "average worker". The average tech workers wants to keep his job simple and easy so he can browse reddit all day at work.
You also assume that these things don't factor into the decisions of average workers. They do. Some workers aspire to be leaders, and, less naive about human nature, are willing to employ some showmanship and artifice to get there.
>In general none of those conditions are good for people actually doing the work and they know it which is why they push back.
None of the conditions you listed are good, but mature technical leadership, including standardization on a reliable stack (and, of course, a willingness to make rare-but-justified exceptions) is a boon to all.
>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.
There is a great deal of naivete and fad chasing everywhere, inside and outside of leadership. The ability to recognize it is valuable.
>Those leaders fail
Quite the contrary. Leaders do these things because, as long as one maintains plausible deniability, they are rewarded richly.
>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
Companies that understand human psychology, both in the public and in their employee base, are extremely successful, because ultimately power comes down to the consent and resources of others. They are also usually the companies people most want to work for.
This is not at all the case. There are many rational arguments to be made for abandoning an outmoded-but-already-in-place practice or stack, regardless of the knowledge base that already exists in the company. Many people could and would suggest a conversion to a new platform in good faith. Sometimes this would be the right decision, and sometimes it wouldn't; it really depends on the particulars of the organization.
> If everyone is rational and had the same goals these things sort themselves out.
People are not always going to have the same goals. You can't limit your organization to a subset of people who are all ideologically aligned.
Also, people frequently don't understand their motives for something; that is, they ascribe some rational-sounding reason to behaviors they are biologically driven to perform. They may fully believe their goals are aligned, but come to find out, they're not.
>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.
Sure, and since there are many tech stacks that would do well, this doesn't mean anything. People can disagree. When they disagree, the subjective judgment on the tradeoff must be passed up to a central authority.
>However people in tech leadership don't always share that goal. They make decisions based much more on personal utility then the average worker.
You're grossly overestimating the "average worker". The average tech workers wants to keep his job simple and easy so he can browse reddit all day at work.
You also assume that these things don't factor into the decisions of average workers. They do. Some workers aspire to be leaders, and, less naive about human nature, are willing to employ some showmanship and artifice to get there.
>In general none of those conditions are good for people actually doing the work and they know it which is why they push back.
None of the conditions you listed are good, but mature technical leadership, including standardization on a reliable stack (and, of course, a willingness to make rare-but-justified exceptions) is a boon to all.
>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.
There is a great deal of naivete and fad chasing everywhere, inside and outside of leadership. The ability to recognize it is valuable.
>Those leaders fail
Quite the contrary. Leaders do these things because, as long as one maintains plausible deniability, they are rewarded richly.
>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
Companies that understand human psychology, both in the public and in their employee base, are extremely successful, because ultimately power comes down to the consent and resources of others. They are also usually the companies people most want to work for.
Too many technologies is a problem so teams shouldn't be able to choose anything. My wider team is 50 people made up of ~8 smaller teams. We have some flexibility to choose technology with the result of our new product:
* Core system JVM
* Python wrapper for web service API
* C# scraping calling the web service
* JS/node webserver calling the C# layer
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.
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.
> 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.
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.
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.
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.
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.
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
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?
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
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
Everyone should know about Conway's Law [0], especially in the age of microservices.
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.
[0] https://en.wikipedia.org/wiki/Conway%27s_law
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.
[0] https://en.wikipedia.org/wiki/Conway%27s_law
Conway's Law in your environment should probably be interpreted that you have a team that can't talk or work together at all. It has nothing to do with what technical choices they are making, even if you imposed a rigid technical structure you would still have divergent nanoservices because your team can't communicate.
No, it's not that they're incapable of working together. It's that they have no incentive to do so. They can do whatever they want now and improve their own positions by so doing, so why shouldn't they?
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.
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.
Even if you imposed a singular stack, I could just do it my way at whatever level you started to let me make decisions. All you end up doing is adding overhead to your basic problem which is your teams are not communicating, fix that problem and your tech stack becomes irreverent. People will start to talk and start to organize into best practices simply because its easier ( why reinvent the wheel if Jim in accounting already did it and I can just use his stuff )
Yeah, but again, the people aren't necessarily mean-spirited or hostile. They'd cooperate more if the structure to affect that existed.
You're acting like they don't talk. They do talk, they just don't care. They know that guy x is making thing y, but they don't want to do it in the language/platform/framework/whatever he's using, so they make their own thing y. Structure needs to be in place to make cooperation happen.
You're acting like they don't talk. They do talk, they just don't care. They know that guy x is making thing y, but they don't want to do it in the language/platform/framework/whatever he's using, so they make their own thing y. Structure needs to be in place to make cooperation happen.
No it doesn't. If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work. Even if it was in a completely different tech stack you would still try to leverage someone else's work and there are plenty of ways to do that in almost any situation across most technologies. Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ). Then you get thing Y and thing Y+1. The problem isn't people chose different tech stacks its they don't want to work together. If they did they would choose tech stacks and work practices that foster collaboration.
>If thing Y was remotely complicated and if the teams had a good working relationship why would they choose to duplicate their work.
So many reasons, but they usually boil down to simple self-importance.
Also, remember that it's harder to read code than to write it. Any non-trivial library or service is going to have a learning curve.
>Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ).
Everyone has their own opinion.
In a rigid structure, this perspective wouldn't work because your paycheck would be imperilled by it.
>The problem isn't people chose different tech stacks its they don't want to work together.
Sure, I agree. In a correctly organized structure, their incentives would change, and their behaviors would be more cooperative.
>If they did they would choose tech stacks and work practices that foster collaboration.
No, that's like saying if people wanted unity, they'd make choices everyone would agree on. Everyone wants unity. They just everyone to unite to their idea of what's important/right.
Management is all about crafting an environment and structure that causes people to work in a productive way. That could happen in this company, but it hasn't.
So many reasons, but they usually boil down to simple self-importance.
Also, remember that it's harder to read code than to write it. Any non-trivial library or service is going to have a learning curve.
>Also even if a rigid structure existed I can still not use your thing Y most likely because I don't respect your work and I would implement thing Y differently ( and in my opinion better ).
Everyone has their own opinion.
In a rigid structure, this perspective wouldn't work because your paycheck would be imperilled by it.
>The problem isn't people chose different tech stacks its they don't want to work together.
Sure, I agree. In a correctly organized structure, their incentives would change, and their behaviors would be more cooperative.
>If they did they would choose tech stacks and work practices that foster collaboration.
No, that's like saying if people wanted unity, they'd make choices everyone would agree on. Everyone wants unity. They just everyone to unite to their idea of what's important/right.
Management is all about crafting an environment and structure that causes people to work in a productive way. That could happen in this company, but it hasn't.
It sounds like the teams should be reorganized to match the desired software architecture. Conway's Law is bidirectional. :)
This. Amazon has embraced SOA for a long time, and the organization is literally built around independent teams owning services. As the owner of a service, you have a charter, and other teams that want to use your service are encouraged to use your service so long as it fits your charter.
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?