No Yelling on Pi day
Sunday was Pi Day, 3.14. It’s a sacred day for my friends who wear the iron ring on their pinky finger - and I love taking time each year to share a slice of pie with them because working with engineers is awesome. This year that can’t happen, so I’m writing a blog.
Hi Chris, this is Tom. It’s his first day here. He’s going to keep people from yelling at us.
In my career as an engagement professional, this was the absolute BEST introduction I have ever had at a workplace. The team was one of transportation engineers and technologists. Everyone in the office had a technical stamp to put on the work they did except for myself, an engagement expert, and the admin support.
There are lots of reasons why technical businesses, love it or hate it, do public engagement:
Regulations or policy
It was in the RFP
Checking a box on the project management checklist
Technical teams that do engagement understand that the iron ring doesn’t prepare them to have hard conversations with the public about bike lanes, pipeline design, bridge placement, or street lighting systems. That’s not a criticism, it's a fact that creates space to solve a problem, which engineers are damn good at.
That’s where I want to focus. Technical experts like engineers are good at solving problems and those problem-solving skills are perfect for public engagement. The challenge is to learn when and where to use those skills, which include identifying a problem to solve before starting design. A simple rule of thumb for applying this in any engagement project is to determine what decisions need to be made throughout the process.
Usually when engaging the public one-on-one or in a group, it’s not time to design and it’s not time to solve problems. It’s time to identify problems and test ideas. In the same way a public participant asks questions about why a technical design looks the way it does, the engaging problem solver needs to work hard to understand the problems the public sees. This is because the participant is the expert within the context of their experiences and they’re often eager to share their opinions, sometimes framed as opposition. The great skill to develop and exercise as a technical expert is to ask questions rather than debating the finer points of design.
By digging into the “why” behind people’s positions, a technical expert can discover new problems, maybe even systemic issues that aren’t obvious on the surface. Working hard to identify the underlying problems and values that participants see in projects will build relationships and give the most in-depth feedback possible for refining and making decisions.
Here’s a simplified version of a real world example:
A participant is outright against narrowing a local residential street because the street will be too narrow. It’s a waste of time and money and nobody will benefit from the changes.
Response 1: Yes the proposed design is narrower, however, the width meets the standard, including for accommodating emergency access. Also, the narrowed road makes room for other facilities that were asked for in previous engagement.
The conversation either ends or circles into a debate about what is and isn’t needed in the neighbourhood. We don’t get any new information. Now there’s a frustrated technical expert, and a frustrated participant who feels the process doesn’t allow them to be heard.
Response 2: Yes the proposed design is narrower. Can you tell me about how the narrower street will affect you? Is there something you won’t be able to do as a result?
The participant drops off and picks up their elderly parent in front of their home. The narrower street means they will block all traffic, not normally a big deal, it’s a local road. However the curbs are also changing with the design and the elderly parent will now have to step over potential tripping hazards. So the participant will have to park the vehicle in the street to help their parent over the changed curbs, increasing the time parked in the street, making them a nuisance to neighbours when they’re trying to protect their elderly parent.
Response 2, though overly simplified from the original, gave the engineers involved a greater understanding of the problems they were working to solve. Spoiler alert, they adapted the designs in some pretty meaningful ways at minimal cost to the project.
Solving problems is where my technical friends thrive. When they hold back on the problem-solving step so they can ask deeper questions that focus on the public engagement participant, this unlocks their greatest potential. The desire to immediately fix or explain is legitimate and speaks to the passion engineers and other technical experts have for their work. Using their expertise for problem identification unlocks great potential for creating better solutions AND keeping people from yelling at us.