23 ms·

But see this article by Cal Newport which highlights how the Pullman Company increased production by limiting communication. http://calnewport.com/blog/2017/06/

by dpatru 9y ago

But see this article by Cal Newport which highlights how the Pullman Company increased production by limiting communication. http://calnewport.com/blog/2017/06/21/an-early-20th-century-lesson-on-the-difference-between-convenience-and-value/ http://calnewport.com/blog/2017/06/21/an-early-20th-century-... It seems that unrestricted communication slows down companies more than it speeds them up. Maybe at Tesla they already have ways to manage interruptions. Elon specifically mentions email and managers. Email can be read at the receiver's schedule. The part of the job of the manager is to protect the workers from distraction. "Try to email the manager who can best solve the problem." != "Feel free to interrupt anyone at any time."

tunesmith 9y ago
This reminds me of an old game theory exercise I worked that showed how adding a new "shortcut" road to a simple road map slowed traffic down for everyone, and removing it sped everything up. Thinking about it, I remember a bit more. Imagine two parallel roads, each with two segments. Both are southbound going from index 0 to index 1. A0-A1 is fast, A1-A2 is slow. B0-B1 is slow, B1-B2 is fast. Introduce a bridge (two-way I believe) going between A1 and B1. There were certain parameter assumptions (traffic levels) that meant it hurt more than it helped.
- damnfine 9y ago
  So what are the conditions where it hurts more? You set up the problem and then left us hanging...
  - tunesmith 9y ago
    Part of the traffic is a function of the fraction of people taking the road, so I can't describe it without using diagrams. However, I remember that it's called Braess' Paradox: https://en.wikipedia.org/wiki/Braess%27s_paradox https://en.wikipedia.org/wiki/Braess%27s_paradox And actually, the example I remember is stated in the mathematical example on that page if you scroll down. Applied to Musk, the answer isn't necessarily to go back to communicating through managers, but probably just to be more deliberate about designing traffic (communication) patterns when you see gluts happening.
SEJeff 9y ago
Have you ever been to Pullman? I have, and would question using its (ultimately failed) model as something good to replicate. It is south of Chicago and is just a rotting old town that once was full of trains and heavy in industry. It is a bit depressing to be honest seeing the previous grandeur. http://www.pullmanil.org http://www.pullmanil.org
Bartweiss 9y ago
This seems like a major risk at companies with software departments. The fastest way to solve a problem like "I need a report with all of this data" or "I can't login to the system" is to ask a programmer or DBA personally. But the best way is to go through some kind of channel that blocks simple requests at a managerial or IT level, so larger projects don't slip under the weight of random requests. The customer service model here is actually quite instructive. For someone with a 'real' problem, talking to a T1 rep is a useless waste of time. But customers still get routed through T1 because the alternative is eating up scarce time with simple issues. If I had to guess, a strategy like this works for Tesla because they've got a culture that supports it (i.e. "find the simplest solution") and a highly technical workforce. This looks like a serious case of a context-specific solution.
- ABCLAW 9y ago
  You're prematurely optimizing. If someone is roadblocked and cannot work (login issues, etc) their problem needs to be solved immediately. If resolving that issue is causing the programmer or DBA themselves to become roadblocked and slip behind on work, they themselves can communicate that too many people are falling through the cracks to HR or whomever else is involved and get the gears moving on a fix.
  - Bartweiss 9y ago
    Huh... I would have argued not doing it the way I described was prematurely optimizing. Specifically, it's about throwing 'processing speed' at a problem before checking whether that actually speeds up the solution. If someone is roadblocked on all their work, yeah, that should be solved immediately. Even if it's less theoretically efficient than some customer service system, it's necessary in terms of treating people with respect. But if someone has a specific task blocked? I'm not at all convinced escalating that to a programmer or DBA is a reasonable step one. Partly because the problem might be simple, mostly because switching time causes real inefficiencies. Of course, I'm assuming competent systems here. If "IT" is an outsourced department that just tells you how to plug things in, then yeah, everyone should escalate past them quickly. But if IT is actually knowledgeable, devops has sensible workflows, and so on, then I worry that out-of-band solutions are faster on each individual issue, but end up net-negative on overall company efficiency.

by dpatru 9y ago

tunesmith 9y ago

This reminds me of an old game theory exercise I worked that showed how adding a new "shortcut" road to a simple road map slowed traffic down for everyone, and removing it sped everything up. Thinking about it, I remember a bit more. Imagine two parallel roads, each with two segments. Both are southbound going from index 0 to index 1. A0-A1 is fast, A1-A2 is slow. B0-B1 is slow, B1-B2 is fast. Introduce a bridge (two-way I believe) going between A1 and B1. There were certain parameter assumptions (traffic levels) that meant it hurt more than it helped.

damnfine 9y ago
So what are the conditions where it hurts more? You set up the problem and then left us hanging...
- tunesmith 9y ago
  Part of the traffic is a function of the fraction of people taking the road, so I can't describe it without using diagrams. However, I remember that it's called Braess' Paradox: https://en.wikipedia.org/wiki/Braess%27s_paradox https://en.wikipedia.org/wiki/Braess%27s_paradox And actually, the example I remember is stated in the mathematical example on that page if you scroll down. Applied to Musk, the answer isn't necessarily to go back to communicating through managers, but probably just to be more deliberate about designing traffic (communication) patterns when you see gluts happening.

SEJeff 9y ago

Have you ever been to Pullman? I have, and would question using its (ultimately failed) model as something good to replicate. It is south of Chicago and is just a rotting old town that once was full of trains and heavy in industry. It is a bit depressing to be honest seeing the previous grandeur. http://www.pullmanil.org http://www.pullmanil.org

Bartweiss 9y ago

This seems like a major risk at companies with software departments. The fastest way to solve a problem like "I need a report with all of this data" or "I can't login to the system" is to ask a programmer or DBA personally. But the best way is to go through some kind of channel that blocks simple requests at a managerial or IT level, so larger projects don't slip under the weight of random requests. The customer service model here is actually quite instructive. For someone with a 'real' problem, talking to a T1 rep is a useless waste of time. But customers still get routed through T1 because the alternative is eating up scarce time with simple issues. If I had to guess, a strategy like this works for Tesla because they've got a culture that supports it (i.e. "find the simplest solution") and a highly technical workforce. This looks like a serious case of a context-specific solution.

ABCLAW 9y ago
You're prematurely optimizing. If someone is roadblocked and cannot work (login issues, etc) their problem needs to be solved immediately. If resolving that issue is causing the programmer or DBA themselves to become roadblocked and slip behind on work, they themselves can communicate that too many people are falling through the cracks to HR or whomever else is involved and get the gears moving on a fix.
- Bartweiss 9y ago
  Huh... I would have argued not doing it the way I described was prematurely optimizing. Specifically, it's about throwing 'processing speed' at a problem before checking whether that actually speeds up the solution. If someone is roadblocked on all their work, yeah, that should be solved immediately. Even if it's less theoretically efficient than some customer service system, it's necessary in terms of treating people with respect. But if someone has a specific task blocked? I'm not at all convinced escalating that to a programmer or DBA is a reasonable step one. Partly because the problem might be simple, mostly because switching time causes real inefficiencies. Of course, I'm assuming competent systems here. If "IT" is an outsourced department that just tells you how to plug things in, then yeah, everyone should escalate past them quickly. But if IT is actually knowledgeable, devops has sensible workflows, and so on, then I worry that out-of-band solutions are faster on each individual issue, but end up net-negative on overall company efficiency.