Adventures of an IT Leader is written as a novel that resonated with my work situation. I was able to draw lessons across several themes:

Measuring value

  • IT differs from other businesses because it is not a profit center. Revenue attribution runs into conflict with multiple executives who lay claims on the same source. In addition, effectively allocating all or some of the value derived from the savings/efficiency gained from technology is not straightforward.
  • Classify activities as competes or qualifiers. The former generates competitive advantage. The latter are commodity areas, they get you in the game and should be run at minimal cost. Competes evolve to qualifiers, in which case the cost should reduce in support of it.
  • Consider time scale: for certain investments, measuring the ROI too early will underestimate the value; in particular for projects that serve as a foundation for later projects. For example, building a data store for facilitation of analytics, the data store itself doesn't have value.

Project Management

  • Project planning is different from managing projects. Project planning techniques ensure that a single person is not required in multiple places, but excludes advice on managing the unexpected. Note Parkinson's law in time estimations/allocations: work expands as to fill the time available for its completion. Also note that it costs you some of your project budget to learn what you need to do to succeed.
  • Death march projects: A project w/ a bad plan that managers are determined to stick with. The primary mgmt tool is yelling a lot and making people work longer hours. Managers leading a death march don't want to hear about unexpected problems, and workers understand that. So everybody just sweeps problems under the rug; it's the de facto mgmt policy. Smart people on the front lines make sure they aren't standing too close when it collapses on itself. (Ed Yourdon)
  • Technical work: Frontline should be willing to bring bad news to the boss because he often can't detect the bad news alone. Technical details leave experienced people a long time ago, so explicit ability to independently verify what the juniors claim is limited.
  • Stakeholders are people who can influence the decision outcomes you care about. Organizations are operationally more political than bureaucratic. They are marked by stakeholder groups that form temporary coalitions to influence patters of behavior. Identify and map stakeholders into categories (Allies, Blockers), then formulate independent strategies to deal with each category, or even an important specific stakeholder.
  • Costs in IT: No independent budget, they chargeback to the business using mapping rules. Complex mapping of costs lead to poor input into decision making.
  • IT cycles: IT projects are launched during good years to chase rising demand, then become sources of unacceptable cost once the new demand disappears.
  • When assigning the "best" people to a project: If they are easy to give up, they're not the best people.

Communication with Peers and Juniors

  • Responsibility for business process decisions should sit with the business, but there is usually a lack of technical expertise in the majority of the team members. Hence, technical teams often take responsibility.
  • Exaggerated visibility of decision consequences and extreme transparency of process make it impossible for anyone to credibly claim that they were not aware of a trade-off decision.
  • Models: simplified representations. Nothing useful is real, it's been simplified. If it's complicated enough to be realistic, it's too complicated to be useful. Be flexible - there is no "right" model.
  • For a person in a hard role, he knows nothing about the role. By definition, neither does anyone else. That puts one on equal footing with others.
  • Buy-in: Everyone has their neck in the noose and everyone can feel it tightening. If you get people to understand the trade-offs and participate in decisions, then when something goes wrong, you are all in it together.
  • Some people get paid a lot of money not to know a rainforest from a desert. They succeed mostly by managing the appearance of success rather than actual success.
  • Innovation: Accidents get you out of old-habits and produce new outcomes. We resist them because they are more likely to have negative consequences than positive ones.
  • Ambition: Resist the urge to offer to do it more quickly.
  • Taking notice: dynamics between you and others around you.
  • Physical presence: sitting back in his char and folding hands on lap to signal open-mindedness.
  • Good phrase to get juniors talking: "Don't leave out your own opinion of what has happened."
  • Control annoyance and work on maximizing the value of the conversation.
  • More helpful mode of thinking: concrete first steps on the new problem.
  • Be resourceful, gather information from an array of people.
  • Surface-level helps, but to get into the next level of discussion requires relationships. Don't meet once, meet periodically because the most valuable guidance will come in time, not right away.
  • Presenting yourself in a different context might yield new information from the same source.

Communication with Superiors

  • One can be too forthcoming in laying out everything known so far. Don't take problems to your superior, bring solutions. Explain the problems when you know how to solve them.
  • Losing mgmt's confidence in you creates a new set of problems. Expect to get more 'advice' and do more than inform them on the ongoing process and recommendations, expect to also have to explain and justify not following advice.
  • Two options on frequency of communication - 1) go away, fix a lot of things, and come back to claim progress, or 2) more frequent and incremental updates.
  • Communicate in such a way that it builds confidence.
  • When you aren't present, imagination builds up in absence of evidence to the contrary. Get in front as soon and often as possible as they'll put up with. You can't rebuild a relationship without interacting with the person.
  • You probably can't make things worse with your interactions if you are a reasonably pleasant person to be with.
  • Writing a memo to your commander does not constitute completed staff work. But writing a memo for your commander to send to someone else does.
  • Post-mortem: Think through the finer points how you present once completed.

Vendors and Internal Shock Pundits

  • The classic problem: vendor wants to win the contract, so they tell the business people what they want to hear. Internal tech raises concerns, which business interprets as lack of expertise within the company because they want to believe the vendors.
  • Post-contract signing: The problem from the vendor perspective shifts from winning the contract to managing the overblown expectations created by claims they made while trying to win the deal.
  • Shock pundit strategy: say something outrageous that your target audience wants to hear, then sit back and watch the protest from people who know better.
  • Easy to get mired in the muck and fight over the small stuff. Step back and think big picture and long term. What does the future of our business look like if we completely reimagine it around a more partner-based, virtual, and global concept.

Managing Talent

  • Value is not strictly in their time. It is in their smarts, resourcefulness, good business judgement, their ideas about new ways to do things.
  • Manager: Careful and effective interpretation of the disparity between what we want from people and what we can readily measure.
  • Technical work: The ability to independently verify what the juniors tell us is rather limited. The details leave people in the dust.
  • Technical knowledge is relatively explicit and learnable, whereas a lot of the understanding that make managers effective is tacit.
  • Know the things you don't know.
  • Self-judgement while performing has limited value - be in the moment and trust your abilities.