Hey all, not sure if this is more of a #platform-culture or #platform-leadership question but I'll ask here and cross post there (hope that's ok!). Looking through the various content in here, and searching around in general, I definitely see a trend towards Platform Engineering as a focus on the tools and systems that provide this capability, but unless I'm looking in the wrong places, I don't see a great deal on things like how do you gather the initial feedback from developers on what things they need that would help improve their experience and productivity? There were definitely great sessions at PlatformCon24 that encouraged this thinking, but I'm looking for practical tips and techniques on how to gather that feedback effectively. Developers are busy people (most likely too busy doing things they shouldn't have to of course), so trying to rope a suitable number and subset of devs into interviews is probably going to be a rather challenging exercise. Can anyone shed some light on how they go about this at all or help me search better?

Disclaimer: I work with a company that runs developer experience surveys as part of a platform, so I have a biased view on this. People hate surveys for a few reasons: • They usually take a long time to answer/run • They don't see the results of their own surveys, nor do they know exactly where it's going • They don't see the action from them That said, if you're trying to get feedback from a lot of engineers, they work if done right. These are 2 resources we have on running developer experience surveys: https://getdx.com/uploads/devex-survey-guide.pdf https://getdx.com/uploads/developer-experience-survey-template.pdf

Thank you kindly, I shall have a read! My experience tends to reflect yours in terms of how people view surveys, so my thinking would be you need a mix of interviews with those who you can get the time with, and a useful survey with follow on sharing of what came out of the survey.

If you're working with smaller subsets of engineers, interviews are the way to go, but like you said, when you have larger numbers of engineers, it becomes very tedious, and you'll also run into the 'loudest voice in the room' danger more often.

Yep, makes perfect sense 👍 To give more context on my specific situation, I work for a product development/software engineering consultancy, so I'm trying to understand what our team members face while working on client projects that hamper their productivity, and what they observe in our customers that hamper their productivity.

Given that context, I'd imagine you have a good bit of variance from project to project, compared to working with an internal organization only. I wouldn't actually recommend a survey for that just because I don't know exactly how much the environments, toolsets, etc. varies based on the project and client. Might be worth asking @Bartek Antoniak about that since I think he does some similar things with Virtuslabs

Yeah... I've had a false start already with one of our internal communities where only 3 people showed up to the call, so I think I have some internal marketing to get right to get some better attendance 😁 I was intending to garner input in an interactive session, but I don't think that message got out loud enough.

Anytime man, glad you like them! The bulk of the research I tend to believe is the stuff that points to the ideas that reducing cognitive load, and making the developer experience as smooth as possible is the best way to drive productivity in organizations, vs other approaches including but not limited to: "Work harder you lazy developers, I need more lines of code!"

Yes indeed! In my leadership roles I've always seen the key thing I need to do is help get all the crap out of the way to let my team "get shit done", whether that be ops teams or developers.

one more, easy read

Thank you kindly Jordan, that is very helpful indeed! I particularly like the fact you get to slide 12 before you talk technology (with sensible caveats)!

We were so fortunate to have a service designer coupled into our area for quite some time and she did go on journeys out interviewing people in different aspects...and the developers loved that they were being asked about workflows, issues, wishes and dreams and everyone found the time to do it as they saw it of high importance

That’s awesome!

When it comes to gathering feedback I think most of the time people are quite happy to do so if they get the impression that it'll actually be used and it has a relevance to what they are working on...aka tell them what you want to improve/invest in and why it matters to them

Ah yes, why is always a good starting point!

cc/ @David Stenglein for the PaaP work in the CNCF!

one more - https://tanzu.vmware.com/content/white-papers/vmware-tanzu-labs-product-manager-playbook

Thanks again Jordan! I just realised I definitely have been looking at this all the wrong way around... should've been taking a "Platform as a Product" view and looked at it through a Product Management lense!

you are on the right track

Cheers!

Pete - one of the most valuable things you can do is understand their experience. Arrange to shadow some developers for a day or a few hours to get an idea of how they do their work. This helps with the issue of people stating what they want with their own biases towards technical solutions and gets you looking at actual needs.

That would be ideal, and used to be possible with my ops teams when I was embedded with them, but these days in the consultancy world I only get to see one client project at a time. Right now being between clients it gives me some flexibility time wise to get to know some other teams and experiences though. My last client project showed me many things impacting their experience!

I also like the Gemba Walk, but I always trip over the name :-)

In addition, what has been mentioned before (which I second that). Speaking from the software engineering consultancy perspective, in our case embedding a fractional engineering lead to client engagement is an interesting way to measure developer productivity and keep up with all other project-related intricacies (do not mix this with account management). Such person is working closely with the client leadership team and your team helping with solution architecture, decision process and more. Not every client will be keen to pay extra so you need to somehow blend the price of it.

Yes, that is indeed a challenge! We have clients we work with in that capacity, but others in the startup/scale up space just don't have the room for that in their budget, but in those cases we do our best to inject good engineering practises where we can by embedded at least one of our more senior engineers, and also running workshops with their teams etc. as well.