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.

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