One of my favorite words/concepts in IT is transparency, the idea that we let

the business see what we're going, why we're doing it, how much it costs, and

even what we did wrong. Most business people have a pretty good idea of the

value that IT brings to the organization, but many also tend to feel that it's a

black box that seems to work on what it wants to, rather than what they think

should be done. On the IT side, for the most part we're content to solve

whatever problem they want us to solve (and the harder the better!), but with so

many voices asking for so many things, how do we figure out what's really

important? I don't all of the answers but I will share an approach that at least

brought a bit of sanity to a confusing situation. And to be fair, this is not a

SQL article, but I hope you'll read it anyway.

At my last job over the course of the six years before I took over management

of the development team I saw the pendulum of control swing wildly. Operations

would cry that they should be driving IT direction, IT would say ok and wait for

direction, and operations would spin in circles and never really decide

anything. Over a few months the pendulum would start to drift back to the other

far side, with IT gradually making some and then almost all the decisions about

what should be done based on what they understood to be operational priorities

from attending as many meeting as they could. Then something would go wrong, not

get done, etc, and operations would cry for control all over again. A leadership

problem? Yes, but in my opinion it's deeper and more complicated than that.

When I moved into management I attempted to address the issue by making

public our task tracking system, allowing anyone who cared to see where their

request was on the list and when we thought we might get to it, and by attending

as many operations meetings as I could to stay up to date on problems and

upcoming requests that might need to be moved to the top of the list. In

essence, I took responsibility for trying to figure out what they wanted, when

they wanted, and for trying to resolve resource conflicts (because there is

never enough time to get it all done). I made some progress and I think won

some amount of trust, but after a year I could see that I was just spinning

about 12 plates and sooner or later I was going to break some. I needed to

bridge the gap in a different way to try to get us out of reactionary mode.

After a lot of thought, thinking about options like a more elaborate

tracking/request system, committees, etc, I ended up proposing a very analog

solution:

• Hold an IT (development centric, but open to any issue) meeting in my

  office at 1 pm each Fri

• Any manager in the company could attend in person or by conference

  bridge

• Meeting would last one hour
• Each attendee would have 3 minutes to ask a question and get a quick

  verbal update, we would continue around the room until there were no more

  questions or we used up our hour

• Priorities for the next week would be set on items that surfaced at the

  meeting

• We would send out minutes of the meeting the same day that would include

  our schedule for the next week

We ran the meeting simply, just a flip chart to record attendees and to write

down their questions. What we saw in the beginning was a real hunger for

information; are there any plans to do blah, what is the status of this request,

and fyi's on upcoming requests. We also saw some frustration about the backlog

of requests and how we were prioritizing. I would attend with the two managers

on my team, and we would answer as clearly as we could, with no hiding of

mistakes or missteps on our part. It's not entirely logical, but admitting to

mistakes gives you more credibility than if you don't admit them. We also saw

that there was rather large number of requests that were fairly small in scope

that were causing the most visible pain. By tackling some of those - even though

they weren't perhaps the most important tasks we could do, we proved that

we were willing to listen and be responsive within the context of our

obligations. We also explained why sometimes we couldn't, or shouldn't, spend

time on some requests immediately. The attendees in the beginning were what I

considered to be the best of our managers, the ones that cared the most and

wanted to get things fixed that would help them achieve their goals. But even at

the second meeting we saw attendance build beyond that as others heard that it

might be an effective forum and was a way to get your project pushed further up

the priority list. The most interesting aspect though was that the first or

second person to speak would have some "hot" issue that needed immediate work

and then later in the meeting someone else would be requesting priority tasking

as well, and that original person would often speak up and say 'that's more

important than my issue, I can wait a week or two if needed'. I think that

happened for two reasons; one is that they had found the only way to get things

done was to 'cry wolf', and the second is that before they were all asking from

a "me" perspective, but now they could see their request in the scope of the

collective needs of the business.

Did I game the system a bit in the beginning to make it work? Of course! You

can call it politics, good management, cynicism, or just plain cheating, but if

I expected people to take an hour out of their week to attend another

meeting I had to prove that I would do what I said I would do, and show that the

meeting format was an effective means of helping them with IT. I have been to

too many meetings that accomplished not much of anything to want to sponsor one

myself.

Following the meeting we would take a break, then we got started on planning

for the next week by evaluating what we had accomplished in the current went.

Task by task we went through to review the status and write down what would go

out in the meeting minutes. That's right, we didn't just publish our plans for

the upcoming week, we reported on exactly how we did on the previous week plan.

You can imagine my teams weren't too happy to learn that any time they failed it

would go out in a email to every manager in the company! That's part of

transparency of course, you have to show the good and the bad, and maybe even

the ugly. Once we had hashed that out, then we went into

the planning phase for the next week, trying to figure out how to juggle all the

requests posted at the meeting (or carried over from previous meetings) with

'super' requests that had some down from the CEO/CIO. You can imagine that after

that first email went out with a few 'task not completed' notes that they became

a lot more conservative in projecting what could be done, sometimes too much so,

but I thought it set up a good tension between me (representing the

organization) wanting to do more and the teams wanting to be able to complete

100% of their commitments.

The final step was to compile all that into a standard template and email by

the end of the day:

• List of attendees
• New requests brought up
• Old requests still open
• Results of previous week
• Plans for the upcoming week
• A short narrative that might include comments about something that went

  really well or badly, decreased work projected for the next week due to

  vacations, things that had to be deferred due to lack of information, etc

• A reminder to dispute the plan by noon on Monday

If you're wise to the ways of corporations you might spot the two interesting

ones in that list; list of attendees and the reminder to dispute by noon on

Monday. If you think back to where I started, I was trying to reconcile all IT

requests to figure out which ones were most important and I was never going to

please everyone that way. I needed a system where the business provided

substantial - but not final - input into what we should be working on. I made

very clear that attending the meeting or sending a proxy was necessary to get

items on the agenda. If you didn't have time to attend, it was going to be put

way down on the list because everyone present would vote their tasks as higher

priority! You had to be there to argue your case. It is a lot harder to complain

in meetings about IT not supporting you when you haven't attended the main

meeting that makes things happen.Now before I started I knew that two things

would happen. One is that no schedule is set in stone, sometimes things happen

that require you to chuck your plan and solve an immediate problem. The other is

that someone would not want to play by the rules and would try to overrule me,

which if happened often, spelled death to the meeting.

I spent time with the CEO/CIO before I had the first meeting to make sure

they understood what I was trying to accomplish, why I thought it would work,

and how they could help me make it work. It didn't take long for someone to try

the end run, perhaps the 3rd or 4th week someone calls on Tuesday to complain

that they just heard that something they needed done by Friday was not on the

schedule. Yes, that's correct, sorry about that, see you at the next meeting on

Friday I replied. Followed by 'you don't understand, this is important, blah

blah', but in my judgment it was not pressing enough to alter the schedule and

probably wasn't doable by Friday anyway given that we had no background on the

task. Upset manager says she will go to the CEO. That's fine, do what you need

to do. Later I get the other half of the story from the CEO. Upset manager comes

in, explains that we aren't going to meet her client deadline. CEO asks did you

know about the meeting and how it worked? Yes. Did you attend the meeting or

send someone to represent you? No? Did you get their email with the weekly plan

Fri afternoon? I don't know, I guess. CEO says 'I think you should plan to be at

the meeting this Friday if you want it done next week'. Tough love baby! Were

there times when we had to break the schedule? Absolutely.

The biggest mistake I made was branding the meeting as 'the squeaky wheel

meeting' because our intent was to help those that yelled the loudest, and

because I have an evil sense of humor at times. I had a senior ops manager

complain that it was horrible way to run a business by catering to those that

complained the most. Said manager had never been to the meeting of course. I

tried to explain in practice they were really good about prioritizing among

themselves and that once we had handled a lot of small irritating problems, for

the most part we were dealing with serious requests from people that cared

enough to push their cause. He was right in a sense, certainly we should be

doing the most important things first, it's just a matter of who is

prioritizing the list. All of those early attendees were the ones most

dissatisfied with IT and over time because our strongest supporters because we

were fair, honest, and open, and we had proved it time and again. Note that it

wasn't that we weren't fair and honest all along, we just had no way of showing

it. As we won more and more support, we started to get more lead time on

requests because they had a sense of what was already on the list and what the

larger needs of the company were. They were also a lot more forgiving when we

failed at something. Transparency doesn't necessarily equate to credibility, but

it can really help you get there.

The minutes were perceived by the CEO has having real value. IT is expensive

and I think a lot of CEO's wonder if they are getting the best bang for their

buck. They get a lot of high level info via the CIO, but like most managers they

like to see what's going on in a little more detail one more level down. It

helps them assess their direct reports and they like to see how mid level

management is doing. More than once I'd be in a meeting where the CEO would

refer to something from the minutes and you could tell that having that extra

bit of knowledge was empowering.

Would this system work everyone? I can't say that, having only tried it in

one place, and it does take some backing from higher up to be effective. But

rather than try to replicate the formula, think about whether you're

sufficiently transparent to the rest of the business. The two reasons I see

people avoid transparency is not wanting to admit any mistake publicly if they

can avoid it, and thinking no one cares beyond their manager. I disagree with

both, but it can be a hard step to take - more so in some cultures than others.

You might be surprised by how many people would like to know what you're working

on, what kind of challenges you face, what caused the server outage, etc. Just

keep it simple, make it as analog as possible, and be consistent. A simple blog

of what your team is doing and why might be a just as effective and require a

lot less effort.

I blog once a week or so at

http://blogs.sqlservercentral.com/blogs/andy_warren/default.aspx about

SQLServer, SQL user groups, and related topics. I hope you'll visit and comment

occasionally!