8 ms·

For me the #1 reason why they are slow is because everything requires consensus or maybe another way of putting it it's hard for people to make a decision on th

For me the #1 reason why they are slow is because everything requires consensus or maybe another way of putting it it's hard for people to make a decision on their own. Let's say I want to change some part of the UI of some app. If I'm by myself I just change it. If I'm on a team first I have to convince whoever has the power to decide to change it to allow it to be changed, that might even be a whole committee. Then several people will be involved, likely a UX designer, possible a separate UI designer, all of which will have to discuss the feature and all of which also have other responsibilities. The larger the company the worse this usually gets. Maybe the change has to be run by the security team to make sure the new UI is not a security issue. Maybe it has to run by the privacy team to make sure it's not going to leak data. Maybe it has to be run by an inclusivity team to make sure it's not offensive in some culture I'm not familiar with. Maybe it has to be run by a localization team to make sure it will work in every language. All of those things add time. Maybe they are all required and good, especially at a large company with a global marketplace but they certainly add to the time taken to do something that a tiny team wouldn't do.

killjoywashere 8y ago
A lot of answers to these questions, and the questions themselves, come from further down the food chain. The flip side of the coin is that no start-up is moving a billion tons of rice, or can park an army off a foreign shore in a week, or lay 10,000 tons of steel rail across a continent every day, or delivery a million packages a day, or make 10,000 processors a day, each with the complexity of the entire European system of roads. So speed is relative to the size of the task at hand. Large enterprise can move big things so fast it literally takes the air out of the room.
- monkeydreams 8y ago
  > So speed is relative to the size of the task at hand. I think of organisational decision making like organic decision making - that the speed of the organisation's reactions are dependent upon its frame of reference. The frame of reference here is the time between sensing and reacting. The eyes and ears of small businesses are very close to the brains, and so decisions can be made rapidly by the small number of people who have capability to marshal resources into a response. Enterprises have layers of processing between the eyes and brains, along with many more sensors than a small business, meaning that questions take longer to be settled and decisions made. However no small business can wield the same power as a large organisation when the army of deciders all focus on a single outcome.
- eismcc 8y ago
  Organizational physics: Newton’s first and second laws seem relevant. https://en.m.wikipedia.org/wiki/Newton%27s_laws_of_motion https://en.m.wikipedia.org/wiki/Newton%27s_laws_of_motion
- saiya-jin 8y ago
  You're missing one piece which degrades performance of all corporations over time - bureaucracy with politics. I don't mean the sane one, I mean processes for the sake of processes, people entrenched in their comfortable managerial positions, battling any change that doesn't benefit them directly. I mean brutal management pyramids, so often seen in older corporations or banks for example. It comes naturally over time, every single time. Organization can fight it, but it needs to be a dedicated effort and priority. If let on its own, complexity arises. I've seen medium-sized young companies trying hard to have flat hierarchy and least amount of processes, committees etc. It worked. It really did. But everybody understood this is the goal, it was clearly communicated. It attracted amazing talent of brilliant people fed up with the (common) opposite. I can see now in oldish bank how a simple change might involve 20 people having their say, often managers with their own political agenda not always aligned with what's best for the employer. Stuff that gets actually developed in 2-3 MDs takes overall easily 10-20x more because of this.
  - oblio 8y ago
    That's gross, but the overall organization is still efficient (or it has some sort of monopoly or huge moat). Otherwise it would be completely out of business by now.
    - barrow-rider 8y ago
      It's efficient at it's stated tasks. Usually this is tied to stock prices. I'm working at a Fortune 500 currently that does a lot of chemical manufacturing. Outside of delivering boatloads of chems, everything in the company is a constant clusterfuck. Stock price stays alright so nothing changes.
      - tormeh 8y ago
        I think this is some kind of law: Every company is good at only those things where external pressure is high, and usually those are sales and whatever they are selling. Everything else has little external pressure to work well, and because the natural state of things is suckage and stagnation, everything else sucks and is stagnant.
tixocloud 8y ago
It goes far more beyond that. We have an IT team that makes decisions without going through the consensus route. I strongly believe the agility of an organisation can be addressed with: - number of projects/initiatives worked on - accountability of said projects/initiatives - technology to facilitate the automation of admin to track these projects/initiatives - collaboration tools for knowledge sharing - mindset shift And this is not something for just the management team or the employees but a collective agreement on this is how we work. It goes back to building and commuting to maintaining a high performing culture. It needs buy-in from everyone on what the expectations are and what the rules of engagement should be. Any sign of politics, bureaucracy? Management needs to snuff it out. The more we accept certain behaviours, the more we allow it to fester within the organisation. Too many projects being worked on just causes backlog and confusion. We did have an agile coach to come in but the organisation remains the same.
qw 8y ago
Even if you manage to go through all that, you still need it to be accepted by the product owner and prioritized into a sprint. Good luck fighting for your feature, when account managers, designers and other "competitors" are doing the same. You're just a developer, what do you know about how the application you work on daily can be improved... They have hired other people for that.
- matthewmacleod 8y ago
  Sounds like you need to find a new job. In my organisation, and others I've worked with, input from developers is treated roughly equally with input from other stakeholders. If anything, developers seem to get angsty when the organisation doesn't bend to do whatever they feel is most necessary immediately, failing to realise that there are also other priorities coming from other parts of the business.
alecco 8y ago
Yes. The rule of people without self-awareness and deep in Dunning-Kruger territory. And the fallacy of popularity bringing good solutions.
mikehollinger 8y ago
Put more simply - there are more people who can say “No.” Saying no is safer than saying “Yes.” When only a single “No” will halt a project, the chance of getting stuck is higher.
- duxup 8y ago
  Also the default state for most people for any given change is ignorance / no reason to change. Thus the default "no". At a non coding job in the past, I've had to explain the same change to five different people or teams in dramatically different ways to get a job done sometimes. If you saw me talk to these different groups you might not know I was even talking about the same thing each time....but I was.
- VintageCool 8y ago
  What Francis Fukuyama would call a "vetocracy".
beat 8y ago
Others get a say in the enterprise because your decisions affect others. The larger the scope, the more people your decisions affect. Ever seen the login system for a multimillion dollar app broken because someone was able to end-run around the slow boring stupid release process and just shove a little UI change in production? I have. And when the entire system of lead engineers is out trying to figure out what got broken and how it got broken, and managers are trying to get the information they need to explain to their managers why the company just got publicly embarrassed and lost thousands of dollars, their response is not going to be sympathy at your struggles with being slowed down by all this stupid consensus bureaucracy.
- existencebox 8y ago
  Speaking as someone big-co track record... that seems like a bit of a strawman though, doesn't it? Not every team, in fact, most teams are not going to be the pivotal shared component behind billion dollar pipelines. Enterprise internal policies re: things like accessibility and security review are _hardly_ reflecting of that, since it's impossible to be fine grained and accurate, so they typically apply "a big hammer" across most groups and "an even bigger hammer" across others. This is close to heart as I've grown a few teams from "small green-field experimental 3 people groups" to full on 8-10 person launched feature teams, and watched the process slow to a crawl despite the additional manpower. There's definitely a _reason_ for some of the bigco paranoia, but being flexible and accomadative in this sense is certainly not one of our strong points, so you usually get a decent amount of institutional boilerplate/plumbing work too, _especially_ when some of these side groups (e.g. UI) have a vested interest in having their fingers in as many pies as possible. A somewhat tongue and cheek but accurate picture to draw: I've seen a dropdown menu go from being "code it up before lunch" to "3 weeks of meetings, multiple reviews, and demos in front of stakeholders" task. Were some parts of that useful? Sure. All of it? Probably not. (To be clear; I don't actually take issue with much of the conceptual process, and like that there's some amount of oversight, but the nature in which it gets placed on teams is often 1. often not fully aligned with their actual "threat model" and prioritization in whatever space this is and 2. often given with inopportune timings and without a good support system. I call out the negatives above pretty exclusively because I think a bigCo _could_ do the processi-fication with a lighter touch and serve the same ends.)

killjoywashere 8y ago

A lot of answers to these questions, and the questions themselves, come from further down the food chain. The flip side of the coin is that no start-up is moving a billion tons of rice, or can park an army off a foreign shore in a week, or lay 10,000 tons of steel rail across a continent every day, or delivery a million packages a day, or make 10,000 processors a day, each with the complexity of the entire European system of roads. So speed is relative to the size of the task at hand. Large enterprise can move big things so fast it literally takes the air out of the room.

monkeydreams 8y ago
> So speed is relative to the size of the task at hand. I think of organisational decision making like organic decision making - that the speed of the organisation's reactions are dependent upon its frame of reference. The frame of reference here is the time between sensing and reacting. The eyes and ears of small businesses are very close to the brains, and so decisions can be made rapidly by the small number of people who have capability to marshal resources into a response. Enterprises have layers of processing between the eyes and brains, along with many more sensors than a small business, meaning that questions take longer to be settled and decisions made. However no small business can wield the same power as a large organisation when the army of deciders all focus on a single outcome.
eismcc 8y ago
Organizational physics: Newton’s first and second laws seem relevant. https://en.m.wikipedia.org/wiki/Newton%27s_laws_of_motion https://en.m.wikipedia.org/wiki/Newton%27s_laws_of_motion
saiya-jin 8y ago
You're missing one piece which degrades performance of all corporations over time - bureaucracy with politics. I don't mean the sane one, I mean processes for the sake of processes, people entrenched in their comfortable managerial positions, battling any change that doesn't benefit them directly. I mean brutal management pyramids, so often seen in older corporations or banks for example. It comes naturally over time, every single time. Organization can fight it, but it needs to be a dedicated effort and priority. If let on its own, complexity arises. I've seen medium-sized young companies trying hard to have flat hierarchy and least amount of processes, committees etc. It worked. It really did. But everybody understood this is the goal, it was clearly communicated. It attracted amazing talent of brilliant people fed up with the (common) opposite. I can see now in oldish bank how a simple change might involve 20 people having their say, often managers with their own political agenda not always aligned with what's best for the employer. Stuff that gets actually developed in 2-3 MDs takes overall easily 10-20x more because of this.
- oblio 8y ago
  That's gross, but the overall organization is still efficient (or it has some sort of monopoly or huge moat). Otherwise it would be completely out of business by now.
  - barrow-rider 8y ago
    It's efficient at it's stated tasks. Usually this is tied to stock prices. I'm working at a Fortune 500 currently that does a lot of chemical manufacturing. Outside of delivering boatloads of chems, everything in the company is a constant clusterfuck. Stock price stays alright so nothing changes.
    - tormeh 8y ago
      I think this is some kind of law: Every company is good at only those things where external pressure is high, and usually those are sales and whatever they are selling. Everything else has little external pressure to work well, and because the natural state of things is suckage and stagnation, everything else sucks and is stagnant.

tixocloud 8y ago

It goes far more beyond that. We have an IT team that makes decisions without going through the consensus route. I strongly believe the agility of an organisation can be addressed with: - number of projects/initiatives worked on - accountability of said projects/initiatives - technology to facilitate the automation of admin to track these projects/initiatives - collaboration tools for knowledge sharing - mindset shift And this is not something for just the management team or the employees but a collective agreement on this is how we work. It goes back to building and commuting to maintaining a high performing culture. It needs buy-in from everyone on what the expectations are and what the rules of engagement should be. Any sign of politics, bureaucracy? Management needs to snuff it out. The more we accept certain behaviours, the more we allow it to fester within the organisation. Too many projects being worked on just causes backlog and confusion. We did have an agile coach to come in but the organisation remains the same.

qw 8y ago

Even if you manage to go through all that, you still need it to be accepted by the product owner and prioritized into a sprint. Good luck fighting for your feature, when account managers, designers and other "competitors" are doing the same. You're just a developer, what do you know about how the application you work on daily can be improved... They have hired other people for that.

matthewmacleod 8y ago
Sounds like you need to find a new job. In my organisation, and others I've worked with, input from developers is treated roughly equally with input from other stakeholders. If anything, developers seem to get angsty when the organisation doesn't bend to do whatever they feel is most necessary immediately, failing to realise that there are also other priorities coming from other parts of the business.

alecco 8y ago

Yes. The rule of people without self-awareness and deep in Dunning-Kruger territory. And the fallacy of popularity bringing good solutions.

mikehollinger 8y ago

Put more simply - there are more people who can say “No.” Saying no is safer than saying “Yes.” When only a single “No” will halt a project, the chance of getting stuck is higher.

duxup 8y ago
Also the default state for most people for any given change is ignorance / no reason to change. Thus the default "no". At a non coding job in the past, I've had to explain the same change to five different people or teams in dramatically different ways to get a job done sometimes. If you saw me talk to these different groups you might not know I was even talking about the same thing each time....but I was.
VintageCool 8y ago
What Francis Fukuyama would call a "vetocracy".

beat 8y ago

Others get a say in the enterprise because your decisions affect others. The larger the scope, the more people your decisions affect. Ever seen the login system for a multimillion dollar app broken because someone was able to end-run around the slow boring stupid release process and just shove a little UI change in production? I have. And when the entire system of lead engineers is out trying to figure out what got broken and how it got broken, and managers are trying to get the information they need to explain to their managers why the company just got publicly embarrassed and lost thousands of dollars, their response is not going to be sympathy at your struggles with being slowed down by all this stupid consensus bureaucracy.

existencebox 8y ago
Speaking as someone big-co track record... that seems like a bit of a strawman though, doesn't it? Not every team, in fact, most teams are not going to be the pivotal shared component behind billion dollar pipelines. Enterprise internal policies re: things like accessibility and security review are _hardly_ reflecting of that, since it's impossible to be fine grained and accurate, so they typically apply "a big hammer" across most groups and "an even bigger hammer" across others. This is close to heart as I've grown a few teams from "small green-field experimental 3 people groups" to full on 8-10 person launched feature teams, and watched the process slow to a crawl despite the additional manpower. There's definitely a _reason_ for some of the bigco paranoia, but being flexible and accomadative in this sense is certainly not one of our strong points, so you usually get a decent amount of institutional boilerplate/plumbing work too, _especially_ when some of these side groups (e.g. UI) have a vested interest in having their fingers in as many pies as possible. A somewhat tongue and cheek but accurate picture to draw: I've seen a dropdown menu go from being "code it up before lunch" to "3 weeks of meetings, multiple reviews, and demos in front of stakeholders" task. Were some parts of that useful? Sure. All of it? Probably not. (To be clear; I don't actually take issue with much of the conceptual process, and like that there's some amount of oversight, but the nature in which it gets placed on teams is often 1. often not fully aligned with their actual "threat model" and prioritization in whatever space this is and 2. often given with inopportune timings and without a good support system. I call out the negatives above pretty exclusively because I think a bigCo _could_ do the processi-fication with a lighter touch and serve the same ends.)