A strategy for understanding purpose, perspective, scope, and impact are you working on? are you working on it? is it going to have an impact? What Why How These are the 3 questions I always ask the engineers I work with. Knowing the answer to these 3 means they are more likely to be engaged, show more initiative, and have greater understanding of the end goal. It helps guard against over/under architecting, prevents unnecessary work, and helps manage tech debt. It ensures that collaboration and knowledge sharing occurs in the planning stages. In Agile software development, the is usually defined in the stories for the sprint. The part that is usually not defined well, if at all, is you are working on the task. your work is expected to have an impact is often left to predictions. were those predictions arrived at? , , and are questions that should be asked up front, and fully understood by the engineers and product. Engineers that only understand are basically code monkeys. what why How How What Why How what — description of the work to be done — purpose behind the work — how the work will have an impact What Why How The worst case scenario is engineers understand what to build, product management understands why, and sales/marketing understands how it will have an impact. The visions are aligned, the perspectives are different, and the execution is divergent. Over time this divergence will result in a system that is misaligned in its architecture, has extended development timelines, and has a restricted implementable feature set. Often enough the work takes 2–3x longer than anticipated. Tell a great engineer what to build and they will build something great. Though it may not be what product had in mind. The engineer delivered a well architected feature when product needed an MVP. The engineers didn’t truly understand why they were building something. Product isn’t happy with the results and engineers feel under appreciated. Scaling up What, Why, and How Asking what, why and how at the individual contributor level can reveal a lot, but it’s not enough. The scope of the questions should be expanded iteratively to include the team/company and customer. This can be illustrated in a matrix of 9 questions. 9-box Question Matrix By iteratively expanding the scope you should be able to gain greater insight into the value the work will provide at multiple levels. This should reveal how the work fits into the bigger picture. If you struggle to answer any of these questions at any level, perhaps it’s not the right thing to work on at this time. Try to discover why you can’t answer the question. Me (Individual) Asking these questions at the individual level will provide clarity and help one understand the purpose behind the work from a business standpoint. One can also ask these questions on a more personal level to help guide career direction. Why are you the one working on this? How will it help your career? How will this work help you learn and grow? Perhaps someone else on your team should be working on this. If the work isn’t challenging to you, but will help another team member gain experience and grow, they should be the one tasked with the work. Us (Team) A team of 5 working on 5 different things is not a team. Why are they, and not another team, working on this project? How are they going to have an impact by doing this work? How will this work help the team be more effective? These questions can reveal a lack of synergy and reasons for inefficient teams. The questions help align the team on what each person should be working on. The team should be working toward a common goal. Them (Customer) These questions will help you get a deeper understanding of the customer’s wants and needs. What the customer wants doesn’t always align with the company’s vision and mission. Why should you build this for a customer? Why is the company pursuing this opportunity now? How does the customer’s needs align with the product vision? Should this work be done just to close a sale? Most developers, managers, and leaders know that the earlier you can catch problems, the cheaper they are to fix. Having a strategy to ask the right questions up front will have an impact on the success of any engineering project. Try applying this strategy to a project that was started and subsequently cancelled. Perhaps you would have discovered up front that it wasn’t the right project to work on, or needed more research. More Questions These 9 questions aren’t designed to provide all the answers. They are designed as a starting point to make sure all the right questions are being asked. These questions are just as likely to lead to more questions as they are to lead to answers and understanding. They help you flip a project around to look at it from different angles. At the highest level/scope these should help reveal projects that may be good for the customer, but wrong for the company. At the lowest level/scope they should assure there is a deep understanding of a project by everyone before starting on it. These questions should also help answer who should be working on a task or project. Is the right person assigned to work on it? Is the right team working on it? Is the project even something that the company should be working on? If you can’t figure out why a particular team should be working on a project, then maybe it’s not a project that should be worked on at all. P.S. Not all managers will appreciate you asking every time they ask you to do something. why Related Links: Simon Sinek TED Talk: Start with Why 9-Box Review Model
