All Posts in Career Management

|In: Career Management|Last Updated:

Let’s get down to cases.

No, not use cases, and can we all please stop adding “use” to “case” to try to sound cool unless we’re planning to use the Rational Unified Process to actually define one?

Thank you. I feel much better now. Where was I?

You want to provide technology leadership. You’ve assessed the situation and all the factors we’ve talked about over the past two weeks are in place, including an enthusiastic business partner. Now what?

Now you’ve learned something about the danger of success, that’s what. Because if everyone you pitched your idea to had said no, you’d have the satisfaction of saying “I told you so” in a few years. Much easier than all the hard work of actually making something happen.

Don’t say I didn’t warn you. Anyway …

You and your sponsor will be tempted to do this the easy way: Evaluate development partners who are experts in whatever the technology is you’re talking about, make sure the winner agrees to adhere to your technical standards and (if you’re advanced) to work with your enterprise technical architects to make sure the new stuff has a clear place in those standards, sit back, and enjoy the show.

It’s tempting. But it misses the point, which is that your most important goal isn’t a successful implementation. Your most important goal is to build a reusable organizational capability.

To be fair, sometimes the best way to build an organizational capability is to establish a firm, deep, durable relationship with an outsourcing partner. If that’s your plan, fine and dandy, but make it a clear and explicit choice, not a default, slippery slope you fall onto because you took the path of least resistance. And even then …

If you outsource, you have a bit more to do. If you don’t, you have more.

Start with the basic framework of organizational design:

  • Process — how you want the work to get done.
  • People — new skills and knowledge you’ll need in your organization.
  • Technology — not only the technology you’re trying to introduce. “Technology” means tools, which includes little niceties like how the new technology fits into your overall development environment, what you’ll need in the way of testing tools, and how IT operations will make sure the new system is working right.
  • Structure — once you’ve finished a successful pilot project you’ll need to assign responsibility for the various bits and pieces.
  • Culture — everyone’s mental habits around how we do things around here. If the impact of culture isn’t immediately obvious, think back, if you’re old enough, to the early days of the World Wide Web, when IT figured the company website should be developed using the same disciplines it used to implement the general ledger system, but Marketing figured it should use the same disciplines it used to build marketing campaigns.

Don’t get too far ahead of yourself. Pilot projects give you more than quick business benefits and “proof” (hah!) of concept. After the pilot you’ll have the benefit of hands-on experience, unlike now when all you have is the benefit of abstractions and theory.

For the pilot, engaging an experienced outside partner is generally a good idea, assuming the technology isn’t so new that there is no such thing. But engaging an outside partner isn’t the same thing as handing the project over to the outside partner with little or no internal involvement. Don’t do this: You and your staff won’t learn anything, except for what you’ll learn about the resentment you’ve caused by giving the fun stuff to the outside vendor.

So make blended teams a project requirement. Assign project management responsibility to the outside vendor. Fair’s fair — allow a certain amount of inefficiency as the team members you provide come up to speed.

But your goal is, at a minimum, owning business leadership, and very likely self-sufficiency. This is your opportunity to build enough expertise to accomplish this.

And in particular, don’t forget the critical role your business analysts will need to play. They’re the ones who match what information technology can do (both the stuff and the organization) to what business executives and managers want to accomplish.

With any luck you’ll have an obvious choice — the business analysts who have already been in your office, trying to persuade you the technology in question has important potential for the business.

Haven’t had any? You aren’t alone. In my experience, relatively few business analysts think maintaining awareness of new technologies and trends is something they ought to do.

The same thing seems to hold among developers, sad to say. So on the people side of things, give this opportunity to the happy few exceptions who do.

* * *

Truth in advertising: I’m employed by Dell Services, which is in this business, which means I’m not entirely impartial in thinking vendor support, either for your early-stage efforts or for building your capability through an outsource, is a good idea.

Comments

|In: Career Management|Last Updated:

Leadership. The word is inspiring. Even those who run away from decisions as if they were rabid wolverines utter it in reverential tones.

Leadership, for the benefit of those who haven’t read Leading IT: <Still> the Toughest Job in the World, is the art of getting others to follow, and requires competence at eight tasks: Setting direction, making decisions, staffing, delegating, motivating, managing team dynamics, establishing culture, and communicating (which consists of four sub-tasks — listening, informing, persuading, and facilitating).

The subject is technology leadership — how IT can identify promising new technologies, incubate them, and incorporate them into how we do business around here. It’s technology leadership whether the technologies are new and emerging or just haven’t been put to use in the business IT supports.

But it’s always about leadership, which is to say getting the rest of the company to follow — not a traditional role for mainstream IT management, which is often so fearful someone will accuse it of squandering the company’s scarce financial resources on technology for technology’s sake that suggesting the company explore something new, different, and potentially useful is as intimidating as proposing a hefty assessment to pay for roof replacement at a townhouse owners association meeting.

So the starting point for technology leadership mirrors the first message in Leading IT, which is, it’s okay to lead. Not only is it okay, the business leaders I talk to are, for the most part, hungry for it. They want to have conversations about how they can use information technology to (1) get their work out the door more effectively; and (2) do something entirely new, different, innovative, and most important, profitable. Sadly, as discussed last week, few in IT are even equipped to have these conversations.

To be fair, plenty of companies, and I’m including many of those who undertake formal strategic planning exercises, aren’t equipped for them either. Their strategic plans are tepid, fearful things. These companies don’t think in terms of gaining marketplace advantage, beating the competition … you know, how to grow. Technology leadership can’t happen in these companies because no leadership can happen in these companies.

When decisions are rooted in fear, the outcome is stasis or retreat, not innovation and progress. If you lead IT in an environment like this, unless you’re close to retirement and just coasting along your best move is to find a better place to ply your trade.

Or, your company might be poised to become an aggressive leader in your industry. Its executives might want to try something more exciting and competitive than a stock buyback. They just don’t have better ideas about how to invest the company’s spare cash. All it might take is the suggestion from you that (for example) adding intelligence to the company’s products might make them more desirable.

(Speaking of stock buybacks, an irrelevant question: If a company buys back enough of its own stock, can it become autonomous … self-owned? As corporations are people too, perhaps we should encourage this. It would be equivalent to Roman slaves earning enough to buy their freedom. I look forward to your irrelevant answers.)

So … last week started a list of factors that must be in place if IT can be successful in providing technology leadership:

  • Awareness: If you don’t know it exists you can’t recommend it.
  • Relationships. If they don’t know and trust you, they won’t be open to your ideas.
  • Astuteness. If you can’t envision the new thing in practical, day-to-day use, you’re blowing smoke.
  • ETAM (enterprise technical architecture management). The alternative to colonizing a new “island of automation” that results in re-keying-based integration and redundant business logic to maintain.

It’s hardly a complete list. This week’s discussion leads to two more:

  • Receptive audience. Without at least one influential executive who wants to try something new and innovative, your attempts at technology leadership will lead to nothing but frustration. Unless they lead to immediate unemployment.
  • Long EHL: EHL, for those who haven’t been with us long enough, is the epiphany half life — how much time must elapse for the enthusiasm for a new idea to decay to half its original level. If you want to provide technology leadership to your company you’ll need persistence — the ability to maintain your enthusiasm in spite of the inevitable organizational roadblocks you’ll encounter.

How does EHL fit into the discussion? Audiences don’t always start out receptive. Sometimes you need to persuade them — not an instantaneous process. If you don’t have a long EHL, the organizational depressives who surround you, trying to persuade you it will never happen here — will wear you down and wear you out.

They’re easy to recognize. They’re the ones who call themselves “realists.”

Comments