What’s common in the phrases of the previous section is that they either assume things are out of “my” hands or they don’t take personal responsibility. In each of these cases, people behave as if they were victims of a situation instead of in control of it.
The real truth is that you, personally, ALWAYS have something that’s under your control, so there is always something you can fully commit to doing.
The secret ingredient to recognizing real commitment is to look for sentences that sound like this: I will . . . by . . . (example: I will finish this by Tuesday.)
Creating a language of commitment may sound a bit scary, but it can help solve many of the communication problems programmers face today—estimations, deadlines, and face-to-face communication mishaps. You’ll be taken as a serious
developer who lives up to their word, and that’s one of the best things you can hope for in our industry.
There is (technically) no way out of this verbal commitment. You said you’ll do it and now only a binary result is possible—you either get it done, or you don’t.
If you don’t get it done, people can hold you up to your promises. You will feel bad about not doing it. You will feel awkward telling someone about not having done it (if that someone heard you promise you will).
Scary, isn’t it?
**
You’re taking full responsibility for something, in front of an audience of at least one person. It’s not just you standing in front of the mirror, or the computer screen. It’s you, facing another human being, and saying you’ll do it. That’s the start of commitment. Putting yourself in the situation that forces you to do something.**
Here are a number of reasons you might not mean it, or follow through, with some solutions.
It wouldn’t work because I rely on person X to get this done.
You can only commit to things that you have full control of. For example, if your goal is to finish a module that also depends on another team, you can’t commit to finish the module with full integration with the other team. But you can commit to specific actions that will bring you to your target. You
could:
• Sit down for an hour with Gary from the infrastructure team to understand your dependencies.
• Create an interface that abstracts your module’s dependency from the other team’s infrastructure.
• Meet at least three times this week with the build guy to make sure your changes work well in the company’s build system.
• Create your own personal build that runs your integration tests for the module.
See the difference ?
If the end goal depends on someone else, you should commit to specific actions that bring you closer to the end goal.
It wouldn’t work because I don’t really know if it can be done.
If it can’t be done, you can still commit to actions that will bring you closer to the target. Finding out if it can be done can be one of the actions to commit to!
Instead of committing to fix all 25 remaining bugs before the release (which may not be possible), you can commit to these specific actions that bring you closer to that goal:
• Go through all 25 bugs and try to recreate them.
• Sit down with the QA who found each bug to see a repro of that bug.
• Spend all the time you have this week trying to fix each
bug.
It wouldn’t work because sometimes I just won’t make it.
That happens. Something unexpected might happen, and that’s life. But you still want to live up to expectations. In that case, it’s time to change the expectations, as soon as possible.
If you can’t make your commitment, the most important thing is to raise a red flag as soon as possible to whoever you committed to. The earlier you raise the flag to all stakeholders, the more likely there will be time for the team to stop, reassess the current actions being taken, and decide if something can be done or changed (in terms of priorities, for example). By doing this, your commitment can still be fulfilled, or you can change to a different commitment.
Summary
Creating a language of commitment may sound a bit scary, but it can help solve many of the communication problems programmers face today—estimations, deadlines, and face-to face communication mishaps. You’ll be taken as a serious developer who lives up to their word, and that’s one of the best things you can hope for in our industry.
Top comments (0)