Building Bridges Between Product and Engineering

Golden Gate Bridge from Kirby Cove

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 disempowering?

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
  • Oh, you’re talking about San Francisco Ferry Building to Sausalito – got it, I build you a ferry system
  • Oh, 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. 

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:

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

RSA ANIMATE: Drive: The surprising truth about what motivates us

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.