Upgrade to Pro — share decks privately, control downloads, hide ads and more …

DevOps and sharing (including missing slides)

DevOps and sharing (including missing slides)

A talk about sharing knowledge and using "people skills" I gave at DevOps Days Kiel on May 12, 2015.

039602d3cb2cf1d8029667b8e833d11c?s=128

Marta Paciorkowska

May 12, 2016
Tweet

Transcript

  1. DevOps and sharing A semi-personal story Marta Paciorkowska

  2. Introduction What I mean by people skills Why this talk

    Communication is crucial in: - recognizing obstacles - self-development - effective knowledge sharing Gaining that secret knowledge Some practical tips
  3. Marta Paciorkowska DevOps Heroine* Acrolinx GmbH t: a_meba || g:

    xamebax * a female hero; a software engineer, a sysadmin and I guess a bit of a coordinator
  4. Our stack Java Python Clojure Node.js Ember Ant Maven Gradle

    Go Jenkins Docker Lambdacd Linux RedHat Windows MacOS Vagrant Scala ESX Clusters GWT MySQL PostgreSQL DB2 MSSQL Oracle H2
  5. Introduction What I mean by people skills Why this talk

    Communication is crucial in: - recognizing obstacles - self-development - effective knowledge sharing Gaining that secret knowledge Some practical tips
  6. People skills communication abilities personal habits cognitive or emotional empathy

    leadership traits building relationships of trust, respect and productive interactions understanding ourselves and moderating our responses
  7. Introduction What I mean by people skills Why this talk

    Communication is crucial in: - recognizing obstacles - self-development - effective knowledge sharing Gaining that secret knowledge Some practical tips
  8. The “why” & the “how” of this talk DevOps is

    not only technology; it’s interdisciplinary I’m against the self-fulfilling prophecy of the anti- social tech-genius: we over-simplify “people skills” Discuss skills one by one You cannot foster success when you only focus on one skill
  9. Introduction What I mean by people skills Why this talk

    Communication is crucial in: - recognizing obstacles - self-development - effective knowledge sharing Gaining that secret knowledge Some practical tips
  10. My experiment After a few months of working in Acrolinx,

    I decided to ask my colleagues a few questions: • What would they consider the biggest obstacles to popularizing DevOps ideas and implementing DevOps- inspired practices in our company? • What was the most important thing they learned recently (this year); did they learn more by collaborating or by themselves? • What’s their approach to internal documentation?
  11. First question: Things that make adopting DevOps in your organization

    difficult
  12. Mindset Overwhelming amount of tools No one wants to do

    the “boring” tasks Using outdated software/technologies Lack of documentation on our outdated software/technologies Lack of resources No bigger picture Other people Being kept in the dark Obstacles
  13. • Learn about people’s preferences and use that when dividing

    work (communication, organizational skills) • Fight the hesitation (empathy): - rigid mindset... - “My work is more important”, - “I don’t see the benefits at all” - “But current tools work ok!” - or underdeveloped skill set? Analyze & f
  14. • Outdated technologies? Lots of tools? Lack of a bigger

    picture? - build a long-term plan (leadership & organizational skills) - listen to complains (empathy) and motivate colleagues (leadership) • Unresponsive colleagues: - the busy bee, the slight procrastinator, the focused one - recognize the reason and pick the best solution Analyze & f, continued
  15. Second question: The most important thing you have learned this

    year
  16. “You need to know what you want to build before

    you actually build it”. “You should keep things simple and don’t engage in premature optimization”. “I’ve learned a lot and it’s hard to pinpoint the most important things, but I’ve mostly learned by myself or pair programming”
  17. Third question: Approach to internal documentation

  18. We have so many tools and “tribal” knowledge lying around

    that internal documentation is necessary. Internal documentation is unnecessary: software changes and we have a low turnover rate, so it gets outdated quickly; additionally, someone has to maintain it. Documentation is important, but no one wants to do it and having it is a team decision – not an individual one.
  19. Knowledge transfer

  20. When people work together for a long time, they start

    treating specialized knowledge as if it was common. The more senior a person is, the bigger the risk that they might treat a lot of their knowledge as obvious. Knowledge transfer
  21. You need to decide whether to spend a lot of

    time writing down docs and then drop them on the new hire or to sit down with them every day and show them something new. Knowledge transfer, continued
  22. Think about each of your colleagues: What would happen if

    they went on an extended sick leave or decided to leave the company? How much would that influence everybody else’s work? Stress levels? Deadlines? Knowledge transfer: mental exercise
  23. Knowledge transfer is both about what you know and where

    you look Knowledge transfer: I’ll share a secret
  24. Your colleagues don’t have to just sit down and explain

    old, cranky code. Encourage them to talk about how they themselves acquire experience instead. How do they debug things? What’s their approach to problem solving? Result: knowledge that will be technology- agnostic. Knowledge transfer, continued
  25. Introduction What I mean by people skills Why this talk

    Communication is crucial in: - recognizing obstacles - self-development - effective knowledge sharing Gaining that secret knowledge Some practical tips
  26. Don’t talk with your colleagues about current tasks only. Try

    to understand where everyone is coming from. In case of resistance: mindset or skill set? Don’t make assumptions, that’s a cognitive error.
  27. Ask, ask, ask. When in doubt: ask. “What is the

    problem you’re trying to solve?” Don’t go quiet when things go wrong or when you’re stuck. Encourage knowledge-sharing. Have your own science log.
  28. Practice non-violent communication. Consider doing regular brainstorming sessions. Mimicry. Foster

    a healthy work environment.
  29. Thank you Marta Paciorkowska t: @a_meba || g: xamebax https://thatmarta.wordpress.com