Deliver Sessions: Back to school

Poster for the event: a photo of inside Auto Trader's offuce, with chairs, plants and a car.

Has the "Back to School" title, then: "Wednesday 25th  September, 6pm. 1 Tony Wilson Place, Manchester M15 4FN"

Deliver Sessions logo, and "Hosted and supported by Auto Trader"

Deliver Sessions meetup took a Summer break, then returned in September 2024 – this time, to Auto Trader‘s office in Tony Wilson Place. We had a range of speakers sharing what they’ve learned from trying out new things at work.

The power of “I don’t know”

Chris Burns (head of product) has been reflecting a lot on this phrase recently. It’s often seen as a weakness, even when we talk about being OK “to admit you don’t know”. Chris started by reframing that: it’s not about “admitting”, it’s stating a fact. What stops us from just being fine with that?

Photo of a slide: "Fear of judgement" Bullet points:

Not knowing reflects on my intelligence or capability. 

I'll be seen as less competent, that's embarrassing. 

Reduces credibility - I'm supposed to be the expert. 

I've not spoken for ages and feel I should say something.

He toured a wide range of possible reasons – fear of what people will think, pressure to respond (with something, anything), imposter syndrome, and more. Chris has worked through all these in the past, but new reasons to hesitate keep coming up. Most recently, when he moved to a new company in a more senior role, he found himself wondering if “I don’t know” would make it look like he hadn’t learned fast enough, or otherwise undermine him.

He’s worked through these new hesitations – and has been practicing turning “I don’t know” into a positive statement.

  • if your role involves coaching or guiding people, showing vulnerability is important – it encourages others to share their own uncertainty, or to suggest answers you could try.
  • in product development, we deal with uncertainty lots and have tools to deal with it – you can move this into more work situations, encouraging curiosity, exploration and collaboration.
  • you saying you don’t know can remove pressure for others to feel they need to be perfect – not knowing things is part of the process, not a personal failure.

There’s a range of phrases you can add after “I don’t know”:

  • “… can I get back to you?” (a chance to talk again, keep a promise and build a relationship a little more)
  • “… what do you think?” (especially for more junior people, encourages ideas and confidence)
  • “… who do you think could help with this?”
  • ” … but I’d love to learn more about it”
Last slide: "I don't know what you'll do with what I've just shared, but I look forward to finding out... Thanks for listening."

QR code for Chris's LinkedIn.

Making meetings accessible

Sophie May and Charlie Cowley (delivery leads) talked about what their delivery community has done to make meetings more accessible. Accessibility’s something Auto Trader takes seriously: everyone who joins gets accessibility training, aimed at answering the question “Blind people can’t drive, so why should Auto Trader care about accessibility?”

Photo of a slide with lots of reasons someone might have temporary, situational, or permanent accessibility needs (e.g. arm injury and bartender). These images and descriptions are from the Microsoft site linked after this image.

Text: "Solve for one, extend for many. Accessible design is good design - it benefits people who don't have disabilities as well as people who do. Accessibility is all about removing barriers and providing the benefits of technology for everyone."

They referred to Microsoft’s inclusive design guidelines, which explain how much accessible design can benefit everyone, and shared some stats from the course:

  • Of 14 million people who visit the Auto Trader side every month, what percentage have some form of accessibility need? 70%.
  • What percentage of disabled people and their families have walked away from UK businesses because of poor accessibility or customer service? 75% (source).
  • Average reading age in the UK is 9-11.

You can estimate how many people might have which kinds of accessibility needs for any website, based on the number of visitors it gets, using this online calculator: How many?

Sophie’s visually impaired, and talked through examples of things that have helped her as a facilitator and as a participant.

  • For in-person sessions: asked people to write big, clearly, and don’t use green pen.
  • When she’s a participant, asked in advance if post-its can be read out once they’re up on the wall – this helps lots of people, otherwise you’re jostling for space or looking at the backs of heads.
  • Asked for slides to be shared beforehand – Sophie can have these open in a separate window, allowing her to zoom as much as needed to read them.

She also shared advice for facilitators:

Always ask in advance of a session if there’s anything you can do to accommodate people’s needs. Things like cameras on to allow lip reading, sharing links to any docs/boards in the chat rather than just screen sharing, and more.

Sharing an agenda, and purpose, is very important – lets people prepare thoughts in advance. If people have to work harder to follow conversations (zooming in on Miro boards, lip reading, etc), knowing more about the context of the meeting can help hugely.

When you do something for the minority, it makes things better for everyone; lots of the ideas shared in this talk make meetings better for everyone.

For lots more on this topic, they pointed to an episode of Auto Trader’s “Roadmap” podcast.

Shipping games solo

Jay Faulkner (software engineer) shared her story of building and releasing a game, on her own – and doing her best to cover all the varied responsibilities that she was used to leaving to other people in cross-functional teams.

During lockdown, lots of people got very into gaming. Jay’s game of choice was Elite Dangerous: “a procedurally generated thing of beauty” that lets to fly around a galaxy modelled on our real-life Milky Way. She discovered a forum where people organise races – they shared screenshots of some planet, draw racetracks on it in Microsoft Paint, then all meet there in the 3D game and compete. Joining in, Jay found it took 2.5 hours of real time to fly to the chosen planet, and the game was actively hostile to letting you play a race. But people loved it! Jay thought making an actual racing game, inspired by what people were trying to make Elite Dangerous do, would be a nice project to practice some game dev skills.

She immediately started hacking away to get something working… then managed to stop herself. She realised she didn’t know what anyone wanted. Basing all your architecture on the wrong idea would be so bad. In a previous job, Jay had worked with user researchers who were passionate about dragging along anyone on the team who’d come to meet users. Engineers should go and listen, take notes: your job isn’t to get Jira tickets done, it’s to build something for a person to use.

Slide, titled "Do it properly!"

"Don't just spend 20 minutes on Google 

Really, spend as much time as you need - I could argue months. 

Find people who make YOUR domain THEIR obsession - they exist! 

They will become your most avid fans and build a community"

Jay spent lots of time with that community of racers, and with other gamers – and shared a range of things that were valuable:

  • All the “fun stuff” is a distraction, and a trap: you need to find out what’s essential, and prioritise (”eat your damn vegetables”).
  • Get familiar with one-way vs two-way door theory: Which decisions matter (horrible to change later), and which don’t?
  • Get a whole, skeletal system first, to get the basic product into playtesters’ hands ASAP.
  • If you did your research properly, those people will be your enthusiastic testers – include tools to provide feedback (Jay’s game had links to a Discord community that got very active).
  • Sending a first version out for feedback is very daunting: You will always be wrong about what people wanted, and it’ll be broken in ways you just didn’t think to check. But not only did Jay not get hate, she got unsolicited donations: people really wanted her to keep working on this!

One thing Jay hadn’t expected: lots of players are really into adjustable parameters. As well as endless variations of flight sim controls and devices, she added options to adjust everything about the vehicles – mass, thrust, angular drag, rotational (torque) multiplier), and more. People enjoy exporting their setups to JSON, pasting it into discussion groups and trying out each others’ ideas.

In addition to the good stuff, there’s lots Jay would do differently if she started again:

  • No analytics – despite her good friend (product manager) repeatedly saying these were important from the start, Jay thought it’d be fine to add these later. Missed out on so much good feedback.
  • Added multiplayer – took months of work, capable of 128 players at once, and a grand total of 6 people have ever used this. All people really wanted was competition – once Jay realised that, adding a shared leaderboard was trivial.
  • A range of other “oh is that what you really needed” revelations – helped properly understand that what people often ask for is their idea for a solution to a problem they haven’t told you. Always dig deeper, and keep thinking: what solves the greatest number of problems for the largest number of people with the least amount of effort?
Slide showing the game's Steam page - link to this is right after this image.

You can try out the game – it’s free! – on Steam: Fly Dangerous. Or to see the code, roadmap, and lots more, visit its GitHub repo.

More from Deliver Sessions

We’ve been very lucky to hear from a range of speakers who care so much about the interesting things they’ve been learning and practicing. There’s time for just one more Deliver Sessions meetup in 2024 – follow the meetup to get emailed when new dates get booked. And, get in touch if you might like to present something yourself!

To keep you going in the meantime, see all the Deliver Sessions posts.


Posted

in

by