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?
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
“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”
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.
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
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.
xamebax
is_ryo
sat
masa5555
takasehideki
niftycorp
yoshidashingo
dahatake
aoshun7
comucal
onecareer_tech
lemiorhan
nagix
palkan
jonrohan
holman
hannesfritz
jacobian
rasmusluckow
tmm1
morganepeng
brianwarren
keithpitt
geoffreycrofte
samanthasiow