Change: Incrementally Making Things Better (Part 6)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

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.

Change: Incrementally Making Things Better (Part 5)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

 

STEP: Implement it in small, practical stepsAt a certain point, you just need to jump into the arena and get your hands messy. After all the meetings, word docs, PowerPoint slides, business ROIs, and cheering sessions, eventually someone needs to actually start writing code or changing scripts or procuring a tool so that the change actually happens. PowerPoint decks are not change; working C# code running on other people's machines is.Be practical - you must meet people where they're at. You want to give a drowning man a life preserver, not swimming instructions.

• Be prepared to build the prototype yourself - You may not be able to wait for your manager to give you schedule time or for the PMO to hire contractors to build it - necessity may demand that you start something yourself (this probably means nights or weekends). If the team thinks it has potential, you have a good chance of handing it off to other developers and letting them run with it.
• Your deliverable must be something concrete - Tools, approval emails from management, scripts, or code blocks are all concrete. An email with a link to a "cool" article, or a suggestion of what we "should do if we only had time", is not concrete - it will no more feed your team's need for improvement than an article on restaurants will feed a hungry family.
• Make it work - If you're making a tool, make it easily available (say, publish a working version to a public share - don't require them to compile the source code themselves), make it run on their machine, and ideally give it default config values so that it does something useful right off the bat. From the time Kurt agrees to look at your tool and you arrive at his desk, you have minutes to download it onto his machine, click a single icon or dos command, and have him see the pain that the tool saves him from.
• Start small, and continually add value in incremental steps - Have some deliverable every week. If you're working 20 hours on a project, there's got to be something to show for it. Avoid the "just give me 3 months and I'll give you the perfect solution," because they'll never give you a blank check for 3 months. Even if they do (say you've built up a great reputation with previous successes, so management risks big schedule time on your ideas), some big emergency will interrupt you 2 weeks in. You'll be constantly distracted with the "urgent" so you'll never get to actually do the "important". You're 3-month salvation project will lay in mothballs, taking some of your credibility with it.
• Don't be paralyzed by perfection. I.e., "perfect is the enemy of done". An imperfect solution that actually does something is adding more value (and relieving more pain) than the perfect solution that never got built. Consider building a quick "band-aid" or "throw-away" solution now to stop the bleeding and then building that perfect solution in 6 months when the schedule magically opens up and you have all the time in the world (yes, this is sarcasm).
• Don't be paralyzed by "coolness". Lots of developers like "cool" new technologies. However, such technologies often have risk and learning curves - which may mean that you only have enough time to come up-to-speed with the tech, but not to actually build something useful with it. Many of the infrastructure problems that most shops face have already been solved with older technology - look at classic books written in the 1990's like Code Complete and The Pragmatic Programmers, and ask yourself - how many of those good practices is a suffering department still lacking? Nightly builds, automated deployment, unit tests, modular design, layers - they were all done with over 10-year old technologies. If some cool new technology saves your day - great - but don't limit yourself to it. Sometimes a good old fashioned xml file and console app plumbing is sufficient to save your infrastructure.

Keep in mind that you must do all of this while still getting your Boss's priorities done. You cannot just "go rogue" and abandon your official responsibilities to do a bunch of research and innovation.

NEXT:  Part 6

 

 

Change: Incrementally Making Things Better (Part 4)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

STEP: Determine which initiatives to push

I am continually surprised by how many smart, energetic, and good-intentioned veterans fail to change their organization because they're pushing the wrong initiatives.You cannot boil the ocean. There are simply too many good initiatives, and you cannot do them all. And even if you somehow could change the entire department (say you win the lottery, and kindly use it to hire a team of star consultants to fix everything), your team couldn't absorb it all. Therefore you must pick your initiatives wisely. Keep in mind that success will increase your credibility with the team, which encourage more success, whereas failure will decrease your credibility. Therefore a small success that actually just works is better than a huge initiative that "almost" works. Unemployed departments are full of cool projects that "almost" work. Here are guidelines to help pick good initiatives for change.

• Knock off the low-hanging fruit. Start adding value (and therefore building credibility) with small wins - perhaps a quick tool or code refactoring or convention you can get done in less than a day.
• Emphasize the high ROI ideas first. For example, updating legacy code that already works has a low ROI because you've gone from "app that works" to "app that worked - gee, I hope I didn't break anything - but now it's easier to maintain." Look for industry-proven changes that give a big return, such as the introduction of code generation, reusable blocks, unit testing, developer tools, change control, etc... New ideas that just "tax" the already-busy developers will go flat.
• Focus on new code. No-one wants to go back and re-write legacy code. Much easier to get people to adapt for new code. If every change has to be applied to 2 million lines of legacy code, it will be like dragging a lead ball around; nothing will get done.
• Pick changes that cooperate with other initiatives. If you're company is desperately trying to improve performance because angry customers complain about slow page loads, now's the time to introduce a caching framework. It will be like running with the wind at your back instead of against your face.
• Break big initiatives into smaller steps. You may not be able to introduce that new attribute-based validation system right away. However, perhaps you can first start building a static utilities library of common validation functions so all the logic gradually gets aggregated in one place. Then you could modify the data layer to pass in entities. Then you could add the validation attributes to the properties on those entities and have a reflection-based component apply the logic. You may not be able to do the big goal all at once, but you could do the small steps piece-by-piece.
• Show how the idea supports the business goals. The easy way to do this is to ask what business goals the managers care about, and pick technologies to support those, as opposed to picking techs that you think are "cool".
• Have either unanimous team support or objective success metrics. We all love hard data, but sometimes a developer just has a "gut feeling" that they know something is right, and they don't have the data to immediately measure it. General rule: if everyone already wants the same goal, then you don't need to convince them with objective metrics ("we really need a tool to automatically merge changes from one branch to another"). However, if people aren't convinced, then you will need some way to objectively measure the benefit.
• What do you care about? Even if something has low ROI, if you'd enjoy it such that you'd spend your own weekend building it - and would have fun doing so - then go for it. You hit two birds with one stone - you get to play with a niche technology or cool tool, and your day job benefits from it.
• What do others care about? - What changes does the rest of the team want? If Lenny wants to automate deployment, and Susan wants better refactoring, and Sunil wants reusable UI controls, then consider adding your weight to those.
• What are the prerequisites? Does your pet project require something else, say purchasing a new tool, refactoring tons of code, or a new team convention where people suddenly change their habits? If so, focus on those prerequisites first.
• What other opportunities does this open up? Related to the previous point, some initiatives open up the door for other big opportunities. Say you purchase a tool (like CodeSmith) to introduce code generation so you can automatically generate data access CRUD plumbing. You can then use that tool to also code generate many other things (base data, install MSI packages, proxy classes, etc...)
• Meet people where they're at - If the team culture is completely opposed to pair-programming, you probably don't want that to be your keynote initiative. If the team is being burnt alive putting out fires, they won't care about anything other than a water hose.
• Can this initiative succeed? Seriously. Remember that a small success is better than a big "almost". Focus on attainable goals.

Given these criteria, prioritize your ideal changes. If there's a hundred things you want to change - great - make an excel list. But then pick your top 3. Then pick your top 1.Some people need to see a list. If that's the team culture, then consider making an excel sheet. Depending on your team, you can make it informal (like the sample below), or very formal - complete with numeric weightings. There's no one-size fits all. If it's too informal, your team may say you "haven't thought it through". On the other hand, if it's too formal, then they may get stuck on inconsequential details like whether making a CI build takes 4 hrs or 8 hrs. In general, you'll want at these pieces of info about each initiative:

• Buzzword - Some label, less than 3 words, that distinguishes the concept so everyone can easily refer to it.
• Description - Any special notes or hints about how to do it.
• Effort - Is this big, medium, or small? A formal scorecard could have an hour estimate here.
• Benefit - Is this project even useful? A formal scorecard could have dollars or time saved here.
• Prerequisites - Must be in place for this to work?
• Who cares - Successful initiatives need people to support them. Will this benefit Cary in IT, the entire QA team, or make your manager's life easier?
• Obstacle - Why isn't this already done? Is it just lack of time?

Here's an informal sample. Of course you can add more columns and vary it up depending on your team culture. Note that some items will be small (get account access), but others could be team-wide initiatives (enforce unit test code coverage).

 

Buzzword	Description	Effort	Benefit	Prerequisites	Who cares?	Obstacles?
Access to QA database	Get devs read-only access to QA database	Minor - ask security team	Medium - lets devs assist with QA bugs	Manager approval	Devs, QA	Martin fears this will hurt QA performance
Purchase ETL tool	Instead of building ETL ourselves	Minor, but costs $$$	Medium	Manager approval	Devs, QA (easier to test)	Procure funds
Developer CI build	Use TFS to have hourly build for dev source code	Medium (less than a day with Monty's help)	Huge - instantly detect compile errors, hook other steps into build like unit test and MSI packaging	Build Server, management to insist the build passes	All devs, managers,  Bart [a senior dev] especially wants this too.	No spare machine for the build server
Split VS solution	Current solution is too big, hard to work with	Small	Faster compile times	Senior Dev support	Half the devs	Time
Make validation library	Put validation logic in reusable utilities	Small to start, could be big	Standard validation, supports future framework	Need a common assembly	Half the devs, Lisa [a product manager]	Just need time to do it
Add unit tests - Phase 1	Just let devs optionally write tests	Medium - tools are free	Huge	Get test harness (like NUnit)	Devs	Culture doesn't support it, so tests not maintained
Add unit tests - Phase 2	Make  required, part of the build	Big	Enforces unit tests	CI Build, code coverage tool, manager support	Everyone	Lots of people don't like UT, "it takes too much time"

 Lastly, as we discuss which initiatives to push, don't use any of these techniques - they will fail miserably:

• Try to change everything at once.
• Push for a change that no-one sees the benefit of (You'll just be branded as that "annoying guy who doesn't get it").
• Don't have your own list, even a mental one. (Merely saying things are "bad" won't fix anything. You'll need concrete examples of what to change.)
• Wait for your manager to give you a list and make it perfect. (Your manager is busy, and they're probably focusing on higher-level problems. They need you to pro-actively tell them the problems you're facing - and your proposed solution.)

NEXT:  Part 5

 

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

Change: Incrementally Making Things Better (Part 2)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

 

What encourages people to change?

 Ultimately all change starts with people. Even if you buy a new tool or framework, you need to convince people to use that new thing (or at least cooperate with it). And remember, "A man convinced against his will is of the same opinion still." You cannot effectively force knowledge workers to change, you must make it a "pit of success" - where it's easy to do what's right and hard to do what's wrong.

If it all comes down to people, then what causes people to change? Two things: the avoidance of their pain, and the pursuit of their pleasure. For example perhaps a developer is receptive to code generating the data access layer because they're sick of writing thousands of lines of brittle ADO.Net plumbing. Or, perhaps they want to start unit testing and refactoring because they get an intrinsic joy in seeing beautiful, automatically tested, code.

 The flipside is "what causes people not to change?" Assuming the change itself is a good and profitable idea, there could be as many answers as there are people:

• They're content now, and the change doesn't benefit them ("if it ain't broke, don't fix it").
• The change isn't worth the cost (let's force everyone to rewrite legacy code to adhere to the new naming convention).
• Their nature is to resist new ideas - some people are just naturally stuck in their ways.
• They don't want to change too quickly - people need some stability to cling too.
• The person proposing the change has a bad track-record, so people don't want the risk.
• They're too busy to even think about it (this plays into the "downward" spiral").
• Ego - it wasn't their idea.
• They have some hidden agenda that they're not explicitly telling you. For example, the change may be good for the company as a whole, but it will personally cost them (such as longer hours, or putting them out of a job)
• FUD (Fear, Uncertainty, and Doubt) - hey, people are still people.

You likely can't change the fundamental nature of the team. A startup will be different than a huge bureaucracy, a private company different than a government agency, an industry IT department different than a consulting group. Think of it like sports teams: you can help an average football team be great, but you can't make it a baseball team. If you want to switch baseball, you'll need to join a baseball team.

 So, any attempt to instigate a cultural or infrastructure change is going to need to address it from both sides: encourage people to change and removing the obstacles that block change.It will also need both top-down and bottom up support. With only top support, it becomes an "ivory tower". With only bottom support, it becomes a "misguided effort" or "postponed project until the schedule opens up". To make things happen, you must work at both ends. Getting into the right mindset

This is one of the many lessons I've learned the hard way. If you want to help change the department, you must put yourself in the right mindset. You're absolutely not going to simply strut into a demo room, show a flashy prototype with a buzzword-filled PowerPoint slide, and then have everyone ooh and ah at your brilliance and "see the light". Even if you have the best idea in the world, you're going to need patience (it will take time), perseverance (9-to-5ers don't change departments), and empathy (you're dealing with people).

 In the hopes that you can learn from my painful mistakes, these types of things will not work:

• Complaining - It may feel good to tell your desk buddy how crappy the whole thing is, but negative venting will not bring positive results.
• Telling how wonderful your perfect past project was - People will think "If your last place was so good, then why don't you go back there?"
• Muttering "I told you so" after a failure - This is what you expect in junior high. People will just resent you or say you're a Monday-morning quarterback.
• Trying to boil the ocean - Sure, "if we just completely wrote all 5 million lines of code by October..." Stop it. This will never happen. Stop even thinking it.
• Pulling rank - You may be able to temporarily use your job title to force people to change, but if they don't buy into it, they'll just game the system. So you set up a required "root-cause-analysis" text box on the issue change form so you can better track what's going on - busy people will just type "aaa" into it.
• Sending one-line emails saying "this looks good" - change needs to be like a hungry dog that attacks the problem and won't let go until it's digested. Tossing some links around will just bounce off people's busy schedules. Anyone can send out email links.

As Paul Glen explains in Leading Geeks, while you can control behavior (think supervisor in a factory), knowledge work isn't based on behavior - it's based on someone's thoughts. And you can no more control someone's thoughts than you can tell the sun to stop shining. Therefore changing people is impossible. All you can do is create an environment that encourages people to change, and this will take every good character trait you can muster.

NEXT:  Part 3

Change: Incrementally Making Things Better (Part 1)

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

Part 1 (Intro)

Part 2

Part 3

Part 4

Part 5

Part 6

"You can be an entrepreneur inside a big company." anonymous coworker

A background on change

Carl stormed back to his desk, furious that the Jim the CIO blocked yet another profitable infrastructure enhancement. Carl had spent the last decade in a Fortune 500 company’s IT shop seeing brilliant minds and expensive consultants build a massive enterprise architecture that could handle hundreds of similar transactions a second. Carl eventually switched jobs, and hoped to bring his successful experiences with him. But Jim, obsessed with keeping the department alive during the current recession had no ears for anything Carl could say. Jim just wanted to keep the business sponsors happy, Carl just wanted to make things better - they were both professionals with good motives - but they often left meetings just angry at each other.

If you're a CIO, you're probably not reading this. So the real question is, what can Carl do?

Carl wants to create positive change. Changing a culture isn't just about "more" effort, rather it's about how that effort is applied. Who hasn't felt the frustration of spending a month of nights and weekends trying to boil the ocean only to have the initiative rejected with nothing to show for it? Often, a fraction of that effort could be applied more wisely, and to a more receptive initiative, such that you've changed (however slightly) the department for the better.

Three categories of changes

There is a big difference between business features and infrastructure/culture improvements. A business feature is simply some feature requested by the business - such as a new web page to enter data. The business doesn't care how that feature was implemented. An infrastructure change (or "process change") allows you to crank out those business features. Good infrastructure and culture means cranking out and updating more business features. The changes I'm talking about are infrastructure/cultural improvements - not business features.

 Over the years, I've seen three main categories of such changes, listed in order of impact from smallest to largest:

1. Individual - A developer makes a private change to simplify their job. It doesn't need any manager approval, nor does it change their "contract" with anyone else. For example, say every time you resolve a bug, you need to write a bloated email with source control and issue tracker information, and it takes you 20 inconvenient minutes every day. Say 95% of this email is tedious grunt work that is forced upon you because of some misguided process. You could sooner move Mount Everest than change this process, but life is what it is. So, you write some quick tool to query the source control and issue tracker databases, and generate most of that email. You're still sending out the exact same emails, so the bureaucracy overseers are satisfied, but now you're creating it in 60 seconds. This is an individual change.
2. Department: Private - The department (or team) has some thorn in their side, and as a team they can privately fix it "under the radar" - i.e. they don't need truckloads of cash, months of schedule time, other departments to change how they do things, or anything that would require the CEO's approval (the CIO may need to at least be kept in the loop). For example, perhaps they want to purchase a cheap tool, adapt a new convention, streamline their internal process, code generate their data layer, adapt a new development practice (OOP, unit testing, agile, etc...), start code reviews, refactor their code, make reusable blocks, etc... These are all types of initiatives that a non-micromanaged department can internally fix themselves.
3. Department: Public - The company's flagship application has just been hacked - some key developer five years ago forgot to do any client-side validation ("we don't have time to write the code re-validate on the server"), and everyone was so busy that they just copied & pasted that developer's code pattern - to all 200 web pages. The CEO herself holds an emergency meeting to tell IT that these security holes must be fixed, top priority, drop everything else. This change is still made by the developers in your department, but it's being tracked like an official business feature with status being reported directly to upper management in other departments.

For simplicity, let's call these cases #1, #2, and #3. Each has its pros and cons.

#1 changes are a good start, but by definition they don't directly benefit others. Private, individual improvements will no more change the course of a company than a dolphin flapping its fins will change the course of a battleship. Ideally, you'd either fix the root-cause with #2 at the department-level (say improve the process so that it no longer require those tedious emails), or you'd want to make an individual change easily promotable to #2 (say make your email tool a public utility that everyone can leverage).

 

Let’s skip #2 for now and jump straight to #3. These changes are great, but the sheer size of these makes them very rare and slow by definition. You maybe only get a handful of such initiatives a year, and they often need to go through layers of approval and red tape which makes them slow. These usually require CIO approval, so they're going to be very business-facing, and they usually take for granted the development infrastructure is already in place. (Think of developers smacking their head as some manager wonders out loud, "I just assumed that because you already did that dynamic rendering for one client, that we can easily apply it to all 500 clients - right?")

 

Back to #2 - it's these private department improvements that are the bread and butter of real company changes. #2 often mitigates the need for #1, and provides the necessary foundation for #3. Without #2, the individual changes of #1 become like building sandcastles on the seashore, and the huge changes of #3 get cut to pieces during actual implementation because the infrastructure can't handle its visionary goals.

 Because #2 is the key to real change, it's what this article will focus on.I'm thinking of smaller, gradual changes - adopt a new tool, automate a process, refactor critical code that everyone is scared of, empower some department so they can handle a task themselves without coming to you, create reusable code blocks, introduce a new quality control measure, add a new architectural component, bring in a consultant instead of building or researching a component yourself, etc... Each of these are small by themselves, but eventually they add up to greatness.
 

NEXT: Part 2

BOOK: Emotional Intelligence

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

I have always admired those who have a firm grasp over their emotions, and I don’t mean the Spock-like characters that appear dead to their feelings. This eventually led me to read Daniel Goleman’s #1 bestseller Emotional Intelligence. While the book was filled with good concepts, two really stood out to me:

• Verbal Bias - Many “techy” people have a verbal bias in their communication. They think it is more “logical” and “objective” to just go with the words that were written or said, and not taint that with someone’s non-verbal inflections. But such a bias is not more logical, quite the opposite. The majority of someone’s communication is non-verbal, and it is illogical to ignore additional (and relevant) information, therefore it’s actually very illogical to have a verbal-bias that ignores - or doesn’t attempt to understand - someone non-verbal communication.
• Emotional Hijacking – I’ve seen coworkers freak out. Rands points out that this means that they care. Great, but I don’t want to be the one freaking out where the frustration of a bad project gets the better of me. It helps to know that most of us have some sort of trigger that will instantly hijack our emotional state and make us go into a state of uncontrollable rage. For example, don’t tell me that “I don’t have time to write unit tests”.

Good emotional exercises that came to mind as I read:

1. Think of every emotion you can. You fail if you can only list “happy” and “sad”. You also fail if you keep listing physical states (“tired”, “hungry”) or mental states (“frustrated”, “focused”). I failed on both accounts. Then I went to google for “list of emotions”.
2. Think of 20 coworkers. What emotions do you think each are feeling? “Rejected” because no on adopted their initiative? “Excited” because they’re on a hot project?

The book has a lot of good zingers:

1. “the brain has two memory systems, one for ordinary facts and one for emotionally charged one.” (pg. 21)
2. “people who cannot marshal some control over their emotional life fight inner battles that sabotage their ability for focused work and clear thought.” (pg. 36)
3. “many people with IQs of 160 work for people with IQs of 100.” (pg. 41)
4. 5 fields of emotional intelligence: Knowing one’s emotions, Managing emotions, Motivating oneself, Recognizing emotions in others, and Handling relationships (pg. 43)
5. “New solutions and fresh ways of seeing a problem do not typically come from worrying.” (pg. 67)
6. “People who are optimistic see a failure as due to something that can be changed so that they can succeed next time around” (pg. 88)
7. “People’s emotions are rarely put into words; far more often they are expressed through other cues.” (pg. 96)
8. There are at least three ways of displaying emotions: minimizing, exaggerating, and substituting (pg. 113)
9. “The two cardinal sins that almost always lead to rejection are trying to take the lead too soon and being out of synch with the frame of reference.” (pg. 123)
10. “Stress makes people stupid.” (pg. 149)
11. “Many things people do at work depend on their ability to call on a loose network of fellow workers” (pg. 161)
12. “[stars] do the work of building reliable networks before they actually need them. When they call someone for advice, stars almost always get a faster answer.” (pg. 162)
13. “There are no grades given in Self Science; life itself is the final exam.” (pg. 268)
14. “The emotional mind is far quicker than the rational mind” (pg. 291)