Owning a Project vs. Owning a Problem Space

I had an interesting conversation with a team member yesterday. He was frustrated by the recent priority change on his project. He worried he wouldn’t be able to finish anything meaningful this year. I gave my regular manager’s talk about change: “change is inevitable but you can grow no matter what life throws at you, if you are willing to keep a growth mindset...yadayadayada” Then it occurred to me: he was complaining about his project change because we found a more efficient way to solve the problem, probably without changing any code. So his original project was not needed anymore. The problem space assigned to him didn’t really change. It has always been the same problem space. Is that a good change or bad change? Well, it depends on his perception of ownership: is he the owner of a project or the owner of a problem space? Project ownership is temporary. A project by definition has start and end. It has bounded scope, a clear goal and its measurement of success. A project is always constrained by time and resources. It is a time-space boxed attempt to solve a problem, based on our best effort and due diligence, at the moment. It is not uncommon we change idea or priority in the middle of a project. Because project is a mean to an end. As we progress and iterate in the journey of problem solving, we learn new information. A project is launched to solve the “current “ problem. Maybe the we realize there is a better problem to solve that gives higher customer value. So we change, we adapt! Problem space ownership, which sometimes can manifest into “component” or architecture ownership, is long lasting. When you own a problem space, you might need multiple projects to solve the problem. You are not only responsible for solving the current problem, but also the long term architecture to address the root cause of the problem space. For example, my team’s mission in KMS is to “Remove limits for customers”. Cryptography primitives in cloud computing scale are hard to implement correctly. We’d like our customers to consume KMS API as much as they need, as fast as they want, no limits! That requires us to push boundaries on capacity engineering, performance engineering, supply chain optimization and technology innovations. The target is alway moving, because customers want more API choices that are secure, faster, cheaper and always available. A real journey that is worthwhile in life is never a straight line, but a zigzag list of trial and error. So when we look backwards, the line from a good leader tends to be straighter - we call it “Are Right, A Lot!” Because good leaders iterate and adapt faster. So I told the team member: “Be the owner of the problem space, not just a project. Be adaptive, bias for action, try things out and don’t be afraid to change - but don’t lose focus on the problem itself. Enjoy the ride!”