5 ms·

Every company over a certain size has a manager who explicitly puts together a rag tag team of cluelessness in order to "get stuff done" because they don't unde

Every company over a certain size has a manager who explicitly puts together a rag tag team of cluelessness in order to "get stuff done" because they don't understand the complexity of the stuff. They interpret push back as a lack of co-operation, rather than the requirement for sanity that it entails. Ideally, once they identify by trying to pull the trigger you can move them out of the company.

tgsovlerkhgsel 7y ago
The probability of such "get stuff done" goes up the more seemingly-pointless and painful, slow and bureaucratic processes are introduced. Many of these processes may be necessary, but it's also necessary to explain why, and to make them as fast and painless/frictionless as possible - especially as each single process in isolation may seem reasonable, but when stacked on top of each other, the "get stuff done" approach becomes a lot more tempting.
- ChuckMcM 7y ago
  Absolutely agree. And it's up to a company to insure that process isn't pointless or obfuscating the reason for its existence. The less clarity there is on the "why" the more creative the management will be. Of course, managers who say "I don't believe that will happen so I'm going to skip this part." should be walked out of the door to their car immediately. :-)
- carlmr 7y ago
  >especially as each single process in isolation may seem reasonable, but when stacked on top of each other, the "get stuff done" approach becomes a lot more tempting. Process stacking for me is one of the reasons why it's super painful to work in big companies if you want to get something done. As soon as somebody makes a mistake, they will add a little bit of process to ensure that never happens again. Individually, as you point out, that makes sense. But if you have to go through a 1000 item review checklist for a single line of code, then I can assure you that no human will be able to actually think through those 1000 items. But they will go through the motions to satisfy the process. Then because they have the checklist they don't think they have to think about it anymore. They make a mistake. It gets added to the checklist. I experienced situations where a single code change would take at least a month. This lead to people trying to save time on a) tests, b) any kind of refactoring, c) adapting libraries instead of writing your own implementation (because fixing the library would be 2 code changes and not just twice the process effort, but an actual committee had to decide about the library change first.) So a lot of process IMHO is the worst thing you can do for your code quality. Checklists are good, but they should be limited to a manageable number (e.g. 10 items, if you want to add something, you have to remove something less important first). It should also not be harder to do the right thing, e.g. centralizing functionality in libraries should be easier than.
  - zentiggr 7y ago
    It's a cool thing that software moves so much faster than other processes, like in my experience military grade weapon loading. Our sub would dock at the pier the day before, everyone but Weapons Department got the day off/in port duty day. Weapons Department would hold an all afternoon walkthrough of the entire process. Manpower locations and roles. Equipment setup and basic operations. Types, quantity, and sequence of weapons to take aboard. Expected timeframe / pace so that no one was expecting to have to hustle to catch up. And everything was in binders, with plastic strip edged pages and fresh grease pencils issued to everyone managing. Every one of those steps was a result of "Ok, crap, what do we rewrite to make sure (shudder) THAT NEVER happens again." And even so, on my fifth loadout party, I still missed a retaining strap and almost helped dump a torpedo in the harbor, except there was already a step right after mine with a separate checkbox that said "Aux handler has checked strap type/quantity/positioning for weapon type." Procedures are great for the things that need them. And when you have numerous teams/functions scattered about, procedures are even more necessary. And I do get that a lot of code is not likely to detonate under the companies' hull, per se.
  - _0ffh 7y ago
    >As soon as somebody makes a mistake, they will add a little bit of process to ensure that never happens again. To be fair, the other side of the medal is when it is simply not possible to get certain things done, because the need has not been anticipated when designing the processes. If you don't have the company political clout to get these processes amended, your only option is to wait until a customer is negatively affected, in order to drive the point home. Still, hustling (even if it is well-meaning) is of course not an acceptable solution.
  - Piskvorrr 7y ago
    Moreover, in this industry, a checklist is usually a reinvention of 18th century manufacturing process. A lot of the "needs checklist" can be transformed and automated into "do the integration tests pass?" Several orders of magnitude faster, as it doesn't need couriers on horseback to carry documents to and fro, or a live human imprimatur. Talk about repeating history...
asveikau 7y ago
I have seen the rag tag "get stuff done" team that works really well because they are staffed with people who know what they're doing. A team that knows better than to try to ship late Sunday for example, perhaps small and organizationally lax but experienced and disciplined. The issue can sometimes occur when the manager doesn't know that their rag tag team is not this special case, but actually clueless. Or have not learned to spot the difference, or that there is a difference.
- Piskvorrr 7y ago
  Bingo! The origin of the cargo cult, right there. "Look at that team: gets stuff done, and quickly! Therefore, I shall assemble a team at random, and push for speed at the expense of everything else. The results must surely manifest, for I am following the incantation!"
deleted 7y ago
[deleted]
perlpimp 7y ago
Incidentally Pirates of the Apple put together first Mac. Though not exactly rag-tag, but brilliant, just a counter example I suppose.
- redis_mlc 7y ago
  Well, the Mac was designed and developed by Apple engineers hand-picked by Steve Jobs. So it was an official long-term project with backing by the CEO. > just a counter example It took me a while to understand why HN'ers revel in "the counter-example." In mathematical proofs, you only need one counter-example to refute a proof or argument. Pedantic HN'ers seemingly fail to realize that mathematics and the real world are not the same thing.
  - deleted 7y ago
    [deleted]
  - pbhjpbhj 7y ago
    I think it's the opposite of what you're imagining. Refutation is generally a claim that the truth of the situation is more nuanced than a simplistic statement would make it seem. Here you're right to raise issue, but it seems the comment is merely trying to point out that 'not all [Scottish!?!] rag-tag teams are bad' and idea draw attention to some such teams being superb. Which seems a fair comment to me.
  - Angostura 7y ago
    I don't think that the goal here is refutation, its adding additional data-points give a more nuanced picture.
  - magduf 7y ago
    >In mathematical proofs, you only need one counter-example to refute a proof or argument. The things we're talking about here aren't mathematical axioms, they're general trends. One counter-example does not disprove a trend. Every real-life trend has exceptions, and it frequently is interesting to examine the exceptions to see why they bucked the trend.

tgsovlerkhgsel 7y ago

The probability of such "get stuff done" goes up the more seemingly-pointless and painful, slow and bureaucratic processes are introduced. Many of these processes may be necessary, but it's also necessary to explain why, and to make them as fast and painless/frictionless as possible - especially as each single process in isolation may seem reasonable, but when stacked on top of each other, the "get stuff done" approach becomes a lot more tempting.

ChuckMcM 7y ago
Absolutely agree. And it's up to a company to insure that process isn't pointless or obfuscating the reason for its existence. The less clarity there is on the "why" the more creative the management will be. Of course, managers who say "I don't believe that will happen so I'm going to skip this part." should be walked out of the door to their car immediately. :-)
carlmr 7y ago
>especially as each single process in isolation may seem reasonable, but when stacked on top of each other, the "get stuff done" approach becomes a lot more tempting. Process stacking for me is one of the reasons why it's super painful to work in big companies if you want to get something done. As soon as somebody makes a mistake, they will add a little bit of process to ensure that never happens again. Individually, as you point out, that makes sense. But if you have to go through a 1000 item review checklist for a single line of code, then I can assure you that no human will be able to actually think through those 1000 items. But they will go through the motions to satisfy the process. Then because they have the checklist they don't think they have to think about it anymore. They make a mistake. It gets added to the checklist. I experienced situations where a single code change would take at least a month. This lead to people trying to save time on a) tests, b) any kind of refactoring, c) adapting libraries instead of writing your own implementation (because fixing the library would be 2 code changes and not just twice the process effort, but an actual committee had to decide about the library change first.) So a lot of process IMHO is the worst thing you can do for your code quality. Checklists are good, but they should be limited to a manageable number (e.g. 10 items, if you want to add something, you have to remove something less important first). It should also not be harder to do the right thing, e.g. centralizing functionality in libraries should be easier than.
- zentiggr 7y ago
  It's a cool thing that software moves so much faster than other processes, like in my experience military grade weapon loading. Our sub would dock at the pier the day before, everyone but Weapons Department got the day off/in port duty day. Weapons Department would hold an all afternoon walkthrough of the entire process. Manpower locations and roles. Equipment setup and basic operations. Types, quantity, and sequence of weapons to take aboard. Expected timeframe / pace so that no one was expecting to have to hustle to catch up. And everything was in binders, with plastic strip edged pages and fresh grease pencils issued to everyone managing. Every one of those steps was a result of "Ok, crap, what do we rewrite to make sure (shudder) THAT NEVER happens again." And even so, on my fifth loadout party, I still missed a retaining strap and almost helped dump a torpedo in the harbor, except there was already a step right after mine with a separate checkbox that said "Aux handler has checked strap type/quantity/positioning for weapon type." Procedures are great for the things that need them. And when you have numerous teams/functions scattered about, procedures are even more necessary. And I do get that a lot of code is not likely to detonate under the companies' hull, per se.
- _0ffh 7y ago
  >As soon as somebody makes a mistake, they will add a little bit of process to ensure that never happens again. To be fair, the other side of the medal is when it is simply not possible to get certain things done, because the need has not been anticipated when designing the processes. If you don't have the company political clout to get these processes amended, your only option is to wait until a customer is negatively affected, in order to drive the point home. Still, hustling (even if it is well-meaning) is of course not an acceptable solution.
- Piskvorrr 7y ago
  Moreover, in this industry, a checklist is usually a reinvention of 18th century manufacturing process. A lot of the "needs checklist" can be transformed and automated into "do the integration tests pass?" Several orders of magnitude faster, as it doesn't need couriers on horseback to carry documents to and fro, or a live human imprimatur. Talk about repeating history...

asveikau 7y ago

I have seen the rag tag "get stuff done" team that works really well because they are staffed with people who know what they're doing. A team that knows better than to try to ship late Sunday for example, perhaps small and organizationally lax but experienced and disciplined. The issue can sometimes occur when the manager doesn't know that their rag tag team is not this special case, but actually clueless. Or have not learned to spot the difference, or that there is a difference.

Piskvorrr 7y ago
Bingo! The origin of the cargo cult, right there. "Look at that team: gets stuff done, and quickly! Therefore, I shall assemble a team at random, and push for speed at the expense of everything else. The results must surely manifest, for I am following the incantation!"

deleted 7y ago

[deleted]

perlpimp 7y ago

Incidentally Pirates of the Apple put together first Mac. Though not exactly rag-tag, but brilliant, just a counter example I suppose.

redis_mlc 7y ago
Well, the Mac was designed and developed by Apple engineers hand-picked by Steve Jobs. So it was an official long-term project with backing by the CEO. > just a counter example It took me a while to understand why HN'ers revel in "the counter-example." In mathematical proofs, you only need one counter-example to refute a proof or argument. Pedantic HN'ers seemingly fail to realize that mathematics and the real world are not the same thing.
- deleted 7y ago
  [deleted]
- pbhjpbhj 7y ago
  I think it's the opposite of what you're imagining. Refutation is generally a claim that the truth of the situation is more nuanced than a simplistic statement would make it seem. Here you're right to raise issue, but it seems the comment is merely trying to point out that 'not all [Scottish!?!] rag-tag teams are bad' and idea draw attention to some such teams being superb. Which seems a fair comment to me.
- Angostura 7y ago
  I don't think that the goal here is refutation, its adding additional data-points give a more nuanced picture.
- magduf 7y ago
  >In mathematical proofs, you only need one counter-example to refute a proof or argument. The things we're talking about here aren't mathematical axioms, they're general trends. One counter-example does not disprove a trend. Every real-life trend has exceptions, and it frequently is interesting to examine the exceptions to see why they bucked the trend.