This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
I really got a kick out of "Good luck, chumps", which Maxine thinks she's thinking to herself but actually says aloud. I've had similar experiences and can totally relate to having to dig myself out of a situation I got myself into by accidentally saying what I meant to just think to myself. I also like how succinctly it sums up Maxine's state of mind at that point. 🙂
I really got a kick out of "Good luck, chumps", which Maxine thinks she's thinking to herself but actually says aloud. I've had similar experiences and can totally relate to having to dig myself out of a situation I got myself into by accidentally saying what I meant to just think to myself. I also like how succinctly it sums up Maxine's state of mind at that point. 🙂
The nightmare of every tech company? https://www.developer-tech.com/news/2020/jan/07/starbucks-api-key-found-public-github-repository-reports/
Maxine took the blame for an outage while she was out of the office. In my mind, her boss didn't stand up for her and make the outage a "blameless" issue. They should have focused on what the Root Cause was instead of finding someone to blame. I agree there may be more than one cause, but it is my understanding/experience that when a root cause analysis is done, the multiple causes would come to light. I should have said, they should conduct a Root Cause Analysis or a Postmortem on what happened. Thanks for clarifying there may be many causes and not just one item.
I agree about the blameless part, but not about there being a 'root cause' for incidents. There are always multiple causes.
https://www.kitchensoap.com/2012/02/10/each-necessary-but-only-jointly-sufficient/
I was listening to chapters 6 and 7 this morning. Specifically the whole bit about the 3 network switches being consolidated into one. This decision caused a ton of pain for coordinating changes and eventually led to a week long outage at Parts Unlimited. It got me thinking about all the consolidation work (for systems/infrastructure) we have done the last 9 years at my organization. The lense I've been looking through was "consolidation in the name of simpler management". Less management consoles, less disparate systems to patch/maintain/pay maintenance on, better visibility into the entire system. However, now I'm at a bit of a crossroads in my thought process. We are looking to replace our ancient PBX. It's physical and uses digital phones. It's almost entirely decoupled from the network and virtualization infrastructure. If we have an outage in the datacenter, our staff can still make and take calls with patients. All the modern PBXs are either cloud or on-prem virtual. My instincts tell me to go with on-prem virtual; however, the new system (whatever it is) will definitely be tightly coupled with the network. This is because all the phones are VOIP instead of digital. Today, the PBX vendor can't blame the network vendor when we have an issue. However, I could see that becoming "a thing" with this new system and architecture. We can't afford to completely segregate phones and other network traffic at the physical layer. That doubles the cost of switches and fiber connectivity. However, if we have an outage in the datacenter (despite all components being N+1), phones will be offline. This has definitely caused me to rethink this PBX design decision in a different way. :thinking_face:
I was listening to chapters 6 and 7 this morning. Specifically the whole bit about the 3 network switches being consolidated into one. This decision caused a ton of pain for coordinating changes and eventually led to a week long outage at Parts Unlimited. It got me thinking about all the consolidation work (for systems/infrastructure) we have done the last 9 years at my organization. The lense I've been looking through was "consolidation in the name of simpler management". Less management consoles, less disparate systems to patch/maintain/pay maintenance on, better visibility into the entire system. However, now I'm at a bit of a crossroads in my thought process. We are looking to replace our ancient PBX. It's physical and uses digital phones. It's almost entirely decoupled from the network and virtualization infrastructure. If we have an outage in the datacenter, our staff can still make and take calls with patients. All the modern PBXs are either cloud or on-prem virtual. My instincts tell me to go with on-prem virtual; however, the new system (whatever it is) will definitely be tightly coupled with the network. This is because all the phones are VOIP instead of digital. Today, the PBX vendor can't blame the network vendor when we have an issue. However, I could see that becoming "a thing" with this new system and architecture. We can't afford to completely segregate phones and other network traffic at the physical layer. That doubles the cost of switches and fiber connectivity. However, if we have an outage in the datacenter (despite all components being N+1), phones will be offline. This has definitely caused me to rethink this PBX design decision in a different way. :thinking_face:
Following the thread of getting people in the same room - I'm interested in people's experience solving the problem with their existing remote teams. The idea of "if we're talking, we're sharing video" appeals to me. However, telling existing remote workers they now need an active camera feels like big brother. I could see it quickly generating resentment. I've been able to get a standing weekly meeting using video, and it's a big improvement. I think normalizing it would provide a boost to collaboration, but not if it's forced on the team members.
Following the thread of getting people in the same room - I'm interested in people's experience solving the problem with their existing remote teams. The idea of "if we're talking, we're sharing video" appeals to me. However, telling existing remote workers they now need an active camera feels like big brother. I could see it quickly generating resentment. I've been able to get a standing weekly meeting using video, and it's a big improvement. I think normalizing it would provide a boost to collaboration, but not if it's forced on the team members.
@US8GKMEAC I work for a Construction company that is heavily decentralised across New Zealand, and we have been working through how to help these people collaborate more. We’ve found MS Teams has supported this very well with the different capabilities built into Teams and the add-on (eg Trello) that are available. It’s the mix of presence (is the person available) with text chat, p2p video and multi-person meeting functionality that helps so much to reduce the friction. Video certainly helps, and it doesn’t need to be intrusive (I think @US9PHLWCX’s approach makes a lot of sense), but it is the mix of capabilities that matters. One option on it’s own is not enough. And have a look at Remote: Office Not Required for some real world experience of distributed teams. https://www.amazon.com/gp/product/B00CZ7OC46/ref=kinw_myk_ro_title But mostly, it will only work when there is a reason to collaborate. The key question to ask is how both people (or groups) will see benefit from the collaboration - until that is clear it will be a struggle. Having all the people in one room doesn’t create the pre-conditions for collaboration.
<!here> It’s almost noon in Portland, OR, the hometown of IT Rev so we thought we’d give some food for thought while we grab some lunch:
<!here> It’s almost noon in Portland, OR, the hometown of IT Rev so we thought we’d give some food for thought while we grab some lunch:
@genek I was responding to a comment on colllaboration and just did a quick search through the TUP, and there are three occurences of “collab” as a word root, and 13 of “coord”. I’ve always viewed coordination relating to separate independent activities needing to be organised, and collaboration relating to interdependent activites. Is there a particular reason why you have used “coordination” so much more frequently than “collaboration”?