talking_to_managers - chef-boneyard/chef-summit-2014 GitHub Wiki

Session Title

Studio, Wednesday, 14:30

  • Convener / Facilitator
  • Note taker

Participants

Summary of Discussions

How to talk to managers

Understanding the language and perspective

  • costs, resources, competitive advantage
  • this is a different w

Pitching - capex, opex,

  • speak in terms of roi,
  • who will manage it
  • training
  • how improves existing process
  • e..g new transparency
  • need to sell the solution
  • how much time

Not specific to chef

  • focus on four eyes
  • systems such that one disgruntled employee can’t wipe out things
  • part of the benefit is that you can keep servers in a managed
  • highly controlled environments - — auditors would think many servers change would be a risk — cock up or maliciously break things

Want for a better audit trail Want for supervisory Sys admins - can log into a golden host

  • they have to have the server scope and ticket for particular
  • loss of

Shrinking supervisory access instead to code review of a single artifact

  • on condition of acceptance of athuroity not blind to the change actually made
  • this becomes the unit of currency

Korea, Singapore - very wary of who has access to what

Organization

Showing compliance and audit people how the thing is actually made is very helpful

  • at the start they will have no idea what they are looking at
  • lots of people don’t understand
  • agile dev is averse to fraud, because so many people look at it
  • the

Changing the thinking re: historical access

  • rigid and regimented process

Identify where the pain points are, r

Learn to say the same thing in many ways

  • technical
  • patience

You need an “opportunity” to put dev ops in an organization Management, for business reasons, but that reason is often obscure to engineers

  • engineers don’t know e.g. the a company to be able to be sold off

Organizaion needs to decide to commit to e.g. the DevOps way

  • when things are moved from Dev to Production matters become very serious
  • org change to support, training,
  • costs, roi
  • but if we don’t do this, we can’t do

Technical explanation are not considered valid answers.

Separate silos between dev and ops

  • no one sits in between to - no one to arbitrate
  • architects - too busy doing their
  • Dev & Ops don’t want to fund a common tool., they have experience and trust in their
  • Managers not understanding just falls to Gartner

Organizational Antipatterns - Conways Law - an organization will always produce systems that reflect the structure of the organization

  • e.g. the app guys and the infrastructure guys
  • systems protect your ways of doing things
  • methodologies like ITIL concrete this

Justin draws a diagram - to get to the core of the solutions

Inside -> Out (infra guy looking at the org) Outside -> In (org looking at guy)

Thinking vs.

  • is someone taking a prospecting Acting vs

IOTA

Where you are vs. Where they are

Outside in = where our assumptions lie e.g. saying taking cost out of the organizations is how you measure success = can you validate that for me?

Proirities

  • are not objectives
  • have to be compared to something else
  • are trade off
  • what is MORE important to you or.
  • relative importanve
  • mke things explicit

Principles (thinking Acting) - this is how we are going to do this

  • we will do the project in X way
  • e/g/ we will not use the principle of
  • because velocity is the most import

Engineers - like to talk about the what; Managers - want to talk about the How and Why

  1. what is important in this company
  2. priorities,
  3. principles, e.g. exclude legacy processes for x, but will abide by compliance stuff — this can help take tension out of the relationship
  4. improvement (outside in, acting) — how do we make sure it stays good, gets better
  • what’s the control process for quality, how do I know its going okay, and getting better

change usually creates a set of instability

  • so you need to sell change = improvement not outage

how quickly,

automation = if you make a change - teams making manual changes - but they aren’t online

  • hugleyly different from them just picking a version from a version control system
  • not scp’d into tmp
  • allieve

speed - lots of small earthquakes, not one big huge one

shipping every six months - you will ship the fix for e.g. shell shock

  • CI/CD gives instant remediation

use analogies for managers

  • the solution of the problem
  • not slow down for stability

hand dryer problems

  • slow luke warm air to dry hands
  • better = warmer air = hottest air
  • dyson = not about the temperature - about the speed of the air
  • not this it is that

During an outage, you can do anything, rebuild the app “fix it, fix it!”

If you want me to do something… make me money, save money or save me pain

we are often not in a position to see the effects of what we started in engineering in devops you can end up driving change to the culture of the whole organization

you have to be clear about the cost savings

you need to know what the manager and the organization are looking for

“too many applications”

What will we do now? What needs to happen next?

⚠️ **GitHub.com Fallback** ⚠️