To commit. To be committed. To make a commitment. Each statement can be met with a generic response: “To?” To what have I committed? To whom have I committed to do something by a certain date? “Commit” is an interesting word, a verb with two basic and quite different meanings:
- Carry out - perpetrate
- To pledge or bind
The first definition is about the act itself, whatever it may be. What was carried out, perpetrated? Unless we're talking about source code control, the word “commit” sounds downright nefarious!
The second definition is about those things that occur before what we commit to accomplish, and an earnest effort has begun. In another context, we may think of one being core development and the other being all those things that must occur before core development may begin; such things include pre-sales proofs of concept and terms of service negotiation. That's the commitment, the promise. When the deal is “signed, sealed, and delivered,” the popped champagne corks must turn to the team's code craft, for there is a software product to be delivered. That's the commitment, which as it turns out, is made up of several other commitments. In the legal world, it's a contract, a promise in exchange for a promise or some action. In the present context, the many commitments we all make to each other to deliver software is usually evidenced by a legal contact. The point here, before getting into the details, is that our commitments are the key, up and down an organization, to making things work. And they all build on one another, sometimes like a house of cards. Although it may be a bit of a mundane topic, it's often good to revisit such things because when we go back to reflect when on what went wrong, it's typically the little, mundane things that went awry.
What was promised? Does it depend on who you ask? If it's the lead sales team, the answer will be clear, whatever that answer may be. And if there is ambiguity, the statement of work (SOW) should provide clarity. If there's no clarity, there's a bigger problem, so whatever answer you get doesn't really matter! What if we asked the dev team what was promised? A response would be received to be sure. If not, then just like before, the answer you get doesn't matter. Assuming we get two actionable and clear responses, to what degree, in terms of organizational and project impact, would the two responses align? If they don't, that's yet another different problem. But if they're aligned, are they aligned legally with what was actually promised? This is why clear and consistent communications is so necessary in order for an organization to and its constituent people to meet their commitments. There are three basic groups/parties we need to be concerned with:
- Those who make the promises (e.g., sales)
- Those who fulfill the promises (e.g., development)
- Those who are the beneficiaries of such promises (e.g., the customer)
How we carry out our commitments is just as important, and perhaps more important than just meeting the commitment. It's my opinion that in any rational business (and I choose to punt on the irrational kind), there's sufficient amount of earnest desire to do the right thing, in the right way, for the right reasons. Sticking with the rule of three, another leg of the stool may be that despite the strong desire, the effort required to meet the commitment's letter isn't feasible. Why is that? Generically speaking, it's either ignorance, malice, or some combination of the two. At the core is information, who has it and who doesn't. In any successful organization, information moves as effectively as it needs to. It need not be perfect, just good enough.
Just good enough - for how long? In perpetuity? That can't work. When we make decisions to pin an effort or to just outright whack a feature, we're making an organizational commitment that we've assessed the risk. But the only way that can work is if people hold each other accountable. Clear and effective communications are one important ingredient. Assuming we have that, what happens when commitments aren't being met. Why is that? That's where accountability comes into play. It's the device by which we see to it that we honor our commitments. And in the most successful organizations, people hold themselves accountable.
No tool or automated promise is going to force anybody to do anything. Only people, cloaked in appropriate authority, can do that. Assuming the happy path here, where there's enough shared vision of mutual respect, transparency, etc., the thing referred to by many is the Accountability Chain. The chain is bi-directional in that it goes up and down the organization. In other words, if everyone is in the same boat, everyone has made and has signed up to the promise, to the commitment, from the CEO to the intern. Commitments and the law are very similar. Often, there must be enforcement for them to be worth anything.
Instead of asking what is good enough, the more important question may be whether the team is enabled to meet “good enough.” And for the record, I'm not suggesting that “good enough” is akin to chucking it over the wall! I suggest that we must define what must be good enough first and then second, see to it that we can actually meet the promises we're making.
As a practical matter, a good place to look for guidance on whether a deliverable is of sufficient quality (good enough) may be found in your Definition of Done. If you have one, chock that up as another commitment that needs to be honored! As I stated earlier, promises and commitments build upon each other. If you haven't codified a definition of done or such other similar thing, if you take nothing else from this editorial, take that! And by that, I don't mean any aspirational talk or philosophies on how things should work in a utopian environment (business school). Take with you the commitment your team is going to codify and establish a definition of done!
For a moment, I'd like to revisit the mundane, the simple, the small things, not so much because they matter. It's because the small things tend to be authentic and, therefore, can't be faked. By small things, I mean those things that folks just know about an organization; how it works, what makes it tick, what motivates it, its people, etc. Some may call it tribal knowledge. This sort of information is vital because these things all go to how information moves through the organization, a thing our ability to honor commitments depends upon.
What I'm referring to are the “small things.” Small things are units of work. For example, how does the shop implement Git, and perhaps more granularly, pull requests? You may be wondering how something as macro as organizational commitments directly relates to something as micro as source code control. What if the organization is a public entity? Add many, many more commitments around SOX, for instance. How do you verify SOX compliance? Via SOC/SOC-2. That's an example of strategy and tactics. You may think that it's like peeling the layers of an onion. It isn't, though, because in these cases, we start from the core and work our way out. That's where the bodies are buried. That's where the truth is. That's where all the small things are! It's there, in that sea of things at the core of the organization, where we find out if we're able to meet our commitments.
Honoring commitments, however, doesn't necessarily mean that there must be perfection 100% of the time. No project is 100% perfect. And yet, there are many, many successful projects. There's always failure, to at least some degree. The question is what does our commitment say about these situations where deliverables haven't been met, either in whole or part? What does the contract say about breach? In my opinion, it's always best to confront and adopt these procedures from the start. Otherwise, there's too much wheel-spinning and finger-pointing instead of doing the things necessary to remedy the failure! Job #1 is honoring commitments, not being perfect. Nobody and no thing is perfect.
It's necessary to make commitments. It's necessary to honor those commitments. It's necessary to enable the honoring of those commitments. Promises and commitments, like everything else, build on one another, like a sturdy structure. The key is to focus on how your organization goes about it, which includes what it prioritizes as necessary. And if you find there are issues, work from the inside out, starting with the small things. Often, the small things are easy to fix!
