Skip to content
This repository has been archived by the owner on Dec 21, 2018. It is now read-only.

Organizational Anti patterns

danielsdeleo edited this page Oct 15, 2014 · 3 revisions
  • Facilitator: Stephen Nelson-Smith
  • Note-taker: Daniel DeLeo

Why We're Interested

SNS: Culture stuff is way harder than the technical stuff

Dan: We had a 6 month effort to improve but we didn't

Matt: I do dev and ops, don't want to be pigeonholed as "the ops guy"

Jon: Etsy considered the "devops unicorn," but it's not true, you can do it.

Alex: Companies say "let's do devops" but don't know what they're asking for.

Hemal: trying to spread the Chef love and ops love through the organization (currently the only person doing this) Several others have this problem.

Discussion

Jeff: people/teams create the most complexity in software (not the features/requirements)

Alex: smaller teams achieve more; team of 3 had better velocity than 15.

Jon: At Etsy, ops team has 15, works really well; 50 people writing Chef code. Culture makes it effective. Have specialization without silo-ing.

Alex: when introducing devops, it works well to start with a small collocated team.

Justin: At GE, went from 0 (no datacenter) to CD app in 6 months. Having an example focuses discussion on what's possible. Reference - Conway's law: organizations produce artifacts that reflect their own organizational structure. Having a working example of a devops-built app allows org to structure themselves differently.

Jeff, Jon, Justin: having one team doing devops mean failure belongs to "the devops team," or if they're successful, they become the build/deploy team for the whole organization (several examples).

Alex, Dan: non-technical managers ineffective.

Dan: Being able to patch shellshock quickly demonstrated value of automation to the team.

Hans: non-technical manager doesn't work well b/c have to translate technical concepts when decisions go up/down the hierarchy.

_Justin: What does the non-technical manager do?

Dan: Protect the team from political issues in the team

Jon: Some orgs have managers just to have a manager to fill roles in the hierarchy, but that's not what managers should be doing. Managers should be handling work that otherwise would slow the team, like budgets.

Justin: Be clear as a manager about what your function is. Had to do a lot of politics and selling ideas.

Jon: It's important to give people a place to progress in their career without forcing them into management, they can stay as individual contributors (applause).

Jeff: you have to know who you are so you know if you're a good fit to be a manager.

Alex: Success in a first devops project at an organization lead to the team getting loaded with a lot more work (sprinkle the devops fairy dust on it).

Justin: Change has to be pulled, not pushed. Escalate new demand to a business level conversation. Manager needs to fight the scope creep within the team's work. Increased demand from outside is a sign of success, but when turning down requests for new work, it can be perceived as a failure "devops can't fix everything."

Jon: Big organizational anti-pattern is how the org handles failed projects. Blameless post mortems apply to failed projects. Otherwise teams won't share or try new things.

Jeff: "Change is hard, don't be a dick about it." When you succeed, other managers will try to give you their underfunded projects, some will try to emulate your success, it's a mixed bag. Make "small blast radius" changes within your team first. Failure to say "no" to work your team can't handle is being dishonest about the amount of work your team has now, is a communication failure.

Alex: how do you deal with it when a high level manager declares "thou shalt devops/CD/etc."?

Dan: Set boundaries for which tools you use to do what, so everyone can see the same examples.

Jon: Very difficult to make change unless you have a high-level decision maker who "get's it." At Etsy, when new tech is introduced, they create a prototype, then they have an operability review; ops, security, dev all contribute. After that, dev goes forward, then there's a second cross-team review to make sure there's a run book, monitoring, contingencies are discussed.

SNS: We're out of time, wrap up, show up to other relevant sessions to learn more

Clone this wiki locally