STEP: Finish it
Congratulations, after giving up 2 weeks worth of nightly poker games, you've almost shoved through an improvement that makes your department (and therefore your life) better. So close, but so far. You'll still need to make the final push:
- Walk the users through until completion - Say you wrote an "alpha-widget-escalator" plug-in into Visual Studio that makes development of alpha-widgets 5x faster. Don't just send the team an email saying "please download this tool from the shared drive and install it". No. Pick 3 developers. Go to their desks, and walk them through until it works on their machines and they can use the "alpha-widget-escalator" without you. Or, say you're trying to add code-generation to the build. Don't just give the build team some templates - be prepared to sit with Jill from Change Control Management, open up the build script, and integrate those templates into the build, and then run the build to ensure the templates actually work.
- Show positive metrics to management about the initiative's success - Objective metrics simplify a manager's life because it lets them tell their boss what a great ROI those initiatives have brought. Suppose you created an auto-merger service to merge change sets between branches. Make it track how many files it's merged so you can tell management that it "automatically merged 800 files a month, at an average of 1 min per file, that's saving us raw time of at least 13 hrs a month, and because devs don't manually do this anymore, we're not missing any files, which saves us 10 errors a month, at an average of 1 hr each..." Of course, sparing devs from tedious tasks also increases moral and reduces distractions which lets them remain "in the zone". Consider sending a survey to the team a month after the initiative is standard, asking them "are you glad we did this". Survey results about developer moral are fair game to provide to management - "80% of our team loves the new auto merger, 15% like it, and 5% don’t care" - Success metrics also show management that the project indeed did work, which builds your credibility to do bigger projects in the future.
- Have an exit strategy - If you do one small initiative a month, it cumulates and you don't scale. Either make that tool/code/process absolutely maintenance free, or coordinate with management to hand it off to someone else.
Appendix
These are miscellaneous topics related to changing an IT department. If I were a star writer, I'd probably have found a way to integrate them seamlessly into the main article. However, it's easiest to just list them here.
What if you're not empowered to make the change?
Sujit spent 5 years developing .Net applications, and his boss has him pigeon-holed as an application-developer. Sujit can't set up build servers, purchase tools, bring in consultants, change the architecture, or do anything that would really turn his department's mess around.
There's still hope. Sujit can always at least defend his own turf and make "Individual Changes" (described above in "Three categories of changes"). For example, he could write his own private tool or script or code block to make it easier for him personally to comply with the broken infrastructure.
He can also support those who are empowered to make the change. Say the star architect, Mary, would love to push good initiatives, but just lacks the bandwidth. Sujit can assist Mary - he can build prototypes for her, do research, or even just provide moral support that all Mary's efforts aren't for naught.
I'm working 70 hrs a week on a death march, and I just don't have time to change
Sometimes you are in a "just survive" phase. People who have never gone through this misery tend to come off as naive and clueless, and don't get why others haven't already made the department perfect. Do what you can, with what you have, where you are.
Perhaps also use this as the reason you need change. Why don't you have time? Is it because the company is fundamentally screwing something - such as they don't do requirements or functional specs so the devs scramble 2 weeks before go-live to massively "correct" the application? You can tell your manager that you realize you need to solve the current crisis first, but this bad process has to be fixed, or you'll constantly be playing catch-up.
How do you know if your initiative is screwed?
First make sure that this is truly "screwed" and not just "inconvenienced" - initial rejection, compromise, busyness, and delays are not "screwed".
Given that, we've all learned the hard way that life isn't fair. Sometimes your department got painted into a corner - say the business (or industry) is fundamentally not profitable. Sometimes the team is just mentally entrenched and refuses to improve things. Other times the key players have "hidden agendas" and it's too much of a political game. However, I think in general the #1 cause of screwing the ability to make positive change is having bad management.
Good managers can internally start repairing the rotting infrastructure, bad managers leave you drifting in the wind. Think of:
- The manager who is so focused on impressing the VP with business features such that they fundamentally don't value the development infrastructure. If you want to keep giving the VP the golden eggs, you need to take care of the golden goose who lays them.
- The manager who won't acknowledge critical process failures even when they do occur. If you spend days to manually juggle 1000 files to deploy, and the deployment keeps failing, and management thinks that "that's just the way software companies are" and hence won't allow you to fix it, then you are screwed.
- The manager thinks that everything is an emergency, and thus constantly yanks you away from any long-term improvement to always put out short-term fires. They'll tell you to pump water till your lungs explode, but they won't let you plug the hole in the boat.
- The manager who just doesn't get it - they know neither the technology nor the business nor the management skills.
- The micromanager who controls every member such that they aren't free to innovate. If your manager controls which tools you can use to do the job on your private workstation ("do it how I did it 10 year ago"), or has developers controlled down to 30-minute tasks, you're probably screwed.
Ultimately, if you are indeed truly screwed and cannot possibly change the department, that’s a topic for another article.
No comments:
Post a Comment