If there was ever one truth about myself which pretty much drove all my career decisions, it was the need to know everything about what I was involved in. “Do this because I say so” has never been my style in either side (as a worker, or as a manager). I didn’t accept it, and I don’t deliver it. I find buy-in to be the biggest motivation. I want to do work because I believe in it, not because I was told to do it, and I want those who report to me to feel the same way.
If you invest in your work you become a much bigger part of the solution.
That bit of true-ism made all the difference to me when it came to delivering solutions. Obviously I understood the need to “do my job” but I never considered myself a cog in a machine just playing my part. I wanted to know how I fit into the big picture. I wanted to understand how others could be helped by what I was doing. If I could “see” what we were trying to build/ deliver, it would help make decisions a lot easier.
It took over twenty years before I understood that this trait – which seemed to be one of the things that differentiated me from many others – was called Connectedness. I need to feel connected to what I’m doing. I need to understand the whole flow of what we’re building and this helps me easily see how each piece feeds the whole. That knowledge allows me to share a complete vision with everyone involved and brings about the best team discussions since we’re all “rowing together” towards the same destination.
If I apply this trait to my “natural” state of Agile, it would be akin to having a fully defined User Story.
For those who don’t know what a User Story is, there are plenty of definitions on the web. Just Google “Define User Stories” and you’ll see what I mean. The way I summarize it is that a User Story defines what a “user” wants or needs, and why. The general statement I use follows this format:
As a PERSONA <client, user, etc.>, I want to <vision, idea> so that <business value>
In my experience, many teams tend to leave out the ‘business value’ of the statement because they want to focus on what they need to build. However, if you look at it logically, that ‘business value’ is the driving force and gives everyone a clear understanding of WHY something needs to be delivered. This value can then be compared against other deliverables in order to better prioritize what needs to be done first.
Going back to what I was saying at the beginning of this post, letting me in on why something is required allows me to understand and appreciate the importance and value of the solution. With this information, it is a lot easier to get buy-in from the team tasked to delivering it. Finally, sharing that information with the team allows them to feel connected to the whole process and makes them feel valued and valuable to the process.
The result? Constant communication around delivering the right solution the best way possible. And if you have a strong trust level in the team, that communication and sharing / challenging of ideas will bring about true collaboration.
Remember, “because I say so” will never get you the kind of results a true collaborative effort will. Explain what needs to be done, share the information you have, don’t be afraid to be challenged, and learn to listen to the opinions of others (especially if they are experienced in the matters at hand!). Make your team feel like they are part of the whole solution, and not just another widget-maker. You’ll be amazed at the magic that will come out of your sessions.
