Iyfjky

Question

With a coworker we have an ongoing debate about the said thing in the title.

Should team-members or individual developers be asked about business and technical decisions affecting them or not?

Is there any hard data that can decide (or help deciding) this question?

We were on a very different opinion, what I want to summarize here:

Cons:

takes time from management, slowing the decision making process

most of the time business decisions is business decision, developers don't have the same insight about markets, so why ask?

criticizing from the lowest level of hierarchy where you don't have real responsibility apart from your own work is arrogance

Pros:

employees feel involved if heard, even if they conclude the same

developers can dismantle untechnical assumptions

they may have ideas about reaching the same goals with less maintenance heavy solutions

Examples of not asking developers:

complete technology stack change

forcing of reusing products or components even when they somewhat fit only

adding half-technical and half-business stories to the teams

moving from team A to team B

Update

The company I work for claims we are following Scrum principles and have lots of meeting about reaching an Agile state.

"criticizing from the lowest level of hierarchy where you don't have real responsibility apart from your own work is arrogance" - I think this viewpoint is in itself arrogant. And also drawing a fallacious parallel between "amount of responsibility" and "ability to provide insight and useful criticism". Those people at the bottom are probably smarter and more capable than you're giving them credit for. — Oct 14 '15 at 10:50
No, the question is company specific. Some companies do tell the employee info (I worked for one before). Some companies are huge enough that you actually deal with first line mangement only and the first line manager has very limited info.(I am retiree from one of the Dow Jones 30 companies which is that case). Agile has nothing to do with the question. (You are talikng about business info, not technical info) — Oct 14 '15 at 11:40
@aroth It is called capitalism. You can sell your company to anyone you want. — Oct 14 '15 at 12:11
@aroth, it is not unethical for the owner to make a decision that you don't agree with and not tell you about it early. That owner has done nothing wrong and owes you nothing with regard to advance notice. It might be nice if he told employees before a large public announcement, but I still wouldn't expect you to be told anything until long after the decision was made. — Oct 14 '15 at 12:45
Depending on the situation, the owner might have legal reasons why he cannot tell you he is selling the company. There are many decisions made at all levels of organizations that have perfectly valid reasons why they were not shared earlier. Business is not a democracy, you have no inherent right to have input into every decision that could affect you. If you want inputs into major decisions, then become a senior manager. But even they don't know about everything in advance. — Oct 14 '15 at 18:28

Patricia Shanahan 16.2k53256 · Answer 1 · 2015-10-14 10:25:33Z

For publicly traded companies, and companies in the process of going public, there may be rules about business information that has to be announced to everyone simultaneously, and when the information should be announced. See, for example, Quiet period.

Even if not limited legally, when and how a decision is announced is often a matter of corporate strategy, with gradual leaks because too many people know about it being the worst option.

Thanks, you are making a good point here about cases when it affects share prices and/or competition reaction. However I do feel that is only true for this major announcements and moves, not for smaller. — Oct 14 '15 at 11:20

aroth 8,29812646 · Answer 2 · 2015-10-14 13:11:25Z

Yes, all stakeholders that will be directly affected by a business decision should be consulted. Both generally, and doubly so if you're running Agile/Scrum.

As for hard data as to why that's the better approach, that's going to be hard to come by as every business and every business decision is different.

However, it's fairly easy to dismantle the argument(s) against that approach. The 'cons' you've listed are flawed, at best. For instance:

takes time from management, slowing the decision making process

Is your goal to make a fast decision, or to make the right decision? Occasionally there's a crisis that genuinely requires a prompt decision. But more typically, a business is better served by investing the time to make a good decision than it is by simply making a quick decision for the sake of making one.

The latter is a symptom of a reactive decision making process that tends to see teams endlessly jumping from one imagined crisis or disruptive-context-switch to another for no good reason, and little to no productive work actually getting done.

In any business, the cost of even a single bad decision can be significant. Thus it seems unwise to prefer fast decisions to good decisions.

most of the time business decisions is business decision, developers don't have the same insight about markets, so why ask?

For the first half, fair enough in the subset of cases where that's actually true. The key is to involve the direct stakeholders, not everyone who might have an opinion.

For the second half, I think you'd be surprised how intelligent and insightful your developers can be on a wide range of subjects if given a chance. If you've put some effort into hiring quality developers, then they're plenty smart. So why waste talent, and why assume that talented people cannot have insight into a broad range of topics?

Besides, if your "business decision" is something like "we're going to change from being a platform that helps people crowdfund their favorite charitable causes to a platform that helps cigarette companies effectively position their advertisements" (to take an extreme example), your developers have a vested interest in knowing that sort of thing. And you have a vested interest in learning that you'll lose 75% of your developers to moral outrage before you make that decision.

criticizing from the lowest level of hierarchy where you don't have real responsibility apart from your own work is arrogance

This is the worst one. It's not just untrue (as above, if you've got decent developers then they're entirely capable of providing valid criticisms and valuable insight), but whomever threw that into the "cons" pile clearly has an arrogant and condescending perspective themselves.

There's zero correlation between "amount of responsibility" and "ability to contribute to the decision-making process". Enough said.

We can also work through the examples you've provided, and see which approach might work better:

complete technology stack change

I can't envision a single scenario in which making this kind of decision from the top, without consulting your developers, wouldn't be completely insane.

Say you're a Java shop, with several teams of very talented Java developers. But the hotshot new CTO comes from a Ruby on Rails background, and his decision is to convert everything to RoR. The only possible (realistic) outcome is unmitigated disaster.

On the other hand, if you take the time to consult with your developers and they point out the obvious "nobody here knows the first thing about RoR", then perhaps you can avoid catastrophe. Or see if your developers think a migration of that kind is even possible. Or get an informed opinion about whether or not switching to RoR will provide any ROI or if it's just the CTO's expensive new boondoggle.

The point is, making a decision like that which affects the people in the trenches in such a massive and fundamental way, without even bothering to check the trenches, is just asking for trouble.

forcing of reusing products or components even when they somewhat fit only

How can fitness be evaluated without having your developers look at the product/component you intend to reuse and the context you're trying to use it in, and making a determination about if, how, and at what cost the product/component can be made to fit the new requirements?

Even if the decision is to reuse the existing product/component, the very first step along that path is to evaluate the actual cost and feasibility of the approach. So you either involve your developers in that process up front by making them part of the decision-making process. Or you involve them in effectively the same way immediately thereafter.

In either case the outcome is the same. Unless your decision-making process is such that you're going to ignore your developers if/when they say the product/feature can't be reused in the desired way. But that would be a bad decision.

adding half-technical and half-business stories to the teams

This one seems a bit unclear.

But if you're following Agile/Scrum, then presumably you're running backlog grooming and sprint planning meetings that involve the developers as a matter of course. In which case I'd expect the developers to give their input on the new story at that point.

As long as the new stories aren't being dropped directly into an active sprint (which is a big problem in your Agile process if so), your process should already be built to accommodate this. In a way that's deliberately designed to bring all the stakeholders to the table to review and discuss the story before any work is done on it.

moving from team A to team B

I assume this means moving a developer around.

How do you determine what the impact will be to team A if nobody asks them? Perhaps the developer you're moving has some skill that's critical to team A. Or perhaps they're really passionate about what team A is doing, and uninterested in team B's task. Do you want to make an ineffective move because you couldn't be bothered to ask first?

Similarly, how do you know that team B needs an extra developer or that the developer you're moving will satisfy team B's needs if you don't consult with team B and the developer involved?

Even the most minimal instance of this case seems to imply at least a degree of consultation. Someone from team B has to say they need another developer, at the very least. Otherwise what you have is arbitrary and capricious management in which developers get shuffled around without rhyme, reason, intent, or impact. Which tends to be very demoralizing for your developers.

So in the interest of making effective allocation of development resources, at least a degree of consultation would seem to be called for in this case as well.

"adding half-technical and half-business stories to the team" - I wasn't clear on this. We are facing this at the grooming process, so we can mitigate it. But at that point we usually need to put it into the next sprint, so the complete redesign from a technical viewpoint is very hard to achieve. For this kind, leaving out the technical part and focusing on the actual business would be beneficial. — Oct 16 '15 at 16:49
"moving from team A to team B" "I assume this means moving a developer around." Yes, this means that. — Oct 16 '15 at 16:50
I do feel that your answer with Patricia's pointing out of the share price affecting ramifications combined together ARE the answer to this question. — Oct 16 '15 at 16:53

Dawny33 12.2k34563 · Answer 3 · 2015-10-14 10:08:52Z

If the change affects/is concerned with a particular team, either in their projects or their role as a whole, then the decisions should definitely be informed.

For example:

Designing the technical stack for the growth dashboard

So, how do you communicate the decision to various teams?

To the engineering team:

The data would be coming from _______, and would get stored in
_______. This language would be used for analytics, and finally _________ framework would be used for the dashboard.

This is what you say for the growth/marketing team:

The dashboard would be divided into _______ components, each dealing
with ______. The dashboards would be effective in analyzing customers'
_____, ____ and ______.

So, I would address the pros and cons which you have enlisted:

takes time from management, slowing the decision making process

Yea and No. The company where I currently work at, have office hours (a session of 2 hrs) for discussing about the decisions which would affect the company and the employees. So, slowing can be avoided.

most of the time business decisions is business decision, developers
don't have the same insight about markets, so why ask?

Completely agree. But, if that decision directly/indirectly affects them or their work, then they need to be informed about it. Else, not needed. For example: The pricing strategy of the product need not be communicated But, the going IPO news need to be.

criticizing from the lowest level of hierarchy where you don't have
real responsibility apart from your own work is arrogance

Again, short sessions would do. And as mentioned, even if they are in a very small role in the company, it is ethical to inform about decisions which affect them and/or their work.

And the pro's are really good. So, I don't have anything to vary about.

Added after your edit:

As you said the company aims to use the agile process, I would still stick with my opinion.

Unless and until all the teams are distributed(or in form of micro services), major technical decisions of one team should be conveyed to another team, if it affects tem too.

And business decisions, I would still stick to my opinions above.

Your answer is about telling people, not asking them. An example of asking them would be "the deadline is May 1. Is that reasonable?" — Oct 14 '15 at 15:13

Erik 26.2k187199 · Answer 4 · 2015-10-14 10:08:59Z

Scrum/Agile says that the people doing the work are entirely self-organising and in charge of their own technology. Getting the work done is their own responsibility.

This means that (in a perfect Scrum/Agile setting) when it comes to the technology stack, which components to use or reuse, what constitutes a good program, and any other question directly related to how the work gets done, management should not be involved, at all.

The only example you have that would involve management is "moving people to a different team", and even there it is really important to talk to the team members, because they'll be the ones who have to leave their current team and get up to speed with the new one.

The entire concept of "having decisions forced upon you by management" is decisively un-Agile.

So, if Apple adopts Scrum/Agile, then every employee has the right to know what the next version of iPhone looks like? — Oct 14 '15 at 10:15
Everyone involved should know, yes. Can't work on the thing if you don't know what it's going to look like. — Oct 14 '15 at 10:22
@Erik I've worked on the architecture of a server without having the faintest idea what color the case would be, or even what the product name was going to be. I got the information I needed to do my job, and no more. — Oct 14 '15 at 10:25
The Agile/Scrum paradigm breaks down long before you get to a work group the size of the entire company of Apple. — Oct 14 '15 at 12:30
Self-managed does not mean you have carte blanche to do whatever you want with technology. For companies of any reasonable size with multiple scrum teams, there will have to be decisions made on common technologies that all teams will have to adhere to. Some person or group in the company has to make those decisions and it is up to the company management to decide how much involvement developers have. — Oct 14 '15 at 12:39

Jim 4,495623 · Answer 5 · 2015-10-14 17:53:57Z

After reviewing the answers to your question, I thought I would provide another perspective.

While we can debate your "pros" and "cons", the answers here tend toward favoring an "open conversation" and "soliciting opinions" from developers because of the value of the opinions, trying to make an argument for the non-personal aspects of the interaction. While developers tend to be very intelligent people, there are many reasons not to include them in decisions because of the personalities and nature of developers.

First, there is the problem of "overvalued ideas" (http://www.goodtherapy.org/blog/psychpedia/overvalued-idea). When asked, some people will have beliefs about their ideas that are not accurately aligned with the true value. This is not always easy to see and is always difficult to handle.

The person asking may also be subject to over valuing the speaker's idea, because of rank or status (this happens with judges and "expert witnesses" for example). These are risks to the business and the decision that are not mentioned in the answers that I read, but I have seen happen in the workplace.

Second, despite the high intelligence of some employees (developers tend to be highly intelligent), intelligence is not the sole basis for asking the person's opinion as it does not always lead to a rational response (http://lesswrong.com/lw/2g1/what_intelligence_tests_miss_the_psychology_of/). The most difficult aspect of this situation is that highly intelligent people suffering from this do not self-assess or recognize this, and our society generally admires the intelligent, whether rational or not. The result is that intelligent words are strung together in a manner that sounds rational, but it fundamentally is not. This is generally difficult to identify and handling the situation is even more difficult.

Another problem is that some employers are concerned that if their decision does not align with an employee's opinion, that employee may feel less valued than if they were never asked. And feeling valued is a key element in performance (http://psychcentral.com/blog/archives/2012/10/09/why-its-important-to-feel-valued-at-your-job/). However, creating this dialog is one of the key factors to helping employees feel valued (http://www.globoforce.com/gfblog/2014/the-dangers-of-employee-silence/). This is usually what creates the basis for the decision on whether or not to ask employees.

It seems that many responses here assume that employers ignore employees - which is possible. In favor of that it is appropriate to highlight that the employer / supervisor is also at-risk for over-valuing their own ideas, being irrational and/or feeling undervalued by their employees / subordinates when hearing their ideas or opinions.

Last, when an employer or supervisor is feeling insecure, they are unlikely to solicit opinions (http://www.texasenterprise.utexas.edu/2015/04/09/workplace/when-managers-are-insecure-employee-voices-aren-t-heard). This is probably one of the more frustrating aspects of this situation - an insecure boss hinders an employee's advancement.

So, "should" employers do this? Yes, they probably should, if they can handle all of the emotional aspects of doing it in addition to the mechanics (gathering ideas, weighing them, responding to them, asking questions to understand them, etc.). And then there are still some of the other possible issues you mentioned (like timely decision making and whether or not an opinion on a matter for which you have no responsibility is appropriate to solicit).

You are making very good points here, and the research is awesome. It pretty sucks, that I don't currently have enough reputation to upvote this. I think that my question is answered, but at least 3 answers covering it. So, hard to choose one. — Oct 16 '15 at 17:04

Patricia Shanahan 16.2k53256 · Answer 6 · 2015-10-14 10:25:33Z

For publicly traded companies, and companies in the process of going public, there may be rules about business information that has to be announced to everyone simultaneously, and when the information should be announced. See, for example, Quiet period.

Even if not limited legally, when and how a decision is announced is often a matter of corporate strategy, with gradual leaks because too many people know about it being the worst option.

Thanks, you are making a good point here about cases when it affects share prices and/or competition reaction. However I do feel that is only true for this major announcements and moves, not for smaller. — Oct 14 '15 at 11:20

aroth 8,29812646 · Answer 7 · 2015-10-14 13:11:25Z

Yes, all stakeholders that will be directly affected by a business decision should be consulted. Both generally, and doubly so if you're running Agile/Scrum.

As for hard data as to why that's the better approach, that's going to be hard to come by as every business and every business decision is different.

However, it's fairly easy to dismantle the argument(s) against that approach. The 'cons' you've listed are flawed, at best. For instance:

takes time from management, slowing the decision making process

Is your goal to make a fast decision, or to make the right decision? Occasionally there's a crisis that genuinely requires a prompt decision. But more typically, a business is better served by investing the time to make a good decision than it is by simply making a quick decision for the sake of making one.

The latter is a symptom of a reactive decision making process that tends to see teams endlessly jumping from one imagined crisis or disruptive-context-switch to another for no good reason, and little to no productive work actually getting done.

In any business, the cost of even a single bad decision can be significant. Thus it seems unwise to prefer fast decisions to good decisions.

most of the time business decisions is business decision, developers don't have the same insight about markets, so why ask?

For the first half, fair enough in the subset of cases where that's actually true. The key is to involve the direct stakeholders, not everyone who might have an opinion.

For the second half, I think you'd be surprised how intelligent and insightful your developers can be on a wide range of subjects if given a chance. If you've put some effort into hiring quality developers, then they're plenty smart. So why waste talent, and why assume that talented people cannot have insight into a broad range of topics?

Besides, if your "business decision" is something like "we're going to change from being a platform that helps people crowdfund their favorite charitable causes to a platform that helps cigarette companies effectively position their advertisements" (to take an extreme example), your developers have a vested interest in knowing that sort of thing. And you have a vested interest in learning that you'll lose 75% of your developers to moral outrage before you make that decision.

criticizing from the lowest level of hierarchy where you don't have real responsibility apart from your own work is arrogance

This is the worst one. It's not just untrue (as above, if you've got decent developers then they're entirely capable of providing valid criticisms and valuable insight), but whomever threw that into the "cons" pile clearly has an arrogant and condescending perspective themselves.

There's zero correlation between "amount of responsibility" and "ability to contribute to the decision-making process". Enough said.

We can also work through the examples you've provided, and see which approach might work better:

complete technology stack change

I can't envision a single scenario in which making this kind of decision from the top, without consulting your developers, wouldn't be completely insane.

Say you're a Java shop, with several teams of very talented Java developers. But the hotshot new CTO comes from a Ruby on Rails background, and his decision is to convert everything to RoR. The only possible (realistic) outcome is unmitigated disaster.

On the other hand, if you take the time to consult with your developers and they point out the obvious "nobody here knows the first thing about RoR", then perhaps you can avoid catastrophe. Or see if your developers think a migration of that kind is even possible. Or get an informed opinion about whether or not switching to RoR will provide any ROI or if it's just the CTO's expensive new boondoggle.

The point is, making a decision like that which affects the people in the trenches in such a massive and fundamental way, without even bothering to check the trenches, is just asking for trouble.

forcing of reusing products or components even when they somewhat fit only

How can fitness be evaluated without having your developers look at the product/component you intend to reuse and the context you're trying to use it in, and making a determination about if, how, and at what cost the product/component can be made to fit the new requirements?

Even if the decision is to reuse the existing product/component, the very first step along that path is to evaluate the actual cost and feasibility of the approach. So you either involve your developers in that process up front by making them part of the decision-making process. Or you involve them in effectively the same way immediately thereafter.

In either case the outcome is the same. Unless your decision-making process is such that you're going to ignore your developers if/when they say the product/feature can't be reused in the desired way. But that would be a bad decision.

adding half-technical and half-business stories to the teams

This one seems a bit unclear.

But if you're following Agile/Scrum, then presumably you're running backlog grooming and sprint planning meetings that involve the developers as a matter of course. In which case I'd expect the developers to give their input on the new story at that point.

As long as the new stories aren't being dropped directly into an active sprint (which is a big problem in your Agile process if so), your process should already be built to accommodate this. In a way that's deliberately designed to bring all the stakeholders to the table to review and discuss the story before any work is done on it.

moving from team A to team B

I assume this means moving a developer around.

How do you determine what the impact will be to team A if nobody asks them? Perhaps the developer you're moving has some skill that's critical to team A. Or perhaps they're really passionate about what team A is doing, and uninterested in team B's task. Do you want to make an ineffective move because you couldn't be bothered to ask first?

Similarly, how do you know that team B needs an extra developer or that the developer you're moving will satisfy team B's needs if you don't consult with team B and the developer involved?

Even the most minimal instance of this case seems to imply at least a degree of consultation. Someone from team B has to say they need another developer, at the very least. Otherwise what you have is arbitrary and capricious management in which developers get shuffled around without rhyme, reason, intent, or impact. Which tends to be very demoralizing for your developers.

So in the interest of making effective allocation of development resources, at least a degree of consultation would seem to be called for in this case as well.

"adding half-technical and half-business stories to the team" - I wasn't clear on this. We are facing this at the grooming process, so we can mitigate it. But at that point we usually need to put it into the next sprint, so the complete redesign from a technical viewpoint is very hard to achieve. For this kind, leaving out the technical part and focusing on the actual business would be beneficial. — Oct 16 '15 at 16:49
"moving from team A to team B" "I assume this means moving a developer around." Yes, this means that. — Oct 16 '15 at 16:50
I do feel that your answer with Patricia's pointing out of the share price affecting ramifications combined together ARE the answer to this question. — Oct 16 '15 at 16:53

Dawny33 12.2k34563 · Answer 8 · 2015-10-14 10:08:52Z

If the change affects/is concerned with a particular team, either in their projects or their role as a whole, then the decisions should definitely be informed.

For example:

Designing the technical stack for the growth dashboard

So, how do you communicate the decision to various teams?

To the engineering team:

The data would be coming from _______, and would get stored in
_______. This language would be used for analytics, and finally _________ framework would be used for the dashboard.

This is what you say for the growth/marketing team:

The dashboard would be divided into _______ components, each dealing
with ______. The dashboards would be effective in analyzing customers'
_____, ____ and ______.

So, I would address the pros and cons which you have enlisted:

takes time from management, slowing the decision making process

Yea and No. The company where I currently work at, have office hours (a session of 2 hrs) for discussing about the decisions which would affect the company and the employees. So, slowing can be avoided.

most of the time business decisions is business decision, developers
don't have the same insight about markets, so why ask?

Completely agree. But, if that decision directly/indirectly affects them or their work, then they need to be informed about it. Else, not needed. For example: The pricing strategy of the product need not be communicated But, the going IPO news need to be.

criticizing from the lowest level of hierarchy where you don't have
real responsibility apart from your own work is arrogance

Again, short sessions would do. And as mentioned, even if they are in a very small role in the company, it is ethical to inform about decisions which affect them and/or their work.

And the pro's are really good. So, I don't have anything to vary about.

Added after your edit:

As you said the company aims to use the agile process, I would still stick with my opinion.

Unless and until all the teams are distributed(or in form of micro services), major technical decisions of one team should be conveyed to another team, if it affects tem too.

And business decisions, I would still stick to my opinions above.

Your answer is about telling people, not asking them. An example of asking them would be "the deadline is May 1. Is that reasonable?" — Oct 14 '15 at 15:13

Erik 26.2k187199 · Answer 9 · 2015-10-14 10:08:59Z

Scrum/Agile says that the people doing the work are entirely self-organising and in charge of their own technology. Getting the work done is their own responsibility.

This means that (in a perfect Scrum/Agile setting) when it comes to the technology stack, which components to use or reuse, what constitutes a good program, and any other question directly related to how the work gets done, management should not be involved, at all.

The only example you have that would involve management is "moving people to a different team", and even there it is really important to talk to the team members, because they'll be the ones who have to leave their current team and get up to speed with the new one.

The entire concept of "having decisions forced upon you by management" is decisively un-Agile.

So, if Apple adopts Scrum/Agile, then every employee has the right to know what the next version of iPhone looks like? — Oct 14 '15 at 10:15
Everyone involved should know, yes. Can't work on the thing if you don't know what it's going to look like. — Oct 14 '15 at 10:22
@Erik I've worked on the architecture of a server without having the faintest idea what color the case would be, or even what the product name was going to be. I got the information I needed to do my job, and no more. — Oct 14 '15 at 10:25
The Agile/Scrum paradigm breaks down long before you get to a work group the size of the entire company of Apple. — Oct 14 '15 at 12:30
Self-managed does not mean you have carte blanche to do whatever you want with technology. For companies of any reasonable size with multiple scrum teams, there will have to be decisions made on common technologies that all teams will have to adhere to. Some person or group in the company has to make those decisions and it is up to the company management to decide how much involvement developers have. — Oct 14 '15 at 12:39

Jim 4,495623 · Answer 10 · 2015-10-14 17:53:57Z