Fork me on GitHub
#discussion-capri-82022-12-06
>
Slackbot16:12:13

Reminder: The breakout sessions are starting in 5 minutes. Get in front of your browser and start navigating your way to whichever session you’re attending. https://devopsenterprise.slack.com/files/UATE4LJ94/F04DG604H1C/image.png

Ann Perry - IT Revolution17:12:02

Welcome @karthik.gaekwad, here to present: "Benefits and Success Strategies Learned from Google’s Internal Devrel Teams"

πŸ‘ 3
πŸ‘ 1
Sankhadeep21:12:41

Hello, I do not seem to find the recording in the video section. Will this still be uploaded?

Ann Perry - IT Revolution21:12:35

Let me check!

πŸ™ 1
Karthik Gaekwad (Speaker)17:12:44

Hi y'all! Excited to be here- let me know if you have questions!

πŸ‘ 3
Karthik Gaekwad (Speaker)17:12:09

Some conferences we hold internally at google are developer related for serverside developers, web developers, mobile devs etc.

Karthik Gaekwad (Speaker)17:12:34

It's a way we bring folks together to discuss ideas/teams etc

Christian Kullmann / Eurowings / Engineering Manager17:12:23

So the documentation you are refering comes completely from you and your team or is it the existing onboarding / developer doc that you revise?

Karthik Gaekwad (Speaker)17:12:00

Good question! It's kinda both- the devrel team is a part of the eng team- so for new products, we work with the eng team to come up with onboarding/dev docs. Sometimes eng will publish docs and then we might revise it, but generally we work on it together before product release

Heather Bannon17:12:01

@karthik.gaekwad - is this a role embedded into every product team or a separate team?

☝️ 3
Karthik Gaekwad (Speaker)17:12:01

Love this question!! I touch on this in the presentation on how it has grown over time!

❀️ 1
Karthik Gaekwad (Speaker)17:12:06

In my area- I'm fully embedded with the product teams. But on larger teams where we have multiple tech writers, you'll end up with a scenario where you are embedded but your tech writing team also has an identity

Heather Bannon17:12:01

I imagine it's best to be embedded in the team, as it enables the DRE to be highly informed on the product's ins and outs

Heather Bannon17:12:37

but i'm assuming it's an evolution/capacity play where you might start external and build muscle strength in teams?

Karthik Gaekwad (Speaker)17:12:43

Being in the middle of it right now, being embedded feels right- it allows us to understand where the product is going, and message things correctly.

❀️ 1
Karthik Gaekwad (Speaker)17:12:03

Prioritization of what products are represented by devrel is key..

Leaf (Jessica Roy), MassMutual17:12:41

This all sounds like ~50% of my job… Do you wind up being a representative for devs to the rest of the company? We’re nowhere near the size of Google, but often people who want to communicate with devs in general will talk to me or my team.

Karthik Gaekwad (Speaker)17:12:08

YES! We now have a specialized team in the internal devrel team for to run surveys, talk to developers about pain points, and see what issues are with products etc.

Karthik Gaekwad (Speaker)17:12:22

Initially, it was a distributed effort with a bunch of folks doing surveys for their own areas, but we evolved into a single team to run this program

Gene Kim, ITREV, Program Chair17:12:59

Hi, @karthik.gaekwad β€” long time no see, buddy!! (last time was the ride you gave me to Austin aiport during a DevOpsDays, right? Thank you!!! πŸ™ )

Karthik Gaekwad (Speaker)17:12:47

Good to see you Gene! Thank you for having me, and miss seeing you!!

Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere17:12:10

Hi @karthik.gaekwad - How do you measure success of DevRel to the organization? How do you justify to your leaders to continually fund internal DevRel?

πŸ‘† 4
Karthik Gaekwad (Speaker)17:12:10

One of the biggest issues we have is that there are a ton of complaints about onboarding, documentation, learning in all of the different orgs- it's been a pattern of showing success in specific areas, and then growing in that area, and then also getting funding for other areas as well.

πŸ‘ 4
πŸ‘ 2
Nick Eggleston (free radical)19:12:44

@karthik.gaekwad How did those complaints initially surface to the point where someone was willing to take action and funt DevRel?

Karthik Gaekwad (Speaker)05:12:25

there are periodic surveys for product suites that happen internally- generally twice a year; it's where developers give feedback on tools they use- we pay a lot of attention to what is said in these surveys as a product, engineering and devrel team. Docs feedback specifically is actionable to devrel, and there's substantial user feedback on this- it's one of the big reasons why we have a larger docs presence in internal devrel.

Bryan Finster - Defense Unicorns (Speaker)17:12:20

Really good docs allow the platform to scale better. πŸ‘

πŸŽ‰ 2
Heather Bannon17:12:52

Love the concept of documentation for different users - we have some docs where it's a novel - super hard for new users to get started

Karthik Gaekwad (Speaker)17:12:32

Yes- we evolved to this state- we have google analytics on documentation and realized that folks wanted a lot of docs on getting started, codelabs, and more advanced folks wanted usecase specific docs.

πŸ‘ 3
Karthik Gaekwad (Speaker)17:12:49

Helps to think about it with context of "why is someone going to read this doc"

Nick Eggleston (free radical)19:12:46

I love the idea of using analytics to understand your user communities and what to do more and less of.

Bryan Finster - Defense Unicorns (Speaker)17:12:20

Imma big fan of answering questions with the docs to test the docs.

❀️ 1
☝️ 1
Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere17:12:12

πŸ’― This idea above is different than the mentality of RTFM. It's almost coming from a place of assuming the doc is wrong until you can prove it's right (i.e. it does answer the question raised).

Bryan Finster - Defense Unicorns (Speaker)19:12:09

Yes. 100%. We cannot write tests for the docs, but if we use them to answer questions then we can get feedback on what to improve.

Heather Bannon17:12:25

and technical writing is an art - love calling it out as a specific role

πŸ’― 3
Carl Chesser17:12:47

One of my favorite talks on documentation (as docs as code and growing that culture) at Google (2015) curious if this is an approach from the DevRel to encourage documentation growth and maintenance) https://youtu.be/EnB8GtPuauw

πŸ”– 3
Karthik Gaekwad (Speaker)17:12:21

Thanks, Carl!! I will check this out!!

πŸ‘ 1
Carl Chesser17:12:07

I liked how it highlighted the need of maintaining documentation, and how quick engineers could sense if documentation was out of date, and therefore didn't trust / use it (i.e. just went to the source code). It looked at how to improve that maintenance, keeping docs close to code, utilizing the same development toolchain.

Karthik Gaekwad (Speaker)18:12:04

Just watched the whole thing- g3docs is now the standard way we host tech documentation at google. Nice to see this evolution!!

❀️ 1
Karthik Gaekwad (Speaker)18:12:01

another thing we do is have a bot is configured so that is periodically will file a bug to make the owners check the docs for staleness...

Carl Chesser18:12:06

That is nice on having a ecosystem for doing the routine assessment on docs, which keeps the work tracking in-line with everything else. Great projects thrive when they have awesome docs πŸ™‚

Carl Chesser18:12:11

I will also say, I loved the goal of the team: "Enable engineers to find, create, and maintain docs by keeping documentation in a simple portable format (Markdown) next to is associated code, and rendering ti at a logical URL"

Nick Eggleston (free radical)19:12:14

Do they do any metrics on when the age of the docs begins to diverge from the age of the code it covers?

Nick Eggleston (free radical)19:12:35

(of course that assumes the dependency chain is mapped)

Carl Chesser22:12:38

I don't think I have seen data on that, as that could be difficult to signal when that occurs (as a change to the source code doesn't necessarily mean any change to the docs).

Karthik Gaekwad (Speaker)05:12:03

It's doc and doc set dependent- the doc owner can set a timeline for when things should be reviewed- there is a default of at least a yearly review, but can be shorter based on the product it covers.

πŸ‘ 1
Carl Chesser15:12:29

That's nice that there is a default (yearly), but can be specified differently within a project with the documentation.

Bryan Finster - Defense Unicorns (Speaker)17:12:41

At Walmart, we had a dedicated team for curating docs and doing training for the delivery platform.

Karthik Gaekwad (Speaker)17:12:51

This is awesome. What kind of training do y'all do @bryan.finster486?

Bryan Finster - Defense Unicorns (Speaker)17:12:18

They did training on how to use the platform tools. We also had the Dojo team for β€œhow to do that effectively to achieve CD” πŸ™‚ The Docs and Training team was 2 people. Major force multipliers.

Bryan Finster - Defense Unicorns (Speaker)17:12:53

It’s something people underestimate the importance of.

Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere17:12:02

This is interesting - and something I'm juggling.. The trade-offs between a dedicated team doing this vs. instilling these behaviors across the org. My bias goes initially to the challenges of orgs standing up a dedicated DevOps team.

Ryan Savage17:12:07

One notabable thing was that the team wasn’t necessarily in charge of writing all the docs - I (representing one of the apps making up our platform) would write docs for my tool but that team would review it/curate it to make sure it would paint a coherent picture to users of the platform

πŸ‘ 2
Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere17:12:26

How easy / difficult was it for anybody in the org to propose a community contribution?

Bryan Finster - Defense Unicorns (Speaker)17:12:02

@mring important to note that the team wasn’t responsible for writing all of the docs. They held us platform product owners accountable to good docs and did code review for our submissions.

Ryan Savage17:12:29

it was just a pull request away @mring

❀️ 1
Bryan Finster - Defense Unicorns (Speaker)17:12:38

It was documentation as one of the products in the delivery platform.

Karthik Gaekwad (Speaker)18:12:27

Funny! I am currently trying to define what a community contribution is for our organization to clarify what is in that umbrella..

Karthik Gaekwad (Speaker)18:12:03

@mring it's an interesting problem - our org is about 60 folks now; leadership is more central to give internal devrel an identity, but the individual teams are distributed into product teams, so assume the product identity. It works well, but we have found it confusing to have strong identities between the same roles in different orgs- example a devrel engineer on the server team versus a devrel engineer on the experiments team.

πŸ‘ 1
Heather Bannon17:12:10

Awesome talk, @karthik.gaekwad!!!!

πŸ‘ 2
πŸ’― 1
Christian Kullmann / Eurowings / Engineering Manager17:12:34

Thank you @karthik.gaekwad for the awesome inspirational talk. Opened up a few thoughts in my head πŸ™‚

Karthik Gaekwad (Speaker)17:12:54

Thank you, @heatherbannon398 and @christian.kullmann505! A lot of this area is pretty new, but it's something that end users keep asking about, and just allows us to serve developers better..

πŸ‘ 1
Leaf (Jessica Roy), MassMutual17:12:06

Thanks @karthik.gaekwad, great to get the perspective of someone who has a team of more than one πŸ˜‚

Karthik Gaekwad (Speaker)17:12:00

I feel your pain @jroy42!! I started as a single DRE for experiments, but we've grown to a team of 3 now- our whole org is larger and has about 60 folks now and growing pretty fast.

Karthik Gaekwad (Speaker)17:12:16

Force multipliers are important there!

Karthik Gaekwad (Speaker)17:12:26

One thing that's helped a ton has been existing teams we working with send praises to leadership, and it helps the team grow quicker..

1
Karthik Gaekwad (Speaker)17:12:28

Happy to answer any follow up questions and I'll be on here for a while!!

Ann Perry - IT Revolution17:12:00

Welcome @dana.finster, presenting: "Team Diversity, Autonomy & Cohesion - What do they really mean?"

Dana Finster - Walmart InfoSec (Speaker)17:12:00

Hi everyone! I’m excited to be here with you for my first DOES Virtual presentation!

❀️ 6
nathenharvey17:12:29

πŸ˜„ πŸ‘‹

πŸ‘‹ 1
Gene Kim, ITREV, Program Chair17:12:14

Hi, @dana.finster β€” β€œautonomy” is something you don’t hear related to information security that often! πŸ˜† So good to see you!

πŸ˜‚ 1
Theresa Somerville17:12:24

Hi @dana.finster. Look forward to the topic.

Amy Crocker (DBA Supervisor - O'Reilly Auto Parts)17:12:42

What are some tactics for creating a team with shared ownership?

Dana Finster - Walmart InfoSec (Speaker)17:12:01

I’ve seen the most success when teams are given outcomes to work toward together. I have also had the most success with real team ownership with smaller dev teams, 3-4 people, so that there is enough for those individuals to effectively work together.

Dana Finster - Walmart InfoSec (Speaker)18:12:28

Trust and incentives are important - and incentives for team collaboration an be hard because individuals want raises and promotions πŸ˜‰ I think the only way to inspire team incentives is to educate leadership and team members on the value team ownership and collaboration have to the organization: resiliency, innovation, predictability, being a few key things I see being asked for, but almost impossible to achieve when individuals own things instead of teams.

Dave Zorko17:12:06

Building trust with teams, allowing/facilitating everyone getting to know each other. Also, making sure people can speak out with their ideas and be heard. Even if their decision isn't chosen, they may have more buy in/ownership as they are part of the discussion. (a fan of Lencioni's books here πŸ™‚ )

❀️ 5
Dana Finster - Walmart InfoSec (Speaker)17:12:27

Absolutely! Trust is one of the hardest thing to build, and one area where I believe a consistent message from leadership is important - when the message, mission/values are shifting constantly, it’s hard to establish a high-trust environment.

❀️ 2
Dave Zorko17:12:06

Thanks @dana.finster

thankyou 1
Tim Solokha17:12:08

Great talk @dana.finster!

thankyou 1
Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere18:12:44

@dana.finster A few things we're doing: β€’ Team eNPS captured every two months (8 weeks) to quantify engagement, surface issues either to key roles (Engr Mgr, SM, etc.) or as themes across teams to share with Action Teams and org. leadership. Related, big and visible action being taken to address themes constructively to show that feedback is being seen and acted upon. β€’ Team Psych Safety surveys that leaders or Scrum Masters can solicit periodically to get a pulse of psych safety within their team. β€’ Annual employee engagement surveys (HR facilitated) that ask questions related to engagement, belonging, DEI, meaningful work, etc. along with meaningful conversations between direct report teams and leadership. Leader roles participating from a place of learning and curiosity, not judgement.

Dana Finster - Walmart InfoSec (Speaker)18:12:31

Thanks! How are you doing Psych Safety surveys? Something you have built internally? Or are you using something like the people not tech solution? (I had looked at that, but couldn’t get the backing to bring it in.)

Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere19:12:11

An internal survey template that teams can leverage (in our case, using MS Forms). We largely reuse the questions from Amy Edmondson and Project Aristotle research to quantitatively measure psych safety. And then an open-ended qualitative question, such as "If you could change ONE thing about this team to make it better, what would you change?"

❀️ 1
Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere19:12:17

And then we use a Likert scale (5- or 7-points) to quantify respondent's sentiment to these things.

Dana Finster - Walmart InfoSec (Speaker)20:12:13

Thanks for all the info! I will definitely look into those resources.

Istvan Bathazi17:12:32

Thanks! Great talk @dana.finster

thankyou 1
Kieran Neeson17:12:50

Great talk!!

thankyou 1
Dana Finster - Walmart InfoSec (Speaker)18:12:03

Thank you everyone - great questions - I’d love to have more conversations around this, and will be on slack and gather as much as I can throughout the conference.

❀️ 2
Slackbot18:12:11

Reminder: The breakout sessions are starting again in 5 minutes. Get in front of your browser and start navigating your way to whichever session you’re attending. https://devopsenterprise.slack.com/files/UATE4LJ94/F04DG604H1C/image.png

Ann Perry - IT Revolution19:12:00

Welcome, @kieran_neeson, here to present: "Experimenting with Agility and Flow at Waters Corp"

❀️ 1
πŸ€™ 1
πŸ‘ 1
Kieran Neeson19:12:06

Sorry that was shorter than expected guys!

Kieran Neeson19:12:19

I am happy to answer any questions

Kieran Neeson19:12:48

And I would love any feedback you might have to help me improve that presentation

Sankhadeep19:12:47

@kieran_neeson great insights! Can you share a bit more insights on how you are achieving probabilistic forecastic and planning?

Kieran Neeson19:12:30

@sankhadeep.dhar certainly. We are using Monte Carlo simulations using our own historic data to help us attain a probability distribution which allows us to say how much risk goes with a given date.

πŸ‘ 1
Leaf (Jessica Roy), MassMutual19:12:26

"Things we mucked up -- everything" πŸ˜‚. Hooray for experimentation and learning.

πŸ‘ 2
πŸ€™ 1
Kieran Neeson19:12:49

Thanks @jroy42 Indeed! We want to emphasise this point internally and externally here, its ok and in fact I would say necessary to muck things up. And thats ok it is the path to learning

Arun Chawla19:12:42

@kieran_neeson I should put that up in my office --- Great work in empowerment in letting people know it is ok to Muck up ! One of the things we encounter with weather modeling is the fear of breaking things

πŸ˜€ 1
Kieran Neeson19:12:56

Thanks @arun.chawla I can fully empathize. Even though we are a scientific organisation and obviously have scientists as stakeholders and actually scientists as part of the delivery teams - we have historically seen an aversion to experimentation when it comes to product / value delivery. Its that driving need perhaps in a Corp environment to have pre-determined solutions and plans. I am happy to tell you (especially) that I have reference weather warning systems to facilitate & shift some of these conversations. I have tried to encourage and invite those who want pre-determined plans to think of our forecasts as more of a weather warning system rather than an attempt to predict the future. I especially love a podcast from Michael Lewis called against the rules where in one episode he speaks with a weather forecaster and the importance of data and probabilistic forecasts.

Nicole McNeill19:12:42

We were chatting internally this morning about platforms and products. Any insights you could share with your experimenting in this area would be appreciated.

Kieran Neeson19:12:42

Thanks @nicole.mcneill At this stage my only insight is how HARD it is, and I think the biggest challenge to get started (for us at least) is understanding how the Platform IS a product and how we might measure that. We are looking into Team Topologies now and looking at that specific theme - trying to understand the main point of a Platform is to reduce the cognitive load on the consumers. I am currently undertaking the Platform as a Product course by the Team Topologies guys to help us with this.

Tamara Mash19:12:52

Nice talk, would like to learn more about dynamic prioritization

πŸ‘ 1
βž• 3
Matt Turner19:12:45

The model @kieran_neeson used was very engaging using beers, holidays and family cars, but I’ll let him describe it

πŸ˜€ 1
Leaf (Jessica Roy), MassMutual19:12:31

Okay, I wanted to know, now I really want to know πŸ˜‚

πŸ˜€ 2
Arun Chawla19:12:23

Me too! you had me at beers

πŸ˜€ 1
Kieran Neeson19:12:40

Thanks @tmash We attained some Cost of Delay calculators from a course we did with Troy Magennis (I can provide a link later if you like). We took one of those calculators and experimented with our own context. Internally our stakeholders were afraid of giving dollar values on things, but more than happy to stack rank a list of 50 or 100 things, which to be honest wasn't really helping nor scientific. We saw a LinkedIn post on Patton Matrices (i think thats what it was called). Amyway it abstracted the Value discussion / question away from stacked ranking and to thinking in terms of Bets. "What would you be willing to bet that this 'feature' has Value for the customer or user?" The scale went from a Pint of Beer, to a holiday, to your salary, to a sports car, to your home. It made things very personal on relative terms. And dramatically changes how stakeholders responded. We kept all the 'Bets' and then presented them back to the stakeholders to show HOW misaligned they actually were. Then we worked together to come to a normalised and aligned view of Value - still using the Bets scale

thankyou 1
πŸ‘ 3
πŸ€™ 1
πŸ˜‚ 1
gratitude-thank-you 1
Kieran Neeson19:12:13

Apologies for the long response there I'd be happy to show this off line any time

Leaf (Jessica Roy), MassMutual19:12:21

That is fantastic!

❀️ 2
Kieran Neeson19:12:32

What you might really like is that one stakeholder tried to say EVERYTHING was a House (top bet). So we said sure! No problem! FYI we are going to tackle things now in alphabetical order because the Value & CoD is all the same. Stakeholder was appalled - and immediately repeated the exercise and place bets that were not all the same Value! :face_with_hand_over_mouth:

πŸ‘ 1
Leaf (Jessica Roy), MassMutual21:12:45

:rolling_on_the_floor_laughing: I've been there. Exact quotes (from a previous employer): "What's your top priority?" "Everything! Everything is top priority!"

πŸ˜€ 1
Leaf (Jessica Roy), MassMutual21:12:40

I think that was also the stakeholder who said, of the software, in seriousness, "why can't it just know what I want?" :woman-facepalming:

πŸ˜‚ 1
Gary Lesage19:12:00

I've been asked to create OKRs for 2023 and am struggling to focus between multiple priorities. Thoughts?

Kieran Neeson19:12:38

Hi @lesagegary In our experience less is most definitely more. Not unlike WIP having too many OKRs will be problematic. If I can be so bold, I would look to question the priorities and try to clarify which is really the top priority and start with that one alone.

πŸ‘ 1
Tracy (Trac) Bannon19:12:36

Hey there everyone.

❀️ 3
Istvan Bathazi19:12:52

Hi @tracybannon

Ann Perry - IT Revolution19:12:00

Welcome, @tracybannon, presenting: "#NoHobbyists: Building A Shared Cybersecurity Culture"

πŸ‘ 2
Jonathan DeMarks19:12:31

:star-struck:

πŸŽ‰ 3
Istvan Bathazi19:12:32

least you were able to get them license... some org flat out refuse to get access to security data

Tracy (Trac) Bannon19:12:53

I've had both situations!

Bryan Finster - Defense Unicorns (Speaker)19:12:38

I just added a pre-commit hook to make it harder for me to commit secrets

Bryan Finster - Defense Unicorns (Speaker)19:12:44

Harden the process!!

❀️ 1
Istvan Bathazi19:12:44

"separation of duties"

Tracy (Trac) Bannon19:12:02

Love and hate this concept; separation of duties does not mean to be ignorant of one another's set of concerns.

Bryan Finster - Defense Unicorns (Speaker)19:12:21

Nor does it mean a human must do it.

Istvan Bathazi19:12:00

but that is needed to keep our silos we worked very hard to build around teams so they dont talk /S

πŸ‘ 2
Tracy (Trac) Bannon19:12:25

YES. Teach builders to think like breakers.

❀️ 1
Istvan Bathazi19:12:51

we are developers. we don't have time to test /S πŸ™‚

πŸ€ͺ 1
Istvan Bathazi19:12:28

@tracybannon great talk !!!! thank you

Tracy (Trac) Bannon19:12:02

You are welcome! This is very important change of mindset; glad it helped!

Matt Ring (he/him) - Sr. Product/Engineering Coach, John Deere20:12:10

Interesting model here @tracybannon! I often lumped people and culture together, but there are merits in distinguishing them and the different aspects laid out here... :thinking_face:

πŸ‘ 2
Slackbot21:12:09

Reminder: The plenary sessions are starting again in 5 minutes. Start making your way back to your browser and join us in #discussion-plenary to interact live with the speakers and other attendees. https://devopsenterprise.slack.com/files/UATE4LJ94/F04DG604H1C/image.png

Slackbot22:12:09

Reminder: Please submit your feedback for the talks you attended. It’s so valuable for us and the speakers. And after all, feedback is a gift and sharing is caring! Enter your feedback for those talks here: https://doesus2022.sched.com/ https://devopsenterprise.slack.com/files/UATE4LJ94/F04DG7DQMSS/image.png