Change: Incrementally Making Things Better (Part 3)

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/change_incrementally_making_things_better_part_3.htm]

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

Practical tips to bring about positive change

Given all the introductory background, let’s discuss practical tips to actually make it happen.

1. Avoid FUD (Fear & Uncertainty & Doubt)
2. Make it a team effort
3. Determine which initiatives to push
4. Implement it in small, practical steps
5. Finish it

STEP: Avoid FUD (Fear & Uncertainty & Doubt)Except to deal with FUD each step of the way. Consider these guidelines:

• Adapt successful traits that already benefitted other companies - It's not that you're asking your coworkers to take a risk on some mad-scientist idea that you had while stuck in traffic. Rather, the vast majority of star developers are asking their peers to adapt best practices and principles that have already been proven in the industry.
• Introduce ideas with a rollback - People are often cautious to adopt a new idea because "what if it fails?" By providing a rollback, you make it more reasonable for the team to try out the initiative.
• Be specific. Don't just say "we should adapt ORM" because some people will think of that time when they tried some obscure, pre-baked ORM tool and it failed miserably. Show an actual ORM tool (like NHibernate) and a simple working prototype.
• Talk is cheap - Show an actual prototype. Leslie says "we should do code generation, it's so productive." Susan shows a prototype where CodeSmith automatically generates an entire web-application to wrap a database. I'll bet a steak dinner that the team will have less FUD about Susan's idea than Leslie's.
• Be approachable. If people can't ask you questions (perhaps they think it will make them look "stupid"), then you're screwed. They may be resisting a good idea out of ignorance, but in the end, they're still resisting - and if enough people do it, it will wear you down.
• Publish an FAQ - Put on FAQ on the wiki that dispels the common myths. If you're giving a demo, you gain 10 points when someone asks a question and you can give a quick answer and then follow-up with "that's a great question, and it has a detailed answer on the wiki..." It helps people feel more at peace to know their concern has already been anticipated and resolved.

 STEP: Make it a team effortIn one sense, changing a department means changing people, and that means doing politics, and politics are never won by an individual. Even if by your sheer awesomeness you can single-handedly refocus the entire department, eventually the pain of the loneliness will trump the reward of the new improvement. Even if people are late to the party, you still want it to be a party, which means other people come along.Many people complain how bad it is, but never offer to get involved making things better. Consider asking these questions:

• To a dev manager - "Can we officially have 2 hours a week for each person to do an infrastructure improvement?" Obviously don't ask this during the big go-live. But ultimately, if a team can't spend even 5% of its time doing pro-active, preventative improvements, then that team is in a death spiral. 2 hours is almost a discretionary amount. A developer could easily suffer a one-hour bug hunt twice a week, so if the research and innovation even saved them from two bugs, it's already paid for itself. This question also encourages team ownership.
• To a dev manager - "If we're spending 100% of our time churning out business features, then who will improve the development infrastructure?"
• To developers - "What would it take for you to develop twice as fast?" There are many means to increase developer productivity: advanced tools, faster hardware, spare machines to run background tests on, unit testing, code gen, aspect-oriented programming (AOP), object oriented programming (OOP), reusable blocks, open-source code, design patterns, etc... Asking developers what they need encourages them to reflect on practical improvements that they can take ownership of.
• To anyone - "What could you personally do to make it better?" Could QA automate some test, could a dev refactor or wrap troublesome code, could IT write a tool to assist with parts of deployment, could a DBA provide a diagnostic report about production activity? Even the most junior member can still contribute something.
• To anyone - "How will it get better? Who will make it better?" Do people expect a new CIO to ride in on a unicorn and fix everything in 6 months, or for management to bring in consultants to overhaul all the systems, or to have the schedule officially devote months to infrastructure improvement?

Questions like these get people away from griping about how much it's sucked for the last 3 years, and redirects that frustration into useful conversations.Other points to consider:

• Get others involved with low-hanging fruit - Yes, you can do it all yourself, but if you shell out that easy programming task to the new hire (get his manager's approval for 3 hrs of his time), or get Sonya to write an informal idea with the design (which she knows cold because she did a similar thing for 8 years at her previous company), or ask Bob how to do that super DBA trick, then you're getting people involved. Besides splitting up the work and opening up the initiative for better ideas, this also lends credibility to the project (it's not just Mario's crazy idea, but a project being assisted by 4 people), and gets emotional investments from others (Bob asks "how did that DBA trick work for you?")
• Work with the influencers - David is the SQL guru, he's done it for 20 years, did the lecture circuit back in the day, and built the core of your data access layer. Now that he has two kids he's more about work-life balance and doesn't lead the fight, but he still "gets it" and loves the stuff and would support a good idea when he saw it. Half the team will support any idea that David blesses. So don't dismiss David just because he leaves at 5:00pm to make it to his daughter's soccer game. Make sure the idea passes his standards, get his approval and insight, and the team will follow.

Benefit from the awesomeness yourself - If you cured cancer, people would be pounding at your door to buy it - you wouldn't need to market it. Likewise, if you made the super tool to spare you from some pain that the department dreads, your coworkers will wonder what your trick is. Then share it with them. Sure, you already sent out the team email two weeks ago about how to download it from the wiki, but still, relish the opportunity to help a coworker.

NEXT:  Part 4