More than ever, blog posts, workshops, tutorial videos, and books are presenting quick and easy ways to get started with new tools and technologies. While these types of media provide an excellent jumping off point for engineers to learn and experiment with new subjects, they also set unrealistic expectations about the complexity of the topics involved. Unfortunately, it is becoming more common for non-technical stakeholders to cite these works as evidence that engineering work should be completed faster and deadlines should be shorter. As a result, technical work that delves deeper into solving the hard problems of production operations, stability and scaling is being devalued and misunderstood. In this talk, we’ll explore the patterns we’ve developed in our communications as a tech community that have led to the conflict between “This tech makes things fast and easy!” and “These problems are hard; we should invest time in solving them correctly.” We’ll dive into some real-world examples of the frustrating impact that current perception has on engineering teams. And finally, we’ll formulate some concrete takeaways to improve the way we present, share and frame technical topics across diverse technical and non-technical audiences.

1. @szelechoski@szelechoski
How 'Up & Running'
Culture is Devaluing
Engineering Work
Sarah Zelechoski (she/her)

2. Sarah Zelechoski
VP of Engineering
@ReactiveOps
@szelechoski

3. @szelechoski@szelechoski
As an Engineer
› Work hard
› Solve challenging problems
› Help customers, other teams
› Learn & teach
› Keep up with new tools & tech

4. @szelechoski@szelechoski
The Result
› Deadlines constantly shortened
› Hours grew longer
› Expectations raised
› Stress was normal
› Burnout was real

5. @szelechoski@szelechoski
Why?

6. Misaligned
VALUES
@szelechoski

7. 1.
VALUE
What is it? How is it calculated?
@szelechoski

8. Actual Value
› Intrinsic
› Factual
› Well understood
› Cannot be manipulated
@szelechoski

9. Perceived Value
› Experience/Perception
› Appearance
› Differs based on Individual POV
› Can be manipulated
@szelechoski

10. @szelechoski
Cheesy
EXAMPLE

11. Value Comparison
“Block Cheddar” Artisan Aged
Clothbound Cheddar
@szelechoski

12. Actual Value
› Type of Milk
› Fat Content
› Flavor Ingredients
› Texture
› Meltability
› Age
@szelechoski

13. Perceived Value
› Unconfined dairy animals
› Family farms
› Living wage
› Local economy
› Health/nutrition
› Care
› Appearance
@szelechoski

14. @szelechoski@szelechoski
Features
Vs.
Benefits

15. Perceived Value
› Is there a way we can predict or
calculate it?
@szelechoski

16. Perceived Value Equation
PERCEIVED VALUE
BENEFITS
COST
=
@szelechoski

17. Maximizing Perceived Value
PERCEIVED VALUE
BENEFITS
COST
=
@szelechoski
PERCEIVED VALUE
BENEFITS
COST
=

18. Difference in PV
› Audience
› Communication
@szelechoski

19. Raw Jersey cow’s milk cheese
crafted by hand, working with
small batches of milk picked
up right after morning milking
at a nearby farm whose herd is
dedicated solely to supplying
their dairy.

20. 2.
COMMUNICATION
How do we communicate value?
@szelechoski

21. Communicating Work
› Share your story/POV/experience
› Method
› Meeting update
› Blog post
› Tweet
› Presentation
› Documentation
› Pull Requests/Code
@szelechoski

22. 3.
‘UP & RUNNING’
COMMUNICATION
What does it mean?
How do we use it?
@szelechoski

23. @szelechoski
Up Running

24. @szelechoski@szelechoski
‘Up & Running’
› Focused on getting started
› Does not necessarily touch on
› Upcoming hurdles
› Advanced technique
› Finish line

25. @szelechoski@szelechoski
In The Wild
“Ansible: Up and Running: Automating Configuration
Management and Deployment the Easy Way”
“Docker Is Easier to Use Than You Think”
“Deploy an App into Kubernetes in less than 24 Minutes”
“AWS Made Easy”
“Painless container management with GKE & Kubernetes”
“A weekend, a Rails app, a Kubernetes and an Azure”

26. @szelechoski@szelechoski
Emphasis
› Simplicity
› No challenges/roadblocks
› Quick to learn/implement
› Save you time
› Potential power

27. @szelechoski@szelechoski
What We Omit
› Challenges
› Learning/research
› Help received
› Implications
› Next steps
› Complications

28. 4.
‘UP & RUNNING’
CULTURE
Are we complicit?
@szelechoski

29. @szelechoski@szelechoski
“Culture is the patterns of
learned and shared behavior
and beliefs of a particular ...
group“
- lumenlearning.com

30. @szelechoski@szelechoski
Culture of
Engineering Communication
› Research is one of our tools
› Learn from others communication
› Communicate to share our
experience/knowledge
› Engineers will always be depositing and
withdrawing from the collective
knowledge of others in this way

31. @szelechoski@szelechoski
Memes
› We imitate behavior
› We emulate patterns
› We communicate in ways that have
been helpful to us

32. @szelechoski@szelechoski
‘Up & Running’ Culture
› Particular subset of engineering
communication culture
› Introductory level material
› Simplification of topics
› Glorification of speed
› Minimization of effort
› Make <unapproachable thing> less scary
› Mic drop

33. @szelechoski@szelechoski
Why do we participate?
› Min-maxed for Engineerings
› Lowering costs to themselves
› Not as much effort
› Low complexity
› Maximizing benefits!
› Learned a new thing
› Effective/impactful
› Make my/your life easier
PV
B
C
=

34. @szelechoski@szelechoski
Why is this
problematic?

35. @szelechoski@szelechoski
Audience
› You may be communicating to other
engineers, but other audiences are involved
› Other groups have different perceived value
› This type of communication is misvaluing
engineering work in the eyes of others

36. Decision
MAKERS
@szelechoski

37. Decision Makers
Expected Benefits
› Learn challenging topics
› Extrapolate from
experience
› Problem solve
› Troubleshoot
› Innovate
› Enact change
Communicated Benefits
› Topics are easy
› No experience necessary
› No challenges involved
› Solved problems
› Implement
@szelechoski

38. @szelechoski@szelechoski
Decision Makers
› Benefits communicated are lower than
expectations
› Must lower their costs to maintain value
PV
B
C
=
PV
B
C
=

39. @szelechoski@szelechoski
Decision Makers
› Timelines must be shortened
› Speed is expected
› Problems are well understood
› There is a “right way” to do things
› Teams should be smaller
› Specialized Generalist “DevOps Engineer”
› Know everything
› Engineers can handle more work
› Tools, frameworks will allow fewer engineers do more
› Automation means the engineer has less work

40. Beginners
@szelechoski

41. Beginners
› Unrealistic expectations
› Witness success without struggle
› Knowledge is assumed
› Learning takes time/Different for everyone
› Inequity in Resources
› Assistance not available at same level
› No learning resources
› Lack of toolkit
› Lack of future thought
› What comes next?
› Pitfalls will arise
@szelechoski

42. @szelechoski@szelechoski
Beginners
› Costs communicated are higher than
expectations
PV
B
C
=

43. @szelechoski@szelechoski
Other Groups
› Sales
› Marketing
› Recruiters
› Customers
PV = ?

44. 5.
METHODS FOR
COMMUNICATING
VALUE
How can we change for the better?
@szelechoski

45. @szelechoski@szelechoski
Set Expectations
› Explain the scope or any limits on the
material covered
› Tell the audience exactly what they are
meant to take away from the
conversation

46. @szelechoski@szelechoski
Leveling
› Clearly label communication
› Beginner
› Intermediate
› Advanced
› People will self select better

47. @szelechoski@szelechoski
The Rest of the Story
› Communicate all levels of work
› Push past ‘Up & Running’
› More than just getting out of the
starting blocks
› Implications
› Consequences
› Next steps

48. @szelechoski@szelechoski
Focus on Benefits
› Cost is not generally under your control
› You are in control of the impact and
benefits of your work
› Make sure benefits are accurately
represented
› Or they become a cost!

49. @szelechoski@szelechoski
Be Authentic
› Do not ‘Photoshop’ your work
› Share trials and tribulations
› Showcase hard work and application of
experience
› Failures are as important as successes
› Cite your sources

50. @szelechoski@szelechoski
Value Judgements
› Don’t judge your work for others
› Factual/evidence based
› Allow others to draw conclusions
› Avoid
› “Easy”
› “Simple”
› “Quick”

51. @szelechoski@szelechoski
Precision
› Words are important
› We are engineers, be precise
› Don’t say “Docker Is Easier to Use Than
You Think”
› When you can say “These Commands
Will Help You Begin to Understand
Docker Fundamentals”

52. @szelechoski@szelechoski
Audience
› Presentation for decision makers in your
company
› Onboarding documentation for new engineers in
your company
› Article for marketing purposes
› Think about the PV=B/C of your audience
› Practice empathy
› Address their concerns

53. Thank you!
@szelechoski
@ReactiveOps
@szelechoski