This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-10-14
Channels
- # ask-the-speaker-track-1 (411)
- # ask-the-speaker-track-2 (347)
- # ask-the-speaker-track-3 (540)
- # ask-the-speaker-track-4 (399)
- # bof-american-airlines (2)
- # bof-arch-engineering-ops (10)
- # bof-covid-19-lessons (1)
- # bof-cust-biz-tech-divide (10)
- # bof-leadership-culture-learning (4)
- # bof-next-gen-ops (8)
- # bof-overcoming-old-wow (3)
- # bof-project-to-product (2)
- # bof-sec-audit-compliance-grc (37)
- # bof-transformation-journeys (1)
- # bof-working-with-data (2)
- # demos (78)
- # discussion-main (1226)
- # games (43)
- # happy-hour (195)
- # help (76)
- # hiring (20)
- # lean-coffee (47)
- # networking (17)
- # project-to-product (1)
- # psychological-safety (10)
- # summit-info (249)
- # summit-stories (23)
- # xpo-delphix (25)
- # xpo-digitalai-accelerates-software-delivery (3)
- # xpo-harness (1)
- # xpo-hcl-software-devops (5)
- # xpo-infosys-enterprise-agile-devops (6)
- # xpo-instana (4)
- # xpo-itmethods-manageddevopssaas (1)
- # xpo-itrevolution (18)
- # xpo-launchdarkly (6)
- # xpo-logdna (2)
- # xpo-moogsoft (4)
- # xpo-muse (2)
- # xpo-nowsecure-mobile-devsecops (6)
- # xpo-opsani (7)
- # xpo-pagerduty (19)
- # xpo-pc-devops-qualifications (3)
- # xpo-planview-tasktop (43)
- # xpo-plutora-vsm (3)
- # xpo-redgatesoftware-compliant-database-devops (6)
- # xpo-servicenow (14)
- # xpo-snyk (3)
- # xpo-sonatype (7)
- # xpo-split (2)
- # xpo-sysdig (15)
- # xpo-teamform-teamops-at-scale (4)
- # xpo-transposit (11)
- # xpo-tricentis-continuous-testing (1)
I think that's coming from the earlier keynote from the Airforce. I'd argue you need to bring in new blood, that's really the only way IMHO
and from both sides, from the grass roots but any change there will need support from an executive, so usually you need someone to shake up the executive level.
Would be amazing to have a deep dive techniques on how to implement Flow Framework! I´m working with my team trying to solve this puzzle 🙂
You might want to ask again in #ask-the-speaker-plenary
Hmm. Is anyone hearing from the right speaker only?
@jillmead2018 Lead time for a laptop? How about a single firewall port opened? 😄
@jillmead2018 crushing the visuals in this presentation
ok no wonder they hated your process
@edwmarshall3app Yep. True story. I cannot tell you how many times chairs were flipped over and flying in the air. @truestory
Absolute best production value I've seen at DOES! Very jealous @jillmead2018
In your opinion, should every company be transitioning to Agile? Is there a typical size of company by revenue, #employees, #customers or other metrics that make some companies better suited to transition to Agile development?
@scott.dedoes I think any organization would benefit from embracing the agile mindset and behaviors.
If some of the POs who are so much better off would have this reflective power.
I wonder how often the 75+ questions were answered with the “known acceptable” answers as a “check the box” exercise. (love the cow paths analogy)
LOL. It is much more meaningful to say process fat. It gives you the visual element.
@jillmead2018 very compelling and well-presented story
I have a client who have a multi-page review checklist (that has grown exactly the way @jillmead2018 describes here - issue -> bandaid; issue -> bandaid x100). And then at the bottom of the document was a signature line that said "I certify that all these are correct and will be held responsible if there is an error." How about that for creating speed!
You know, it was for a "real" product, not technology. So that checklist is okay. :rolling_on_the_floor_laughing: Even better - as you and Dr Spear described earlier - the checklists accrete over time. No one has any idea why those elements are there, but goodness knows they can't be removed. Thanks for your story of blowing this up!
@jillmead2018 Did people ever ask you what's going on with you?
NPS of 60 is fantastic!
(esp for a process everyone hates)!
Our customers were so thankful for a leaner approach. Honestly - they were tickled.
@jillmead2018 When you pull back changes are you doing this with Feature Flags? If so, were you using a system you build in-house or a 3rd party solution?
At the time we had ServiceNow as our IT Service Management tool. We created a extraction layer for our API's. Many of our engineers utilized Github as their code repository. Nope - at the time we did not utilize feature flags.
@jillmead2018 how did you decentralize your Enterprise CAB? What did that look like after?
@lpagnacco We empowered the portfolio owners to determine whether and how they wanted to meet to review changes. All of this had to do with accountability. They were no longer hiding behind a security blanket of a enterprise CAB meeting.
"We had the worst NPS within IT... to a score of 60, which is amazing.". — OMG, so good, @jillmead2018 . (Sorry for duplicate Slack account. Using it from my iPad. :)
@genek Yeah - it was pretty amazing. I think users were so thankful for a lean approach after many years of circus acts and wild escapades.
"Other teams deleted the Dumpster Fire emoji in reference to us." So good!!!
(@jillmead2018 Where were these Dumpster Fire emojis? In Slack?)
I am making a shortlist of people to send this to 😉
CAB is really about risk management. When you think in those terms, you focus on automation, unit tests, canary testing, etc. Then you can get rid of CAB.
I agree, but sometimes CAB is be about awareness, especially if you're rolling out something that other product teams can leverage
Awareness leads to dependency management. Always assume your dependency is going to fail. How is your service going to respond?
We literally have implemented a “low risk CAB” which is one person (the product owner) pressing a button to approve deployment at any time they like, provided the automated pipeline has passed all its stages.
It’s not for all of our 400ish services, only a selected few that are able to actually pass the gates. But more and more are getting there.
@lpagnacco There are other ways to provide visibility and awareness than holding a change approval board meeting.
@cncook001 Risk management or postponement?
"OVER THE THREE YEARS" . That's how long it takes, minimum, to make significant lasting changes 👍
i never cried but i have wanted to punch people in the face 🙂
@jonathansmart1 Does it have to be three years? I know it usually is, but does it really really have to?
Depends. Size, current state, history, behavioural norms. In my experience for most large, traditional, firms, the horses it's 3 to 5 to 7 years for lasting change
It takes at least 3 years to have a chance to break past having just built a cargo cult.
In this story, you are changing your own behaviour. So that should be a pretty empowered position to create change.
Sure, you are not "enlightened" to begin with, so that will slow you down.
But okay, I have not started with traditional firms from the very beginning, so something has always been happening before my time and some of the long-term change has been rather easy and fast and some has taken years.
Individual change can happen fairly quickly. Persistent organisational change takes longer. In both individual and organisational change, it’s only the first step. They also then have to fight their way through Dreyfus or Shu Ha Ri or whatever flavour of skills assessment you want.
Uhm, yeah. 11 months of skills assessment run by me and counting.
Great job @jillmead2018 using the cinematic format for your talk. Super awesome! I felt like I was watching an impactful documentary on Netflix!
@jillmead2018 - so you teased the e-guide - where do we get the details for that?
That release cycle is similar to our vehicle release cycle @james.simon1
I think there were only 6 or 8 Gates internally (suppliers had their own)
Yeah MD-102 is just a particularly fine specimen of what lots of organizations have
With your experiments were you trying this across the whole organization or trying with a single team first to scale up later?
That's the power of it - you CAN just start with one team, show success, then expand out
The big project - USCIS Transformation - was about 20 teams. We were introducing it elsewhere in the organization at the same time
The 20 teams were drawn from 4 contractors, all working in parallel on the same codebase with CI/CD
I'd say there is an opportunity cost or cost of delay to not scaling up quickly, once you've demonstrated value
That was just a joke Sutherland and Schwaber were playing on us all, right?
My point is that bureaucracy comes from a lot of places and for lots of reasons
Well, that would invalidate most of the usual "Scrum" teams. However, it would invalidate the true "beyond Scrum" teams as well... however the latter would not care.
An it IS bureaucratic. It prescribes that you should talk every day with your team.
I haven't asked Schwaber but I always assumed they were trying to avoid the problem of https://ronjeffries.com/xprog/articles/jatbaseball/.
Some people (and systems?) are very attracted to Rules and Order
https://en.wikipedia.org/wiki/Controversies_in_professional_sumo#Women_and_sumo
my thought about Scrum being rigid: "You've become the very thing you swore to destroy" 🙂 - Obi-wan
There is a lot of structure in Scrum.
Jedi practicing Agile -> Jedi Scrum
@ganga.n Yeah, it's funny, though. Scrum deliberately provides structure within which you can continuously improve
The rules are there for certain reasons... but when the underlying reasons change, the rules are no longer applicable — but now a new iteration needs to begin to change the rules...
For me it seems using a strong structure like scrum is good for getting started then improving away from as you mature. Thoughts?
I’ve found it’s easy to create a policy, but super hard to shut it down
"This policy becomes invalid based on the following terms:"...
You can lead with personality, excel and structure. You need a bit of everything but not in excess and not in a counterproductive way.
@james.simon1 this is how I use it/explain it for new teams - follow the rules rigidly to start. Once you have that working, then start looking for ways to improve. A lot of teams want to start with lots of modifications to suit their needs!
Shu-Ha-Ri, I guess? Start with the rules first before trying something different right away..?
walking before running, shu-ha-ri... whatever flavor you like.
@james.simon1 I know what you mean, but I'm not so sure. If there's a better way, why not just go straight to the better way? I'd say that a flow-based approach, minimizing cycle time, keeping low WIP is just as rigorous as Scrum but arguably more effective
@nickeggleston "Some people (and systems?) are very attracted to Rules and Order" --- Yes, very much so. Reminds me of "Jack" in Golding's "Lord of the Flies" (not to be confused with Ralph). Maybe that relates to one of the areas in the Cynefin framework?
"we wrote a management instruction to explain what policy compliance meant for our teams" - this is a ninja move
@james.simon1 There is a gaping pitfall of not explaining that every event in Scrum is about learning together. If that does not stick, it becomes paint by numbers.
Oh I agree. I keep trying to drill home that that is what all of this about
Sure, when you see that Scrum has this set of events to have a 360 learning together culture, you can replace all the parts.
Frameworks in general should be seen as a crawl state, with walk, run, and fly to follow through experimentation and continuous improvement in the context of the team using them.
This story is incredibly entertaining for some reason. Definitely getting the book.
@mark.fuller126 You'd have to convince me that it's necessary to crawl and walk before you fly. I'm not sure it's true
I have spent months in full on combat with management over this. You don't get mature at doing the right thing, by doing the wrong thing
yes @james.simon1 that's my point of view. It's really a question of change leadership
Its a thought provoking point. Can a person become an expert at something without any practice or learning along the way? From my perspective, if the team is heading in the right direction and dictating the speed of change themselves, the growth and learning can be very beneficial.
You can learn by doing or watching others' mistakes.
I am leaning towards having to walk before running but it does not have to be so many steps, if you know your nervous system well enough.
Not sure it's a gradient of experience. You don't need to learn to groom backlogs before you learn to minimize cycle time - they're different skills. Becoming good at grooming backlogs doesn;t make you get better at minimi9zing cycle times
Sure, you need practice, but not by practicing something different. I am being asked to lead iterative design, because we aren't "mature enough" at iteration to add development yet
I teach Scrum one event at a time and get that to a great level and then move on. That's like running every seventh step or so.
and you just don't get good at developing software, by not developing software
Remember the opportunity cost / cost of delay of only going halfway until you feel "ready" to go the rest of the way
CoD seems to be impossible to teach to a lot of people. Does not stop me from trying, though.
@ferrix I am definitely in favor of learning by doing instead of by watching, which is why I think you have to have some of the experiential learning to get to great improvements and levels of maturity.
@mark.fuller126 Let's take an abstract example: stand-up comedy. Not so abstract to me. In an open mic night there are 15 comedians and I have 5 minutes. By watching the others bomb and succeed, I can amplify my learning and get an edge. It simply has to be deliberate observation.
In terms of Scrum, it could be replicating the better experiments based on others' learning.
@mark.fuller126 The learning isn't up to a mastery level unless you do it yourself, but you will start recognizing the moments when you are screwing up just like that other guy and this is how that mistake is made.
So you steal some of your "oh shits" from others and you can possibly avoid some in the process.
@ferrix I agree you can learn from others mistakes. We use this premise to have teams that are more mature demo their experience to less mature teams. Even then, the context of the second team might drive them to a different answer through their experience.
Diversity could be an option there. Averaging out the maturity so that everyone has the "old and wise" to notify of imminent failure from the same room 😄
I was listening to the "Stink eye on steroids" presentation and got interrupted ... and then missed the end of it. Anybody made note of the contact info for Jill Mead?
@schmark what you describe is similar pattern to the Barclays journey; once the policy of the organisation has been co-opted then resistance starts to drop away. There is a golden nugget here for traditional organisations.
Feel free to continue the conversation #ask-the-speaker-more !
@mylesogilvie Exactly. Financial services shares a lot with gov, but bureaucracy's universal anyway
Hey everyone! I’m looking forward to discussing in the next session
That was indeed awesome! I admit, when I first saw the title, I assumed the 'Monkey' had something to do with ChaosMonkey )and SImianArmy) and that Sumo might be related to the DevOps vendor of that name. (I correctly guessed the razor tho -- was pleasantly surprised to see I was mistaken about the other too).
Some of what was said about rules & governance, reminded me a bit of Ray Immelman's "Great Boss! Dead Boss!" (which isnt really about dead bosses, but about warring tribes phenomenon in many organizations and governance, and the idea of creating a "supertribe" to unify (and hopefully dissolve) rigid tribal silos.)
I need to start using the words "value stream" more in my emails. People seem to like it. And I have completely missed this trend
Crazy to think of a rocket scientist at a small company that was growing
With the amount of capital needed, it would seem like it would be an instant large enterprise
yeah that could apply .. they called it something different in this whitepaper
It's the 2nd time in two days I've heard someone talk about the FAE in a way I'd not thought of it. The common element there is uhh...me!
I can do better than answering that. … here’s the whitepaper
Thank you so much for sharing. I have been trying explore what I call “rewarding firefighters vs silent guardians”, this white paper and your talk is so timely!
Think this is how you get to the Technical Debt spiral that @mik talked about this morning
1Such a great perspective on Thinking in Systems. That rocket engineers would look at inputs, outputs, bottlenecks, etc.
Whats crazy is the engineering organization had decades of experience in lean manufacturing - and at one point was an exemplar at it. And yet. the red tape crept in.
crept is the right word because no one knew when or how … it just happened over time
Is there a correlation with growth of the organization?
@edwmarshall3app there seems to be a lack of research into the relationship between organisational size and agility. The https://businessagility.institute/ is running some primary research in this space, I believe they're on track to publish later this year or early '21
Interesting! Lean paints all waste with an equal brush. ToC focuses on where the hunting is good.
'What if we could hunt for "Brent" everywhere'? 🎯 😆
it’s an nice light way to search for where knowledge is stuck
When you gather metrics, share and visualize them, how do you ensure they are not weaponized?
It’s about choosing what to measure .. and the combinations of metrics .. hunting metrics show trends and and allow opportunity for people to work together to get ahead of problems
Did you encounter any fear? Why do you want to gather that metric about my team?
no because they aren’t team-centric .. they are up a level
teams need different types of metrics than leaders
teams need more granular metrics about flow and bottlenecks etc to use for themselves
Thanks @txjones Loved all the background papers and references too. Very helpful.
metrics not being weaponised: I don't think you can ensure that. It's many conversations about how metrics support outcomes, but also to gain trust to learn where they're being misused (so many scars... "so, why aren't we deploying this new feature?" "because I have a kpi, if I fail I lose. if it works there's no benefit" #metricsFail)
agreed! that said, I like the release and make more $ approach better than release-and-get-hit 🙂
@ganga.n "Lean paints all waste with an equal brush" -- does it? I thought there was (used to be) a distinction between some forms of "necessary waste" (i.e., non-value-adding activities that help either preserve/maintain value, or prevent waste/failure demand, or improve flow). I think refactoring (and lowering tech debt) falls in there somewhere. (Or am I mis-recollecting?)
True, it does make distinction between types of waste.. I was referring to a comment where I found that ToC helps better hone in on the real problems to solve rather than trying to eliminate all waste.. That was one of my takeways. Did I get that right?
Ahh - yes. You are referring to "POOGI"? or the "Evaporating Cloud"? (Clarke Ching has a lot of great stuff here!!)
What is POOGI? or Evaporating Cloud? 🙂 So much to keep track of! 🙂 I need to check them out! I was following Tiani Jones' observable universe. 🙂
POOGI == "Process Of Ongoing Improvement" = consists of the 5 focusing steps: https://www.tocinstitute.org/five-focusing-steps.html
Evaporating Cloud is a collaborative conflict resolution technique in TOC that tries to elicit dialogue over debate: https://online.visual-paradigm.com/knowledge/problem-solving/what-is-evaporating-cloud/ (it can work quite well with a good facilitator and the participants have a working agreement for the ground rules of particpation)
Of those two: POOGI (the 5 focusing steps) is probably the one that tries to guide you to hunt for the "next right thing" to address in terms of waste elimination (e.g., you find the next biggest constraint/bottleneck and follow the 5 focusing steps)
Thank you so much! Love it. I recall the steps in ToC esp from its reference in the Phoenix Project, but the acronym didn't ring a bell. 🙂 Hadn't heard about the Evaporating Cloud. Much appreciated!
In Phoenix Project, John lears that all of the efforts he was making in IT Security around controls were wasteful and redundant, since Finanace alrady had their own controls in place. Where and how is it useful to challenge statements that "we can't do X because... audit"?
Any time audit is the sole reason you're doing something (or not doing something), it makes sense to challenge it. Understanding why audit is not wanting you to do something (or why they want you to do something) can result in more clear and actionable feedback from the auditors. It can also challenge the auditor to really make sure the feedback they're providing is adding value.
When challenging conotrols/SoD/etc, since Audit typically is checking against controls created by some process, who usually need to get involved to determing when these can be safely modified?
Any time you're changing key controls, it's a good idea to connect with your auditors to explain to them how the control is changing and how the risk is still mitigated. They can provide an independent lens as well.
How do you differentiate between risks and threats and measure (or rank) each?
We would look at threats as a component of a risk. Each organization ranks risk and threats differently, though.
Love this question! We're figuring this one out as we go. Ideally we would get a feed of data showing the output of the automated controls and monitor this for key risk indicators (how effective is the control over time?)
So base it on outcomes tied with things that passed the control under a given set of conditions?
I posted a related question on the #bof-sec-audit-compliance-grc : https://devopsenterprise.slack.com/archives/C01577ZGQ2G/p1602646779013300?thread_ts=1602646436.013000&cid=C01577ZGQ2G
Do you have knowledge of any material that more deeply discuss the validity of different approaches to separation of duties?
like automated controls only vs any-peer-review ("four eyes"), vs review/approve by different roles ...
I've always seen it done by "four eyes", with the concept of how many folks would have to conspire to subvert a system (all talked about in your link). I'm intrigued by automation of SoD, but haven't seen a case study that backs that up.
Are you familiar with the (somewhat dated) concept of "People-Centric Security"?
Great presentation @lucasc5 and @lewir7. Are your audits supporting SOX requirements specifically? SOX requirements for controls and evidence appear less amenable.
Excellent presentation! Im curious how long did it take your Risk Mgmt and Internal Audit teams to get comfortable with DevOps and the automation it brings?
We started adopting lean and agile practices beginning with our Agile transformation in 2006. DevOps however became our IT organizations primary focus beginning in 2012, and then in 2018 we created a DevOps Platform Team to assist application teams in making progress on our overall organizations DevOps journey. From an audit perspective, we are still in the process of working with our risk partners in an effort to gain greater comfort in the automation it brings.
The talk mentions the risk appetite of the organization. How far is that a decision/choice of the org when it comes down to regulations like SOX? Example: preventive controls vs reactive controls (detect something wrong occured, and take action on it to remedy it and avoid further ocurrences)
Hi everyone! I'm going to be honest - it's a little odd listening to myself doing my track talk 🙂
yes, you too as well! I was delighted to see you on the schedule. I always learn so much from you!
I'm looking forward to this presentation. Influence is indeed > than authority. Authority, however, is louder and it can scratch your corneas 😉
LOL - yes - I'm not in any way saying that authority doesn't matter. And mis-used authority can indeed scratch corneas and cause all sorts of other kinds of damage.
“I told them what to do… but they’re not doing it” < I’ve heard that before!
Aha! Step 2 - Make Problems Visible
I’ve heard that conversations are important. 😄
@dominica and I each triggered in our own way. 😄
Not to override Step 1 - very much want to learn how to set up conditions for growth.
Positive feedback only reminds me of animal training. Rewards only.
Train the puppy that shows up"-)
Not sure I would frame it quite that way when talking about people -- wouldn't want to offend anyone -- but yes, it's the same general principle.
Yes - true - and common in organizations where the culture encourages people to play the my-brain-is-bigger-than-your-brain game.
My friend Brian calls this “tiger training”, in refrence to an old NYT essay: https://www.nytimes.com/2019/10/11/style/modern-love-what-shamu-taught-me-happy-marriage.html
Dan North covered that as one of his feedback techniques at QCon several years ago: https://qconlondon.com/london2016/presentation/making-sandwich-effective-feedback-techniques
BTW you can find Dale Emery's tweet here: https://twitter.com/dhemery/status/1255189841089712128
Really like getting the feedback from everyone else.
How would you kick-start a behavior that isn’t there? Like, if nobody does good commit messages?
You can "shape" the behavior you want by finding the very very best example (that still doesn't meet your bar for 'good') and feed that.
If you're a leader with a dev background, pick up some stories and write some good commit messages as an example :)
An article that goes into Jon Stegner’s glove story in more detail here: https://scm.ncsu.edu/scm-articles/article/managing-maverick-spend-at-deere-and-delphi-an-interview-with-jon-stegner
I confess I actually am enjoying this virtual format better than traditional in person for exactly that reason!
BTW in addition to her fabulous book, @dominica has a fabulous presentation / article here: Also she did a great presentation on this topic available here: https://itrevolution.com/how-to-visualize-impacts-to-workflow/
She's also a fabulous VSM workshop facilitator ... speaking as a happy customer 🙂
between an hour and a week? yeah, a bit of variation…
LOL - this was in an organization that was theoretically was doing something approximating continuous delivery - our philosophy was generally that every committed change we made should be shippable.
I remember those days. Now I'm still working on convincing my peers that we - a university IT department - are a software company and should act like one occasionally.
I was starting lean coffee sessions before covid, but have struggled to get attendance to lean zoom sessions when everyone is well over zoom now.
Understandable but sad-making. It is exhausting to be staring at screens all day without face-to-face interactions.
Yeah - it was sooooo painful. The worst we had on that project was a 3 week period where we couldn't ship anything because we couldn't get a green build.
@esh what's a flake?
THIS --> "The primary driver of painful change was contention & flakes"
brilliant illustration of the problem, and also of working through a problem.
Flaky tests are usually false failures. The problem is that you can't ignore the failure because it might actually represent real and valuable info. You don't know.
I mentioned the open space law of mobility. It’s also called the law of two feet, but I prefer mobility since not everyone has the use of their feet.
If you haven’t encountered open space before, there’s a good short primer here: https://openspaceworld.org/files/tmnfiles/2pageos.htm
Harrison Owen, the person credited with starting Open Spaces as a conference format, wrote a wonderful book: Open Space Technology https://www.goodreads.com/book/show/166989.Open_Space_Technology
Love that story. Leaving a meeting because you don't belong there == radical empowerment!
I like the way you made that statement. "Bosses" think that ""authority"" gives them """value""" (additional quotes intentional...)
And big shoutout to @jtf & @ds for their book on Agile Conversations!
I will forever be grateful to Kim Scott for her framing of nice v kind - it resonates so much with folks. https://www.goodreads.com/book/show/29939161-radical-candor
We have talked about Radical Candor at work quite a lot. That's a great book. Radical Candor is tough, but if you're comfortable you're not changing
I don't talk about it here - but it so bothers me when folks think that being kind is being weak.
I like "thoughtful". Also "responsibility" as in the ability to respond while being present.
At StitchFix, we used to say our values were "Bright, Kind, and Goal-Oriented", and talked a lot about Nice <> Kind.
@esh As a leader, if you have hire/fire/compensation power over people, how can you challenge them directly in a way that doesn't shut conversation down?
Seriously - establishing that you genuinely care and establishing trust is a precondition. Otherwise there's too big a risk of coming across as a jerk.
Organizational power can backfire so easily, especially when you're trying to foster trust
an addition to the list that I like is “the story I’m telling myself is…” < from Berne Brown
A lot of this is in line with the Difficult Conversations technique as well - it’s been really helpful for me to navigate these sorts of conversatinos
I really like the book “Crucial Conversations”. This model has worked very well for my org
One thing I find really hard, is in the moment remembering all the things from Crucial Conversations or Radical Candor and not just letting my mouth run away with itself.
I tend to get a book club going on it with new leaders or leaders who haven’t read it previously at least once a year, or more often as needed. It helps me keep myself in check
That's a great idea. I've spent a lot of this year re-reading some of my most inspiring books and realising I'd forgotten so much.
@nl_does I agree - implementing these techniques is so much harder than understanding them! The breakout session "Making Change Painfully with Conversational Dojos" had a view on how to actually practice conversational technique which I found really interesting 🙂
Frank Herbert would say "Fear is the Mind Killer", that's a Dune reference. Nice! I agree with @rshoup
Ha - I think that is running away from your fear
No that's just re-positioning for a better attack angle. Common misperception when dealing with sand worms