DevOps and sharing A semi-personal story Marta Paciorkowska 

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 

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 

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 

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 

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 

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 

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 

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 

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? 

First question: Things that make adopting DevOps in your organization difficult 

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 

● 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 

● 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 

Second question: The most important thing you have learned this year 

“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” 

Third question: Approach to internal documentation 

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. 

Knowledge transfer 

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 

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 

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 

Knowledge transfer is both about what you know and where you look Knowledge transfer: I’ll share a secret 

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 

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 

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. 

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. 

Practice non-violent communication. Consider doing regular brainstorming sessions. Mimicry. Foster a healthy work environment. 

Thank you Marta Paciorkowska t: @a_meba || g: xamebax https://thatmarta.wordpress.com