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

Let me check!

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

Ah, yeah. That makes sense. Thank you

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..

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

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

Right back at you!!!

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.

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.

💯 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.

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.

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.

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..

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.

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.

@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?"

https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/foster-psychological-safety

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.

@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.

Thanks!

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

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.

Thanks

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:

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.

I've had both situations!

https://github.com/thoughtworks/talisman

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.