This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
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
Welcome @karthik.gaekwad, here to present: "Benefits and Success Strategies Learned from Google’s Internal Devrel Teams"
Hello, I do not seem to find the recording in the video section. Will this still be uploaded?
Let me check!
Hi y'all! Excited to be here- let me know if you have questions!
Some conferences we hold internally at google are developer related for serverside developers, web developers, mobile devs etc.
It's a way we bring folks together to discuss ideas/teams etc
So the documentation you are refering comes completely from you and your team or is it the existing onboarding / developer doc that you revise?
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
Ah, yeah. That makes sense. Thank you
@karthik.gaekwad - is this a role embedded into every product team or a separate team?
Love this question!! I touch on this in the presentation on how it has grown over time!
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
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
but i'm assuming it's an evolution/capacity play where you might start external and build muscle strength in teams?
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.
Prioritization of what products are represented by devrel is key..
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.
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.
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
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!!! 🙏 )
Good to see you Gene! Thank you for having me, and miss seeing you!!
Right back at you!!!
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?
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.
@karthik.gaekwad How did those complaints initially surface to the point where someone was willing to take action and funt DevRel?
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.
Really good docs allow the platform to scale better. 👏
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
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.
Helps to think about it with context of "why is someone going to read this doc"
I love the idea of using analytics to understand your user communities and what to do more and less of.
Imma big fan of answering questions with the docs to test the docs.
💯 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).
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.
and technical writing is an art - love calling it out as a specific role
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
Thanks, Carl!! I will check this out!!
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.
Just watched the whole thing- g3docs is now the standard way we host tech documentation at google. Nice to see this evolution!!
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...
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 🙂
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"
Do they do any metrics on when the age of the docs begins to diverge from the age of the code it covers?
(of course that assumes the dependency chain is mapped)
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).
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.
That's nice that there is a default (yearly), but can be specified differently within a project with the documentation.
At Walmart, we had a dedicated team for curating docs and doing training for the delivery platform.
This is awesome. What kind of training do y'all do @bryan.finster486?
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.
It’s something people underestimate the importance of.
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.
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
How easy / difficult was it for anybody in the org to propose a community contribution?
@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.
it was just a pull request away @mring
It was documentation as one of the products in the delivery platform.
Funny! I am currently trying to define what a community contribution is for our organization to clarify what is in that umbrella..
@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.
Awesome talk, @karthik.gaekwad!!!!
Thank you @karthik.gaekwad for the awesome inspirational talk. Opened up a few thoughts in my head 🙂
Thanks for the talk @karthik.gaekwad!
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..
Thanks @karthik.gaekwad, great to get the perspective of someone who has a team of more than one 😂
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.
Force multipliers are important there!
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..
Happy to answer any follow up questions and I'll be on here for a while!!
Welcome @dana.finster, presenting: "Team Diversity, Autonomy & Cohesion - What do they really mean?"
Hi everyone! I’m excited to be here with you for my first DOES Virtual presentation!
Hi @dana.finster! 😀
Hi, @dana.finster — “autonomy” is something you don’t hear related to information security that often! 😆 So good to see you!
Hi @dana.finster. Look forward to the topic.
What are some tactics for creating a team with shared ownership?
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.
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.
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 🙂 )
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.
Great talk @dana.finster!
@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.
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.)
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?"
And then we use a Likert scale (5- or 7-points) to quantify respondent's sentiment to these things.
Thanks for all the info! I will definitely look into those resources.
Thanks! Great talk @dana.finster
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.
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
Welcome, @kieran_neeson, here to present: "Experimenting with Agility and Flow at Waters Corp"
Sorry that was shorter than expected guys!
I am happy to answer any questions
And I would love any feedback you might have to help me improve that presentation
@kieran_neeson great insights! Can you share a bit more insights on how you are achieving probabilistic forecastic and planning?
@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.
"Things we mucked up -- everything" 😂. Hooray for experimentation and learning.
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
@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
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.
Here is the link @arun.chawla https://www.pushkin.fm/podcasts/against-the-rules/respect-the-polygon
We were chatting internally this morning about platforms and products. Any insights you could share with your experimenting in this area would be appreciated.
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.
Nice talk, would like to learn more about dynamic prioritization
The model @kieran_neeson used was very engaging using beers, holidays and family cars, but I’ll let him describe it
Okay, I wanted to know, now I really want to know 😂
Me too! you had me at beers
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
Apologies for the long response there I'd be happy to show this off line any time
That is fantastic!
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:
: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!"
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:
I've been asked to create OKRs for 2023 and am struggling to focus between multiple priorities. Thoughts?
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.
Hey there everyone.
Welcome, @tracybannon, presenting: "#NoHobbyists: Building A Shared Cybersecurity Culture"
least you were able to get them license... some org flat out refuse to get access to security data
I've had both situations!
I just added a pre-commit hook to make it harder for me to commit secrets
Harden the process!!
"separation of duties"
Love and hate this concept; separation of duties does not mean to be ignorant of one another's set of concerns.
Nor does it mean a human must do it.
but that is needed to keep our silos we worked very hard to build around teams so they dont talk /S
YES. Teach builders to think like breakers.
we are developers. we don't have time to test /S 🙂
@tracybannon great talk !!!! thank you
You are welcome! This is very important change of mindset; glad it helped!
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:
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
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