The 6 Ws of Software Development
Every story begins with the first word. Every drawing begins with the first stroke. Every journey begins with it’s first step. Solving a problem or creating something new has a beginning, a middle and an end. I wanted to share some thoughts on what I have found to be effective to help me and the teams I have worked with solve problems or deliver new capabilities well. Disclaimer: this post is not blanket advice and there is a spectrum of complexity where there are diminishing returns on any methodology. Here are a few steps that I wander down when trying to solve both really hard problems and the occasional easy one.
First and foremost when solving problems I try to always remember that the work we do involves people and all that that entails. People are not computers, they are not binary ones and zeros. Their state is a continuum and emotions are always in play. Kindness and respect are important because there is nothing worse than emotional debt in the work environment. Another aspect of understanding people are involved is to try and understand why something must be done and what are the constraints around solving the problem. There have been many times where the problem was only a problem because the humans involved were lacking a shared understanding.
Secondly, in most problem solving scenarios I firmly believe you should have a bias towards action that incorporates data in a tight feedback loop. Wandering around the forest quickly in the fog does you no good if you are not taking notes or marking your path. The data will tell you where you are and then you can make a small change, examine the data, and keep going until you find your solution. There are innumerable times where this tactic has served me well both in debugging but also in delivering value to customers incrementally. Minimize the things that are changed in order to isolate the minimum that must be changed and to keep the cost of change low.
Third, an understanding of your constraints is critical to solving a problem the best way possible. The best way being delivering what is actually needed to have a positive effect on the outcome of all involved (customer, business, engineers, support staff etc.). To accomplish this some shared understanding between the business, technical, product, design, and user experience sides, will allow you to define constraints with empathy and clarity. As I have learned more about user experience, or business demands I have been able to make better technical choices in my career that have provided real value. When team members have empathy and respect for each other’s work they can have honest discourse about why they are doing the work they are doing, what work should actually be done, who can do the work, how that work should be accomplished, when it should start or end, and be able to articulate where the state of that work is. These are the why, what, who, how, when, and where of software development (the 6ws).
It is important to understand that titles and roles try and capture who should have the primary responsibility of the different aspects of the work to be done. However, titles and roles are imperfect abstractions. The team should understand who has the primary responsibility to resolve the why, the what, the who, the how, when, and where and that as a team they support each other in ensuring they all have a shared understanding of all those aspects of the work. While I may spend a great deal of time on the technical how of solving a given problem I will make the wrong choices if I do not incorporate the other aspects into my recommendations of how to move forward. I need the why to be clear, I need to know when things need to be delivered, I need to understand where things are etc. Shared understanding is critical and allows amazing things to happen because people can focus on their area while trusting what they are doing is moving the project forward. Shared understanding is a super power of highly effective teams.
Understanding the why informs your constraints and allows the team to focus on its respective areas of execution. For example if I understand why someone might describe a given feature as incredibly important to the customer I can be more creative about how I can solve that problem, I can discover if maybe something less complex would satisfy that need and be able to be delivered incrementally. If the team knows what is to be done and who is working on a given task then there is less coordination required and combined with the shared vision I can trust they will make local decisions and respond to change within their teams bounds and those decisions will not be at odds with other teams they are not directly connected. Vision is really hard to both define and communicate effectively. However once done amazing things can happen.
I think of a lot of our work can be boiled down to a very simple analogy. At the beginning of any project the leadership begins to start sketching the outline of what needs to be accomplished, they start sketching the actual vision. As the project goes through various phases different people add their perspective, they add more detail and they clarify constraints and design along the way. Through this process the drawing begins to take shape. When I was in my teens I used to draw and I loved this book entitled “How To Draw Animals” by Jack Hamm. The book was amazing to me because it taught me how to draw rough shapes and then from those rough shapes build out more complex structure until I had a complete animal. It taught me that most animals can be drawn using circles and rectangles and that if I can define the rough shape of something it is a lot easier to draw a more detailed picture of that thing that appears proportionally correct and aesthetically pleasing. I think the process of outlining and defining areas applies to software engineering just as well.
When we understand the why everyone can take a portion of the drawing and start filling in detail because they know what the final drawing is supposed to be. The vision guides people and the outline defines the strategy to follow. The rough sketch provides bounds for each group to work in. Once the broad strokes are decided then the group can decide what should be worked on together within their bounds. Understanding who is responsible for each area allows discussions about changing the bounds, the constraints, and allows positive resolution and coordination about when a given area should start receiving more detail. If you are unable to subdivide a problem then it is difficult to not have teams drawing all over the same area and interfering with each others efficiency and outcomes.
Understanding the bounds of the problem is also important because it helps people understand the ownership of a given area. It is clear who is responsible for detailing out the rough sketch and who is going to take the rough sketch and turn it into a finely detailed drawing. As I have been involved in architecture these past few years I have discussed more and more at length the concept of functional areas being defined as almost more important than the given systems we build. Having clear vision over specific areas and clear ownership (which includes authority and accountability) of a given area will help scale decision making because it lessens the complexity of driving consensus. Your organization as a whole can only move as fast as your decision-making process because of momentum. Also, if nothing is certain, if everything’s sketched in pencil, then you may have whole swathes of your drawing that have to be redrawn over and over again because boundaries and constraints constantly change.
Finally, I strongly believe that a culture of honesty with empathy will lead to better outcomes. A psychologically safe culture allows for real problems to be discussed and fixed instead of just patching over symptoms. I also firmly believe that if a group of people is able to understand the who, what, where, when, why and how of their work they can do amazing things. In my last almost six years of working at Workiva I have witnessed many teams come together, work really hard and solve amazing problems because they followed these principles to drive shared context and decision making. I do not discount how difficult this can be and how much effort it takes. I would encourage everyone to have a little more empathy and inject a little bit more kindness into their interactions and start applying these principles to their decision-making and problem-solving processes. I know that a sprinkle of the who what where when and how can make a big difference in any project.
