4 ms·

That's why Basecamp is better suited for work in my opinion. Don't use chat to solve problems. Use longform text like messages. And avoid notifications. Allow

by myspy 7y ago

That's why Basecamp is better suited for work in my opinion. Don't use chat to solve problems. Use longform text like messages. And avoid notifications. Allow your team to response in a matter of hours/days, not minutes. Let them think about and rethink a problem or question. This requires to be able to work on a couple of problems at the same time. Divide the work accordingly. Or use the time waiting for a response to learn something. There's a quote going like this: The urgent is not important and the important is not always urgent.

iamnotacrook 7y ago
"Allow your team to response in a matter of hours/days, not minutes. Let them think about and rethink a problem or question." Is anyone using dsr55rhel? I need to reboot it.
- rgoulter 7y ago
  "Last week I needed to reboot dsr55rhel. I was blocked for 8 hours because of the way we communicate things. To avoid this next time, I suggest we: ..." "Last week I lost 3 days of my work because someone rebooted dsr55rhel and I didn't see the reply in time. To avoid this next time, I suggest we: ..." There are probably cases where it's necessary for multiple people to be communicating/collaborating on some issue simultaneously and synchronously. Most won't be. I think cases like "what if something comes up and you need multiple people" is a smell that something can be improved, rather than a common unavoidable problem.
- asdfasdf1234567 7y ago
  SLACK INSTALLED, 5 MINUTES LATER Is anyone using dsr55rhel? I need to reboot it. 0:00 Is anyone using dsr72rhel? I need to reboot it. 0:05 Is anyone using dsr21rhel? I need to reboot it. 0:09 Is anyone using dsr97rhel? I need to reboot it. 0:11 ..ad infinitum 1 Month Later, some over the top, ITIL compliant business-flow is setup to quash that nonsense. And now everyone is suffering the consequences with hyper bloated business process procedures. ...basically the disease, the cure, and the cure for the cure are all equal when killing productivity. It really comes down to people and discipline. You're either working with smart, competent, well adjusted adults, or you're not. If your organization is small, brilliant, tight ...then any/all decent tools can be utilized to maximum effectiveness, because again it's people. But the larger the organization, it mitigates any and all tools, even the best of tools, and it also mitigates the possibility of having a small collection of really smart, talented people. Smart people in this environment typically will feel suffocated in a few years, unless they are protected from the endless nonsense that large organizations naturally create. This is how brilliant managers operate, and the competitiveness is interesting to see. Savy manager, makes his way up the food chain by being a problem solver. How does he solve it? Pooling talent, shielding them, in exchange he has high expectations from them, they come through, all are heroes, but the manager gets majority of credit. He/she then gets moved to a higher level, or a group that tackles harder problems. He streamlines the group, gets rid of the dead weight, steals better talent from other teams, protects his team pushing the boundaries as granted to him/her due to previous successes, then uses the potential to solve problems that no one else can/wants-to solve. Wash Rinse Repeat. If someone regulary utilizes a broadcast to ask everyone "who is using this server, anyone on it, can I reboot it?" Something is terribly screwed up at that organization. And having Slack as the broadcast tool is just an enabler.
enraged_camel 7y ago
This doesn’t work well, because of this: “This requires to be able to work on a couple of problems at the same time.” ...which is a really bad idea, because context-switching carries a heavy productivity penalty. Many studies show this clearly: even though people may feel more productive when multi-tasking, they actually are much less productive, and the solutions they come up with to complex problems are more likely to be wrong because they haven’t spent as much time in the same context (i.e. asked for help, couldn’t get any on time, was forced to switch to another task/problem).
- sutterbomb 7y ago
  Working on two or three projects concurrently over the course of two or three weeks is not the same as multi-tasking. If you’re expected to immediately respond to things and have multiple projects going, yes that’ll be trouble. But if you’re able to pace your own work, and respond in hours/days, you can be more than capable of holding more than one thing in your head.
danpalmer 7y ago
> Allow your team to response in a matter of hours/days, not minutes. This does assume only one of the kinds of work that I mentioned though. If our database server goes down and the site is offline and we're losing money, that is when Slack shows its value. We have a full log of what's going on, we can rapidly communicate statuses to stakeholders, we can debug things in realtime even if a distributed team. I'd love to not have those sorts of times, but there's always going to be times like that for almost any business, any type of work. They can be minimised, but sometimes you just need fast communication. In that way, I see Slack as a better long-run conference call. I can dip in and out as needed, it's got rich information, it's easy to look back through history. For things email is good for – let's stick with email.

by myspy 7y ago

iamnotacrook 7y ago

"Allow your team to response in a matter of hours/days, not minutes. Let them think about and rethink a problem or question." Is anyone using dsr55rhel? I need to reboot it.

rgoulter 7y ago
"Last week I needed to reboot dsr55rhel. I was blocked for 8 hours because of the way we communicate things. To avoid this next time, I suggest we: ..." "Last week I lost 3 days of my work because someone rebooted dsr55rhel and I didn't see the reply in time. To avoid this next time, I suggest we: ..." There are probably cases where it's necessary for multiple people to be communicating/collaborating on some issue simultaneously and synchronously. Most won't be. I think cases like "what if something comes up and you need multiple people" is a smell that something can be improved, rather than a common unavoidable problem.
asdfasdf1234567 7y ago
SLACK INSTALLED, 5 MINUTES LATER Is anyone using dsr55rhel? I need to reboot it. 0:00 Is anyone using dsr72rhel? I need to reboot it. 0:05 Is anyone using dsr21rhel? I need to reboot it. 0:09 Is anyone using dsr97rhel? I need to reboot it. 0:11 ..ad infinitum 1 Month Later, some over the top, ITIL compliant business-flow is setup to quash that nonsense. And now everyone is suffering the consequences with hyper bloated business process procedures. ...basically the disease, the cure, and the cure for the cure are all equal when killing productivity. It really comes down to people and discipline. You're either working with smart, competent, well adjusted adults, or you're not. If your organization is small, brilliant, tight ...then any/all decent tools can be utilized to maximum effectiveness, because again it's people. But the larger the organization, it mitigates any and all tools, even the best of tools, and it also mitigates the possibility of having a small collection of really smart, talented people. Smart people in this environment typically will feel suffocated in a few years, unless they are protected from the endless nonsense that large organizations naturally create. This is how brilliant managers operate, and the competitiveness is interesting to see. Savy manager, makes his way up the food chain by being a problem solver. How does he solve it? Pooling talent, shielding them, in exchange he has high expectations from them, they come through, all are heroes, but the manager gets majority of credit. He/she then gets moved to a higher level, or a group that tackles harder problems. He streamlines the group, gets rid of the dead weight, steals better talent from other teams, protects his team pushing the boundaries as granted to him/her due to previous successes, then uses the potential to solve problems that no one else can/wants-to solve. Wash Rinse Repeat. If someone regulary utilizes a broadcast to ask everyone "who is using this server, anyone on it, can I reboot it?" Something is terribly screwed up at that organization. And having Slack as the broadcast tool is just an enabler.

enraged_camel 7y ago

This doesn’t work well, because of this: “This requires to be able to work on a couple of problems at the same time.” ...which is a really bad idea, because context-switching carries a heavy productivity penalty. Many studies show this clearly: even though people may feel more productive when multi-tasking, they actually are much less productive, and the solutions they come up with to complex problems are more likely to be wrong because they haven’t spent as much time in the same context (i.e. asked for help, couldn’t get any on time, was forced to switch to another task/problem).

sutterbomb 7y ago
Working on two or three projects concurrently over the course of two or three weeks is not the same as multi-tasking. If you’re expected to immediately respond to things and have multiple projects going, yes that’ll be trouble. But if you’re able to pace your own work, and respond in hours/days, you can be more than capable of holding more than one thing in your head.

danpalmer 7y ago

> Allow your team to response in a matter of hours/days, not minutes. This does assume only one of the kinds of work that I mentioned though. If our database server goes down and the site is offline and we're losing money, that is when Slack shows its value. We have a full log of what's going on, we can rapidly communicate statuses to stakeholders, we can debug things in realtime even if a distributed team. I'd love to not have those sorts of times, but there's always going to be times like that for almost any business, any type of work. They can be minimised, but sometimes you just need fast communication. In that way, I see Slack as a better long-run conference call. I can dip in and out as needed, it's got rich information, it's easy to look back through history. For things email is good for – let's stick with email.