Joseph Eng, CIO, JetBlue on how to make IT leadership credible and driving value into the business
In an interview with Meet The Boss TV editor-in-chief Adam Burns, CIO for JetBlue Joseph Eng unveils the secrets of IT leadership, how to manage directors' expectations and the key to managing staff
Meet The Boss TV: One of the toughest challenges facing a CIO is managing the expectations of senior executives and the employees within the company. In your previous role at Swift, you set out four principles of managing expectations: Define expectations internally; establish rules of engagement; deal with doubters; and not everything is negotiable. Have those changed or been refined during your time at JetBlue?
Joseph Eng: Those have been the hallmark of what I've done and what my teams have done to create success.
I think IT leadership - successful IT leadership - has to be about engaging the business, aligning with the business, building a relationship with the business. We need to not get into the stereotype of being the 'IT person', the techie person, because actually in this day and age the more successful IT organisations and leadership is about being engaged and being part of the business leadership team. You happen to have a role, but you're part of the business leadership team. If you're seen as a niche techie IT person, I think you'll have a very hard time really driving value in the enterprise.
Around that you said, "You need to set up a governance type of structure, and I say this very bluntly, to force the business to be involved in IT." How does that structure work at JetBlue?
Well, the governance structure at JetBlue is a regular committee or forum that engages senior leaders of the business, and from an IT perspective, one of the biggest challenges is we always have more than we can do.
I can't think of any firm, IT organisation that says they're not busy; and you always have a lot going on. So the challenge, getting to meeting expectations or managing expectations, is prioritising: get alignment, get agreement. And so we use a governance structure, committee, forums to bring IT leadership together, but more importantly to bring the business leadership together, to really outline and provide transparency.
Because then you'll have - you'll be struggling with a lot of contentions and priorities, and here's where you get that agreement across the business of saying, 'These are the priorities. These are the things that IT needs to go off and work with the business', and then we go off and focus and execute.
What real business outcomes have you seen from this governance structure?
At Swift it had a lot to do with when we brought out our new product platform around IP-based financial messaging platform. It allowed us to decide what are the product features that we had to have in a platform in the first release, the second release, the third release. You have to prioritise because at some point in time you got to close the door and say, 'We got to go focus on that'. The biggest risk many times of IT groups is scope. Too much scope. Changing scope.
You have got to lock in and get it done here, and so that was what allowed us to be successful and launch that platform. And at JetBlue we've had several innovations. The ability to launch at T5 on time, in fact, we would debate and argue that we were ahead of schedule in launching the T5 terminal opening at JFK [airport]. Launching a new product called Even More Legroom in 2008, which was a multi-month project that got rapidly done to drive a lot of new ancillary revenue for us as a business. Those are some of the successes that we don't just have an IT group, but we say as a firm were successful and IT played a key role in that success.
You mention the rolling out of the IP at Swift and I believe there was a small delay on that, which you obviously had to deal with and manage around. Do you feel that there were very definite lessons there, particularly in the what if scenarios etc, that you managed to bring to this?
Well, in that particular case at Swift we did - we were running up to starting the launch of a product roll out, and we did hit a problem. I think we learned here hope is not a plan. You can't just wish and wish and wish. You got to deal with the reality, and we came to a point where we said, "This is not gonna work." We would risk reputation of our company with our customers by just trying to get this rolled out there and just kind of deal with it on the fly, so we had to deal with that harsh reality.
And, as I've said to many and I think has been discussed in industry circles, [it was] a very difficult time but you have to face that. I think that's part of leadership - it's not just the good times it's how you deal with the not so good times and having to deal with that harsh reality that we weren't ready. Having to go and discuss that with my colleagues in executive management. Having to go discuss that with the board. Having to get out there with customers and say: 'We've made this decision. We don't feel we're ready. We're doing this in your best interest because we wouldn't want to have you struggle with the product. We need more time. This is what we're doing to re-do the schedule. This is what we're trying to do to minimise impact to you but this is the reality of the situation.'
And similarly we've had to apply those principles at JetBlue. There is - we want to hit the date, but there is a point where you also need to have other factors. It's not just a date. It's do you have the functionality that's expected. Do you have the right quality that's there? If you hit the date and it doesn't work, you really haven't done much.
I think IT leadership gets more credibility and gets the opportunity to participate more at the table, of course, by delivering success, but also being very candid and prepared to be transparent about the issues and the challenges and to demonstrate it understands and is working on that. The last thing anybody needs is the last minute surprise.
You prefer a smaller, more nimble, more agile IT department, and you bring in products and value-add around that product rather than build. How does the CIO make those decisions and what metrics are you using? What are the signposts that you're looking for to assess success or failure?
I think we should take a step back, and I want to make sure there - it's not that I have a particular philosophy of one should do development or one should do more buying of applications. For that matter, in previous roles I've managed large product engineering development organisations; and at JetBlue we're not doing that. I think it goes back to, again, the alignment with the business, understanding the business objectives. So at JetBlue we are looking to have rapid cycle time. We're looking to create more customer innovation with regards to the platforms and capabilities that we bring to the table...