DOES18

#teams have to view that their work makes a difference and adds to the success model and metrics of the company

Feedback loops are critical without blame

Failure is another link to success

people that are passionate about their work, looking at it as more than just a paycheck, will persist and support DevOps journey until success. Failure is a part of this journey and learning from it and continuing will be only possible from motivated ones..

The way people view their work matters - It's hard to manage invisible work.

@dominicad perhaps even impossible

Might be controversial but for me it's the number of ticket systems. Anything greater than zero contributes to the potential for wait time & value flow disruption.

@dominicad Making problems visible for teams to see helps people understand and work to improve.

I think the way people view other people can make or break DevOps transformations

@manupaisable too many stereotypes in IT still :(

I've always been fascinated by how work can get atomized into various ticketing systems, and almost impossible to reassemble back into business intent. @fgoulding

@RealGeneKim need to move ticketing to being a record rather than an approval

It sounds cliche but it's the fundamental culture of high performing teams. When we are all committed to each other's success regardless of organizational lines for the ultimate aim of value delivery it's amazing how it affects the definition and execution of work.

when I see people move from cynicism to hope, then I know we are making progress.

I find it important to give revenue protection work the same visibility as rev gen work.

@carmendeardo Yes! Hope increases the positive energy of the teams across the org.

@fgoulding That would be the theoretical ideal! I remember very early days as an open source dev where I would pull work in effectively real time from a user community. But as soon as the project got more popular the demand exceed the capacity, and the age of issue tracking came

Credit also needs to be shared and stories need to be told to make it real to the community.

by defining the clear overall goal that both sides can relate to

@thebabymonster agree. Having a goal like being responsive to business needs to accelerate delivery from idea to feedback.

Shared incentives: everyone has a stake in feature throughput + stability + operability of the system.

We having a saying in various teams I have been apart of "Teamwork makes the Dreamwork!" #Ops leaders are apart of that team

Common KPIs are key. Interact as much as possible - for instance, getting team members at each others' stand ups, or holding joint stand ups, builds understandings

@ericarmorrison meeting, conversation, common ceremonies, all of it helps build familiarity which lessens fear

Help #Ops leaders work towards the same goal by clearly identifying explicit prioritization policies.

@dominicad Recognize that a decision to do one thing is a decision to delay something else.

In my experience, one thing that can catalyze this is deliberately creating a strategic objective (eg OKR) that both sides rally around. Avoid ops only or dev only objectives, which pushes back to silos. But if it's "reduce lead time for value stream x" both sides need to work.

@dominicad what you say no to is important

getting a focus on speed of delivery (lead time which includes automated infrastructure) and also automated recovery capabilities to mitigate the risk of frequent deployments.

@cshl1 #MoreNoLessWIP

@ericarmorrison Yes, exactly my experience, +1 for common KPIs, especially those that focus on end-to-end business outcomes, not a dev specific improvement or an ops/infra improvement

For me the ultimate answer seems to be in those organizations that are realigning the organization and job descriptions to eliminate the silos and focus on flow of value. We created the division in the first place... we can likewise fix it... if we have the courage.

PS: I'm super excited by the Ops leadership emphasis in the programming this year: https://itrevolution...

Ops must realize that their role is changing #SRE

I'm fascinated by when Ops leadership is perceived by the rest of the organizations as "union leaders," not "business leaders." Sometimes warranted!

Core tenant of #Ops in the future - coding is a necessity #SRE

And +1 for common meeting cadence and ceremony Chris. Making progress on such a crosscutting KPI requires effective meetings and collaboration that builds trust and relationships between the key stakeholders.

Making Work Visible by Domica Degrandis. I've referenced this multiple times

I've seen some great videos from Thoughtworks & the Web Summit. Practically free education ;-)

This is one of my faves: @richhickey (inventor of Clojure): a talk he gave at JavaOne in 2015. His comment of "how many people do you have to take out to lunch in order to make your change"

Oops: here's that amazing talk from @richhickey: https://www.youtube..... Blew my mind.

I second Erica. And also - for fun - the intro videos from early DevOps Days (2009-2011) were hilarious.

@ericarmorrison agree and also loved your talks with Scott.

@manupaisable How far we've come!

Understand that in most organisations they face so much more change resistance than Dev

Ooh! Yes, @ericarmorrison talk in 2015: "When Ops Takes Over Dev": her team's suggested talk title: "we should present something on NLB, but we would need to present at 1am"

All of Scott Prugh's talks going back to 2014 https://youtu.be/f4e.... The message that DevOps works even in legacy environments and technologies is powerful, and the fact that it has remained so in the years since gives that message incredible legitimacy.

I reference talks from Topo a lot while at Nationwide to show what is possible even with regulatory requirements.

@ericarmorrison Many Thanks!

I’m not sure what a technology value stream is. To me a value stream is a business value stream by definition. What we need is technology leaders to understand that - and, crucially, behave themselves and promote the behaviors that match that alignment with business

It's so important to navigate the organisation, expand your network and make connections!

culture and fear of change

@cshl1 Yes, absolutely. This is true across an entire organization. Change is hard. We must build empathy and understanding of what we are trying to accomplish

@ericarmorrison and consistent, firm leadership

personally i think that main obstacle is an illusion that technology doesn't matter for them. But technology is entangled in everything nowadays, every large org is a tech org in some way

there are obstacles around culture and organization. Most organizations don't really understand the flow of work form Idea to deployment and feedback and know where bottlenecks exist. Seeing IT as a cost center is another issue that emanates from that.

Lack of organizational agility and the leadership competencies to drive the change needed to take that on as an adaptive challenge. Closely connected to Chris's comment about culture and fear of change.

Yes! It will be awhile but IT must transition to opportunity rather than cost basis. Lots of history must fade first.

@manupaisable yes we have a saying that technology is the easier part and culture is the challenge.

Tech leaders face uncertainty everyday - contributed by staff who are afraid to speak the truth.

@dominicad until it's too late!

the money value stream and the belief in the illusion of the value of the fixed plan

follow the money