Software Development

The hovering laptop

“I need my laptop to hover in the air. Who can build this, or can you recommend someone that is selling this feature?”

So, you work in technology, in some role trying to deliver solutions to stakeholders. When you receive the request “I need my laptop to hover in the air,” what do you do next?

It’s natural to want to be the first one to display your technical prowess balanced by your profound sense of how to deliver ROI (a problem I clearly struggle with, lol); listing the reasons why you can’t solve this, that the existing tooling won’t support it, or that the risk/reward is just too unbalanced to even try.

After your response, the requestor assumes it can’t be done or isn’t worth doing, and everyone moves on. Do we really know what we left to die on the table?

The example of a hovering laptop is absurd enough that most of us probably think, “I would definitely ask WHY before responding?” While that may be true, we often get requests where our assumptions about the request defeat our best intention of asking WHY?

More than ever, the stakeholders we work with tend to come to us with solutions rather than problems and are more technically inclined than their counterparts from 20 years ago. Naturally as people become more tech savvy and more aware of the techniques used to deliver solutions they become more solution focused.

We need to ask questions we didn’t have to ask 20 years ago. When people were more likely to come to you and say, “I’m not a techie! Here is what I do today; my boss told me to loop your team in to see how we can improve the process.” At this point, you’d start learning about the process they want to be improved, what data is involved, how frequently it changes, and the people involved, along with other factors, and formulate a proposed new process.

Today many stakeholders are “Solution Proposers” and technologists as “Solution Providers” we need to be experts at peeling back the layers of the proposed solution to identify how and why the requestor came to the conclusion that they need “A hovering laptop.” Maybe they are right, maybe they do need a hovering laptop.

Despite whether they are right or wrong, as a solution provider, I still want to ensure that any solution I put in place will address the underlying needs driving the request. So we start asking questions.

  • While your laptop is hovering, will you be actively using it? Is it a touch screen, will you use an attached mouse and keyboard, or the keyboard and touchpad that are built in?
  • Are you mobile while using this hovering laptop? Are you sitting, standing, or riding something?

Your approach may vary depending on the people you are working with. For some, asking questions about the solution requested can be a more straightforward approach aligned with how the stakeholder already views the outcome. Remind them that you just want to talk through the proposed solution and that you are there not just to deliver a solution but to help them make an appropriate decision on what solution best meets all of the goals and constraints they may not have shared yet.

From your initial questions the requestor may start simplifying their request:

Hrm. I guess if I’m just sitting at my desk, I could use something to lift the laptop up. It doesn’t really need to hover, per se.

Maybe the requestor has never seen a riser that sits on a desk, or perhaps the requestor is just assuming the company wouldn’t build a shelf above her desk or that the cubicle wall won’t support attaching a shelf.

Clearly, today, if we really wanted, we could make a laptop hover. It would likely come with a lot of unintended user experience problems.

We can probably find a simpler, cheaper, faster to deploy, and less likely to fail solution. We just need to get to the WHY. We can only do that through curiosity and understanding of what brought the requestor to suggest the specific solution they did.

This post is getting pretty long, so I’ll just end it by saying: Don’t lead the conversation by enumerating the reasons you can’t deliver what is being asked. First seek to understand why you are being asked for a particular solutions.

Leave a Reply

Your email address will not be published. Required fields are marked *