What does it mean to know why over what?

What I do

A focus on “what” we do creates many problems. It’s easy, though. It’s the first thing that comes to mind. I write code. I test. I gather requirements. I manage projects.

Unfortunately, when we do this, it’s easy to lose sight of why we do it.

You’ll notice this when project managers take people off the floor for hours (or days) to get the plan perfected. They’re so focused on what they do (manage the plan), that they inadvertently take too much time and attention away from value delivery.

The client doesn’t want a plan. We will use plans, but the value we’re delivering is software.

7. Working software is the primary measure of progress.

This isn’t a project manager problem; it’s a human problem. Engineers may try to sequester themselves for weeks to perfect something because “what” they do is write code. They see all those client conversations as waste and don’t want their skill to be called into question if there’s a defect.

Clients want problems solved and value delivered today, not something perfect years from now.

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

We could harass analysts and testers as well, but hopefully you get the point. Thinking about what I do is a distraction from our real purpose.

What To Do

Too often teams have a backlog of solutions awaiting engineers to simply write the code. This is a symptom of an organization built around “what we do”, but the practice can exist in other environments. A focus on “what needs to be done” is destructive.

It makes the assumption that we understood the problem when we wrote down an answer. It assumes that the need and the tools won’t change between writing the answer and implementing it. It assumes, that those designing the solution know the right architecture better than those implementing it. It assumes that the engineer has no creativity to bring to bear. It assumes we don’t need to work with the client anymore, we already did. It assumes we won’t learn more about the solution as we go. We should.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

The key concept here is emergence. If we focus on what to do, we will be anchored on a particular solution. Our goal should be tapping into our collective talents and creativity to arrive at the best possible minimum solution.

No matter how smart or creative the person who wrote the solution, a team of skilled and creative people working together will create a better solution every time. By focusing on why we are doing the work (the problem that needs to be solved), we invite collaboration. We invite creativity. We invite better solutions.

Using Why

It can be hard to focus on “why” over “what”. It’s easier to “just write code” or “just manage projects”. Worst of all, the constant focus on “why” can turn into a tireless process of always questioning everything. To be successful, you need to get more comfortable with this. But there are some simple steps you can take.

The easiest, is to start practicing writing and working with user stories. These are a good way to think about why we’re doing things to invite a discussion.

As to what we do (our actual role) and how we invest our time, there is no easy answer. Always ask yourself if what you’re doing is adding he most value to the client of all the options in front of you. The horizon for this measurement should also be near term; today, this week, this sprint. That’s it. If what you’re doing is adding the most value for six months from now, you’re doing it wrong.

Challenge

Is what you’re doing today the most valuable thing you can do for the client?

Are you doing the work you have because it’s your role, or because what you’re doing is contributing client value?

Is there some other role you could take on, some assistance you could offer, or something else you can do that would deliver more value to the client than you are today?

Why do you do what you do?