This “Build a Bridge“ question is from my list of interview questions I like to ask.
It works for best for a Product Manager role, but can also be used for an Engineering leadership role…

If, as a product manager, you wanted to have engineering build a bridge, how would you convey that to engineering?

If it’s an engineering manager or director that I’m interviewing, I flip it around and say, how would you interact, what would you ask when a product manager comes to you and ask you to build a bridge? The other aspect here is how a manager of engineers or PMs presents problems to their reports. Are they empowering or dis-empowering?

Level 1 Answer – The pure How (solution statement)

The simple answer given is along the lines of I’ll give you (ask for) all the requirements for building the bridge including materials, numbers of lanes, whether it should be a truss, suspension, cantilever, arch, cable-stayed, beam, girder, pontoon, etc.
How many resources and how long will it take for you to build that bridge?

Level 2 Answer – Still a How, but some of the what (combo problem and solution statement)

More on requirements such as what is moving across (pedestrians, bikes, cars, trains, semis), how often, peak load in numbers and weight, …), how far apart, how windy, what climate…

This is still a “how” as they are proposing a bridge of some form is the solution, but they are leaving you to decide the type of bridge, materials, etc

Level 3 Answer – What (problem statement)

I have had some product manager candidate recognize without prompting that they should never ask engineering to build a bridge. They should say this is what I need to get from A to B and how often and how far apart A and B are. They provide more context to the problem

• Oh, your kids need to cross a creek on the way to school – got it, we’ll build you a rope swing
• I see, you’re talking about San Francisco Ferry Building to Sausalito – got it, I build you a ferry system
• Ah, you’re talking France to UK, got it, I’ll build you a Chunnel

Here, I like to help illustrate the importance of a good problem statement by observing traffic on the Golden Gate Bridge and the San Francisco Bay Bridge. Neither, in their design, took into account that more traffic flows in one direction in the morning and in the other in the afternoon. However, the Golden Gate is all on one level, and now they shift the middle divider to allow more lanes in one direction in the morning and others in the afternoon/evening. That’s not possible with the Bay Bridge.

Level 4 Answer – Why (meta problem statement – why is this a problem looking for a solution?)

This is where it gets interesting. They don’t start by saying this is what needs to get from A to B at this distance and this frequency, they instead explore why is it that these people/things need to get from A to B, what is the motivation, what existing solutions might exist, …

• Let’s say there already is a narrow bridge to Staten Island Technical High School and the issue is that it gets jammed up with parents and kids all driving across at the same time and kids getting to school late and parents being annoyed due to the time sync… What if instead of widening the bridge or building a new one, we build a parking lot on the mainland side and have buses ferry kids across the existing bridge?
• Or, people need to commute from Oakland to San Francisco to get to work and the bridges can’t handle the capacity during rush hour. Do we want to compete with all the other bridge builders, or do we look for other opportunities presented by the “why”? Perhaps offering rental office space with good teleconferencing on the side of the bridge where people live, or better tools for working from home, …

Does the candidate demonstrate and understanding of why we want to be open to creating insight into a market for a solution that is completely different than the one initially conceived?

Is this the kind of Product-Engineering thinking we want if we want to disrupt a business that’s been in existence for centuries? This kind of thinking is what results in thinking about an automobile instead of a faster horse…

The other thing that happens with Product Managers that operate closer to Level 1 on the continuum is that this reduces the connection to purpose and craft engineers and engineering leaders when they are told what to build and how rather than being a problem to solve where they, as the experts arrive at the optimal solution themselves. You often find this approach in large organizations that aren’t primarily software houses (such as banks, insurance companies, large retailers, etc) where the developers are seen as IT or programmers rather than as engineers. It is hard to attract and retain good engineering talent into such a culture.

Henry Ford, Innovation, and That “Faster Horse” Quote

Henry Ford is rumored to have stated:

“If I had asked people what they wanted, they would have said faster horses.”

When engineering teams encounter a production issue, a common practice is to do a Root-Cause Analysis through asking 5 Whys, an approach developed by Taiichi Ohno, one of the inventors of the Toyota Production System and described in his book Toyota Production System: Beyond Large-Scale Production. This helps a team not only understand the immediate cause of a problem, but also what led to that problem existing to begin with. In coming up with a Problem Statement, there is also value in doing a 5-Why analysis, for example:

1. Why do we need to build a bridge?
   To get people from A to B.
2. Why do people need to get from A to B?
   Because the live in area A and work in area B.
3. Why do they live in one area and work in another?
   Because offices are located in area B and housing is nicer/more affordable in A.
   This could lead to a few different next why questions
4. Why do is housing so expensive in area B, or
   Why area there no offices to work from in area A, or
   Why do people need to be in the office to be able to accomplish their work?
   The answer to the last may simply be because that’s the assumed way to work, or people aren’t set up to work effectively from home – both of these were put into question during Covid.
5. Why can’t we enable people to work more effectively from area A?
   This could be because they don’t have the right equipment or tools to work from home, or because there isn’t shared work-space available in area A.
   Understanding this underlying root cause of the problem could lead to arriving at solutions that not only don’t require a bridge but might not even require some people going from A to B every day.

Empowering engineering teams to find the optimal solutions

Furthermore, when Product or Engineering Managers offer solutions rather than problem statements, they not only dis-empower and demotivate their teams, they create an expectation that the solution will always come from the Product/Engineering Manager – who then, in turn is surprised when they don’t scale and feel over-burdened. Liz Wiseman speaks to this (see below). It’s the question of wanting to be the 10x contributor vs the leader of 10 10x contributors – in the end, do you want to have a 10x or 100x impact?

In my experience, Dan Pink exploration into the topic of what motivates us Drive – The Surprising Truth About What Motivates Us, is particularly applicable to software engineers:

• Autonomy (Don’t micromanage – it’s a sure-fire way to take the wind out of their sails.)
• Mastery (Help find ways to master their craft; show genuine appreciation for it.)
• Purpose (Why do you come to work, why do you work for this company and not another, what, in your eyes, is our business’ purpose, how does that align with what you see as your prupose, and what do you hope to impact by working at here?)

See also Liz Wiseman:

• Book – Multipliers, How the Best Leaders Make Everyone Smarter
• Video Summary: Liz Wiseman – Multipliers Highlight Reel
• Video Summary: Liz Wiseman – The Accidental Diminisher

See also TED Talk by Dan Pink: The puzzle of motivation or for those a slightly more fun/visible interpretation: