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