When to Break the Rules

I find myself in an interesting position where I’m doing good work, but my client isn’t entirely on board with the results yet. Now, this is a problem I’ve created as a consultant by not keeping people aligned, but it happens.

I’m confronted with two broad choices: stay the course, or break my rule.

For me, I’d be breaking a rule I have about writing software. I try not to do that anymore. When my eyes focus on code, it is harder to see what is going on around me, and the problems around the code are the important ones. Things like trust, safety, risk management, working across groups, and so on make products, projects, or initiatives succeed or fail, and none of that is code. Anyway, this got me thinking, when do I seriously consider breaking the rules I have?

Who Suffers?

One of the first things I look at when considering breaking a rule is who will suffer the consequences of my choice. All code is maintained, and if I write something, someone will have to keep up with it.

To feel like I can break this rule, I have to know who I will impact. In this case, I’d impact another software team with maintenance. That is, unless I can steer away from that at the same time. For this particular case, I will attempt to build only a demo or proof-of-concept that needs to be rebuilt if seen as useful.

On the other side, who suffers if I don’t break my rule? In this case, the same team suffers, but they’ll have to attempt building two projects in parallel with the same initial timeline. In other words, they’ll fail.

What is Gained?

If I’m going to break a rule, there had better be some excellent reason for it. I think through future scenarios, and I consider what new options are available for me.

In this case, I believe that breaking a rule buys me some more favor as a consultant while giving the client a quick-win that they urgently want. I can’t bet on how far these two things carry me, but that is better than holding to my rule and letting a team fail and my client as well.

Recovery

Sometimes you break a rule one time, and you find yourself breaking it more and more. There is a potential for a slippery slope, and I don’t want that. As it happens, I am worried about that with my writing code rule.

Once people find out I can write code quickly and well, the question typically becomes, “Why don’t you jump in and help?” Sort of like going to a house party as a chef and refusing to go into the kitchen. Before I break my rule, I have to have an approach to re-establishing it.

In my past, for this element, I’ve set some specific terms and expectations for what would happen when I break my rule, but I’ve found that people are very agreeable when they are about to get what they want, and much less so when they want more. In other words, it takes constant re-enforcement of those terms from then on.

Break or Not

In this particular case, I’m breaking my rule. I believe I can protect the team from suffering my choice while giving my client a win. Also, I think I can leverage that in the future as well. In terms of recovery, I will have to keep people from coming to me with similar requests in the future.