“Nick, we have a leadership meeting regarding a new partnership we are looking at for next year, and I need you to be there.”
To most, this would generate a groan due to another meeting being added to an already jam-packed schedule. However, this was music to my ears; the IT gods had finally listened after all these years. The team now understood the value and importance of IT “being at the table.”
This is step one — and the most critical in the process — because at this point you are now viewed as an integral part of the team. It is impossible to be a “partner” if you and the department are not viewed as a counterpart to the others.
Getting to the table usually happens organically due to a combination of IT raising their hand while jumping up and down saying, “we can help, we need to be involved” from the back of the room, and when a project is negatively impacted because IT wasn’t involved from the start. Typically, when the latter happens, this will bubble up to the executive team; here’s where appreciation of IT is born. But once at the table, we, just like any other function of the hospital, need to continuously produce results, become a go-to resource, and help drive the organizational goals forward.
“By the way, we need IT to implement this solution in the next 60 days.”
How many times have we all heard this, or something extremely similar? The natural reaction for most of us is to roll our eyes or become immediately defensive by replying, “We can’t do that with all the projects currently on our plate,” or “We didn’t know about this until now, I’m not sure we can satisfy that timeline.” Personally, I believe that message is incredibly damaging to the perception of IT being a strong partner, since it is entirely negative in nature and puts us back on the island we are trying desperately to escape.
Instead, this provides a golden opportunity for us to ask questions such as ‘Why is there a rush on this project? What is the problem we are trying to solve?’ By doing so, we accomplish a few objectives all at once. First, we did not separate ourselves from the request, but rather showed interest, which is a much more positive reaction. Secondly, we start to see the big picture of what the rest of the executive team values, and the destination that we’re trying to drive the organization toward. If there is such a rush, there must be a need that we are attempting to satisfy.
This brings us, as the IT leaders, to a perfect juncture. We now know the need and reason, and can assign a relative priority. We can now offer solutions and suggestions for the rest of leadership to assess. The feedback from these discussions is incredibly valuable, as the details for why a given idea may or may not work can provide even more insight to other issues at hand, or simply educate us on workflow/business processes. The value of the information derived from these discussions with our counterparts should not be underestimated. Treat it like you just received an unexpected a stash of bitcoins. If managed well, it will inevitably yield an improved relationship that will serve both leadership and the IT team as a whole.
“From an IT perspective, this is what we need to accomplish, this is the impact and why it matters to all of us.”
The previous situations have outlined how I’ve been able to become involved in the broader discussion and help push the organization or other specific department’s initiatives. But as with any relationship, it should go both ways; and as we all know, IT has a technology specific agenda to drive as well. In this case, I found being a “translator” has paid big dividends. Others in management do not, and should not, need to know our techy talk; we need to translate what we need to accomplish, and why they should have an interest in that. By already establishing ourselves “at the table” and conveying the importance of being at that table, when we know bring something to discuss, it should be treated with the same importance. By developing those relationships with the counterparts, the discussions around IT initiatives tend to be less contested.
One of my favorite examples is when an IT leader proposes the need for a monthly maintenance window. The initial reaction from other leaders might be, “No way, how could we purposely cause a disruption like that?” However, by learning other workflows/processes, building the relationships and translating IT lingo into a language that the rest of the team can understand, we have a greater chance of implementing a successful IT strategy, whereas previously our plan would have been crushed before we even finished explaining it.
Obviously, none of this is rocket science, but one of my favorite cliché lines that I preach (and probably overuse) is, “What separates a good team from a great team is that a great team does the basics really well, and more importantly, they do them consistently.” This applies here because what I have outlined is simple. If you communicate with, and garner trust among, your peers on a consistent basis, you’ll become a vital part of the team, which will not only drive organizational strategies, but those that lie within IT itself.