I’ve read and seen a few different takes on this concept, but here’s mine:
There’s “can”, “may”, and “should” for every idea - but we need more than one. It’d be nice if we had all three.
“We Can”
We have ability - there is conceptual understanding, a pragmatic plan, and the required tools, people, money, and time. Or maybe we finally got it to work.
“We May”
We have permission - regulatory and compliance concerns are known and managable, legal and licensing terms are met, the security story is solid, and there’s leadership support to expend effort on something.
“We Should”
We have a reason - we need to do something (or actively stop doing something) because it’s right for the business and stakeholders. This reason can be short-term (see “pain point”), regulatory, or more strategic.
Patterns
There are some common patterns I’ve noticed:
Technical teams get caught up with whether or not “We Can.” Maybe there’s a culture that says if we can’t do everything, we can’t do anything. I’ve heard technical teams say things like “we’ll wait for them to buy something, then figure it out.” These folks can’t help but draw on their experiences, especially situations where a once shiny new project has become a burden after a number of years.
Management teams can move too quickly through “We Should” and don’t always give enough energy to “We Can.” A good idea doesn’t mean that management immediately has the ability to devote resources to that idea, and “We Can” should be about resource allocation and prioritization as much as it is a technical capability. Leaders should also look out for confusing “We May” with “We Should.” Example: a vendor pointing out that you’re already paying for a specific license or feature, and now you feel like you have to use it. In fact, you “may” use it, but that doesn’t mean you “should.”
Meanwhile, our customers correctly focus on “We Should.” They’re often relying on IT people to handle the other two. Vendors are aware of this, which is why they work hard to reduce the burden of “We Can” and “We May” through software as a service, user-based subscriptions, etc. Anything that remove barriers. While this can be helpful to the technology team, we still need to clarify the technical and operational needs, put in the work to develop a sustainable, meaningful, and realistic path to “We Can” and “We May”, then make it happen.
Great things happen when organizations describe why they can, may, and should do something interesting with technology.