Driving Technical Change
人民幣：RMB 29 元
Before we make any moves to convince others of our solution, we have to ask ourselves a very important question: are we solving a problem or pushing a solution?
In our excitement over the solution we found, we lose sight of the fact that we are trying to address a problem. We forget that most problems have more than one solution.
Once you’re sure there is a problem, you then have to consider whether it is worth fixing and what would make it worth fixing to your team.
Look at how other organizations are solving the same problem that you are seeking to solve. When you search, make sure you search for the problem and not a specific implementation.
The main challenge here is that you could fail to really consider alternatives objectively.
Another difficulty is that this burns up time.
You need to use countering techniques, especially Demonstrate the Technique, to show these individuals not just the what of the technique but the why.
The Herd aren’t going to seek you out to be led. You have to go to them and lead. Techniques that encourage them to advance are mildly effective, but ones that force them are even better.
Countering the Cynic is about two things:
• Refusing them entry points to arguments
• Preparing enough so that you cannot be refuted
Assuming that you can prepare and refute as outlined here, you can usually do well by this group.
This can be a tough group to completely convert. People tend not to like spending time learning new things. To try something new and then have it fail can simply be too much of a hassle to give it another try. It is often easier to go around these previous experiences by selecting an alternative technology.
“There’s never time to do it right, but there’s time to do it twice.”
No one likes being crunched for time. It’s an awful feeling that usually makes you feel constantly a little nauseous. They want out; they just might not know how to get there.
The single biggest reason that management resists professional development techniques is because management doesn’t understand them. That might sound harsh, but it isn’t.
In short, meeting people where they are and talking to them in their language isn’t insincere; it’s practical.
“Making code more maintainable” can be sold to management as “reducing ongoing project costs.” “Automate rote code” can become “Complete projects faster.”
Success with the Boss is going to rely on how well you make your tools the solutions to their problems.
If it isn’t entirely clear from everything else I’ve said, you cannot sell to the Irrational. This is not to say that you cannot get them to participate, just that you won’t do it by convincing them. You can bribe, punish, or compel them. In fact, the overall strategy I recommend is to ignore them and get management to mandate your technique.
Bottom line, you just can’t convince them. So, don’t spend a lot of time on them. It just leads to wasted effort.
If that benefit wasn’t enough, it’s worth it to point out again that teaching is one of the best ways to learn.
Now, when we do this, we don’t mean to drive people away. We’ r e just letting our enthusiasm get away from us. But it doesn’t matter. This type of speech will put your audience on the defensive. The better way to encourage people is by suggestion, not declaration:
“Show, don’t tell.”
In the previous story, Ed waited for an opportunity to arise. He was prepared, and when it presented itself, he seized the opportunity. Some tools and techniques are more likely to be sold in an organic opportunity.
The best thing you can do when a demonstration fails and your contingencies don’t work is stop.
As organizations age, they grow rules. Rules often come up in response to incidents—the policies prevent those incidents from occurring again. The downside of those policies is that they can end up constraining more than they protect.
Let’s face it, when developers impose rules, they’re called “best practices,” and when the Boss (Chapter 10, The Boss, on page 44) does it, they are called “policies.” That difference in language is very telling. Bosses are the drivers of rules. They oversee a lot of people, and onesize-fits-all rules are easier to keep track of.
Trading them something for rescinding a rule is the only way to get some of them to give them up, because in these cases, rules are a solution to their problems. Only by offering more solutions to their problems can you get them to part with their rules.
The other challenge is creating a group of like-minded people with enough power to overturn the rules. Typically the further away the policy enforcers are from your team, the harder the change is to make.
Believe it or not, being wrong might be the best thing to happen to you. It gives you the opportunity to inform people that you are wrong. Yep, you read that right. See, most people aren’t used to people owning up to their errors. Even if they are, most people have to be confronted to own their mistakes. But the fact that you willingly admit mistakes allows people to trust you. Because you tell it like it is, even when it is bad for you.
We all know that if a tree falls in the woods and nobody is there, it doesn’t matter if it makes a sound, because nobody hears it.
There’s a meme that come from the Bible, “You can never be a prophet in your hometown.”
Despite what we in technology may like to believe, technology doesn’t drive business; business drives business. Business needs will always trump technology concerns.
This can be a powerful technique, but only if the opportunity presents itself. The key here to keep in mind that your company exists for a reason. That reason is usually not technology. If you can align your
tools around that reason, then not only are you going to get help from management to implement them, but you’ll be serving the best interests of the company in a direct way.
In other words, we provided maximum benefit and added minimal cost.
In the story example in this chapter, I didn’t find any solution that could be a bridge between my desired solution and the status quo, so I built it myself. The idea here is that you can perfectly mold it to your environment. If you have conventions or best practices, you can make sure that your solution follows them. If all of your applications have boilerplate code, then include that. Basically provide as much advantage as you can squeeze into your solution, since you are designing and developing it yourself.
The only downside is that it can be a great deal of work.
Practicing bridge building is a bit daunting, but you can do some research to find something that exists already to act as a bridge, or you can build small bridges on your own.
The key here is to try to think of the Irrational as an obstacle and not an enemy. Enemies are defeated; obstacles are overcome. Overcoming an obstacle can be as easy as walking around it.
Once your converts are out working for you, you need to work for them. You have to promote their efforts.
More importantly, own your failures. Admit them. Advertise them when they happen. Most importantly, explain them.