SQL Clone
SQLServerCentral is supported by Redgate
Log in  ::  Register  ::  Not logged in

IT Transparency

By Andy Warren,

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!

Total article views: 3460 | Views in the last 30 days: 46
Related Articles

Monitoring a Rollback and sys.dm_exec_requests

The dynamic management view (DMV) sys.dm_exec_requests returns information about each request that i...


SQL Server is terminating in response to a 'stop' request from Service Control Manager

SQL Server is terminating in response to a 'stop' request from Service Control Manager


DMV-3 : What is currently going on ?……..sys.dm_exec_requests

sys.dm_exec_requests DMV (Dynamic Management View), described by BOL as follows: http://msdn.microso...


The request failed with HTTP status 400: Bad Request.

The request failed with HTTP status 400: Bad Request.


Guest Editorial: Managing their expectations

In which Phil Factor's attention wanders whilst reading some software product announcements and imag...