Read: War and Peace and IT

I got this book, War and Peace and IT by Mark Schwartz for $0 at Amazon.com. I think IT Revolution was holding some promotions which is how I got it for free back then so I was spared from shelling out $12.99. I bought it last May, but didn’t come around to actually opening it until this June.

We had a rocky start. The author pretending to be Napoleon Bonaparte in the Foreword section was something I found a bit too corny for my taste. So that made me put off reading it for a few more days or so. When I eventually reopened the book, I reached the section in the introduction sharing who the book is for.

Not me:

  • CEO
  • CFO
  • non-IT CXO
  • CIO or IT leader
  • Any category of business leader

And finally me: “For others in the business and IT community”

So mmmkay, I’m definitely not the main audience for this. I read it anyways. And it actually wasn’t so bad after I got over those hurdles. What I particularly like is that there’s a chapter summarizing suggested actions. So if you’re looking for one chapter to read in the whole book, go for Chapter 10: “Action Plan”.


I’ve listed out some bullet points from Chapter 10 below. For the full context though, you’ll still need to read the book. But at least this can give a starting point on whether you find the suggestions interesting enough to push through with checking out the $12.99 book.

Tie IT initiatives to business outcomes.

  • Choose a few objectives for trial.
  • Assign each to a cross-functional business/IT team that is fully empowered to execute.
  • Use impact mapping to brainstorm with the team.
  • Remove impediments.
  • Review progress often and make adjustments.
  • Celebrate success.

Shorten lead times.

  • Emphasize urgency and fast delivery.
  • Your goal is not to make people work faster or harder, but to improve workflow. Make that clear.
  • Take advantage of the cloud.
  • Ask IT to speed up the portion of delivery that is technical. This will probably involve implementing DevOps, creating reusable components, and designing secure “landing zones” in which new work can safely be done.
  • Find bureaucracy that isn’t adding value or that could be made leaner with Occam’s turkey carver. Often this includes sign-offs required from people who have no good basis for making the sign-off decision, forms that ask for unnecessary information, or controls that could be automated.
  • Becoming lean means reducing calendar time. Wait time, for example, should be eliminated, even though no effort is being spent.
  • Task switching is a source of waste and defects. Organize work so that everyone can focus. You can make this easier by keeping tasks small so they can be finished quickly.

Emphasize delivery and results.

  • Ensure that work is organized into very small units, work toward minimum viable products, and experiment to learn and test ideas.
  • Monitor results starting immediately.
  • Remove organizational impediments that resist quick shipping.
  • It may be easier to begin “working small” by modifying an existing system.
  • “Shipping” means that people start using the product. Prototypes and demos aren’t shipping (although they might be valuable steps on the way).
  • Don’t be afraid of disruption from shipping quickly. The idea is that by shipping quickly and frequently, each shipment is very small, and is consequently low-risk.

Treat requirements as hypotheses.

  • Read the Side Glance on humility! [this is another chapter in the book]
  • Question assumptions by asking how they can be tested.
  • It’s better to put effort into testing an idea than to risk not testing it.
  • A/B testing (where some users are shown version A, some version B, then the results are compared) is very effective and might be easy to set up.
  • Be sure that the test subjects are the same people who will be using the product—not, for example, managers or people within the product team.

A culture can’t turn ideas into innovations

I was skimming through some of my old notes when I came across this line:

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

And I thought of how there’s always a call to innovate at work. There’s always an invitation for new ideas. There’s always a call for change.

But it’s one thing to ask, and another to deliver. I’m a firm believer that you can’t just say something and that alone will will it to happen. There’s got to be some intentionality. If you want something done, you have to create space for it, you have to make time for it, you have to allow for it to happen. Because, physics, I guess. I don’t know how else to explain that going from A to B requires actually going from A to B. Hmmm… maybe logic.

Anyways, I’m putting in here some of my other notes relating to that quote and to creating the space for work or change to happen.


From “Innovation for the Fatigued (2019)”

The core tenet is if you want more innovation, give people what they need in order to innovate.

  • Make responses mandatory
  • Promote givers — In order to build a culture of reciprocity, leaders need to look for the givers of the organization, the people who are always ready to help with comments or support for ideas, and look to promote for generosity. The more givers you have in top management, the easier it will be to build respect and reflection.
  • Twin demands with support — You cannot develop innovation in an organization by simply demanding more and more of it. … make sure that demands are always reciprocated with support – be this allotted time, material resources and/or encouragement.
  • Punish indifference

Without reciprocity, in both deeds and resourcing, a culture can’t turn ideas into innovations.

From “It Doesn’t Have to Be Crazy at Work (2018)”

Reasonable expectations are out the window with whatever it takes. So you know you’re going to grossly underestimate the difficulty and complexity required to make it happen.

…Rather than demand whatever it takes, we ask, What will it take? That’s an invitation to a conversation. One where we can discuss strategy, make tradeoffs, make cuts, come up with a simpler approach all together, or even decide it’s not worth it after all.

From “Fast Times (2020)”

Having bold aspirations matters, but only when also matched by corresponding commitment. Without allocating funds and resources at sufficient scale over enough time, the value of digital will remain a mirage—promising but forever out of reach.

From “Brave New Work (2019)”

Creating space also means making time for change. Because most teams simply don’t have it.

One of the most self-destructive tendencies within teams is to get so busy that we believe there’s no time to get better at how we work

Continuous improvement is not magic; it is a discipline. It is a thing we do. And like all valuable things, it takes time. The average team doesn’t spend even thirty minutes a week reflecting on how they work together. They are going to need your help to stop this pattern and clear a path. Because we can’t learn if there’s no time to think. Teams need time for retrospection. They need time for personal reflection. They need time for deep work. They need time to run experiments and find a better way.

From “Full Metal Alchemist” (Anime)

Humankind cannot gain anything without first giving something in return. To obtain, something of equal value must be lost. That is Alchemy’s first law of Equivalent Exchange. In those days, we really believed that to be the world’s one and only truth.


There’s not going to be a shortage of material that supports the idea that it takes action to make change happen. Magic would be cool but most of us are muggles.

More on When in Rome

One of the things I often say is “When in Rome, do as the Romans do.” I have some team mates who admittedly know me better than most that jokingly say what I really mean is “When in Rome, invade the Romans.” While I have no plans for domination (that’s just too much trouble), a lot of jokes are half-meant.

“When in Rome, do as the Romans do” is not a call for conformity, submissiveness, or withdrawing your own beliefs to follow someone else’s. To me, it’s about flexibility and just being plainly realistic that when you’re thrust into a new environment (be it a new company, a team, or a project) you can’t expect things to go your way or the old way that you know. You need to “do as the Romans do” to survey the environment, find out how things are being done, and more importantly to find out why things are being done a certain way.

There’s a saying that goes first learn the rules then break them. “Doing as the Romans do” allows you to learn the rules. This gives you the context and is essential for finding out which rules you can break or to how much extent can you push the limits of the rules. I don’t generally condone rule-breaking (I hate jaywalkers), but sometimes there are just BS rules (Google: sacred cows) which were set in place ages ago that are no longer relevant to the current situation. To me, rules (just like tools and processes) should be there to help make things easier or move things along more easily. If it’s more of a pain in the ass, then something’s wrong.

And I guess this is where “invading Rome” comes in. Armed with what you’ve learned from “doing as the Romans”, you are in a better position to trigger change. You also pick up on how to go about it, say who you need to talk to effect change more easily. But before we all go on a changing spree, one other important thing for me is to choose your battles. Not everything is worth rallying change for. I am not religious but the serenity prayer* says it best: Grant me the serenity to accept the things I cannot change, the courage to change the things I can, and the wisdom to know the difference.

[* N/A when I’m driving.]

Back to an old new team

Last October, I rejoined a former team but this time as a test lead. Previously, I was a tester in this team but I got pulled out in Nov 2010 to lead another test team. That other project had come to an end, and the options that my manager had for me was to either go back or join QS (another division). I ended up going back. It was like joining a new team altogether though. Only 1 of the original set of testers I knew remained.

One of the first things I did was try to collect my bearings. I wanted to know where is what, how do I find this, and so on. It was a bit all over the place. My OC-ness kicked in and I ended up centralizing the available testing-related materials and tools, and deploying the structure to the team. I didn’t want any new guys feeling lost as I was, and I don’t think you should need to ask more than 1 person for stuff that should be readily accessible to you.

Next up, I worked on the training materials. Again, I remember having received a lot of references (some obsolete) and not knowing where to start. So I made a visual outline. In the course of doing so, I also identified needed training topics with no available references. I prepped a couple or so slides for some of the topics, and also revisited the older ones. Still a long way to go, but at least the ball is rolling. My teammate, Tin, has taken over the training area so that’s one thing off my back.

In one of our earlier test team meetings, Tin facilitated a rant session to identify potential areas for improvement. The thing with rant sessions though is they’ll only work if someone drives the initiatives for improvements, otherwise you’ll end up with just a list of rants. There were nice ideas, but there weren’t any plans on working on them. Those things won’t just happen. I asked for a copy and posted them in a tab in my excel task list. That was another thing the test team didn’t have prior, btw, a task list or a less forgettable way of tracking the stuff they were doing for the test team. So far, I’ve picked off some of the low-hanging fruits marking them off to indicate whether something was or is being done for them.

(I’m nearing the edge of the page, need to wrap up.) Feeling lost or frustrated has been the starting point for all these. There are some things that shouldn’t have to be as difficult as they are. There’ll always be something to complain about. But you either let it defeat you (in which case you’ll just keep complaining about it) or you actually do something about it. It doesn’t have to be so radical so as to change things overnight– baby steps are fine — as long as you’re heading towards something.

Be not afraid of going slowly; be only afraid of standing still.

[Notes, Feb 2012]

Wanting change is not enough

Occasionally, we come across folks who say they want change or who are ranting about how things are currently done. (Chances are, at one point or another, we’re one of those folks.) But then after some time, we get in touch with them and find out that nothing had changed even though it’s perfectly within their power (or their limits) to trigger the change. In asking why, we sometimes get to the sad conclusion that nothing changed because nothing was changed. They just shrugged things off, maybe, or hoped that things would somehow just get better. At best, if they had even bothered to note down, what they end up with is a growing list of problems where nothing gets crossed off.

That list of wants or rants won’t magically get resolved. Stating the problem is not enough to get it solved just as stating the goal is not enough to get it done. It’s a start. But there’s got to be a change in mindset from simply just saying “I want X!” to coming up with something like “I want X so here’s what we can do…” I think Antoine de Saint-Exupery said it best: A goal without a plan is just a wish. Of course, planning won’t suffice — there are still the harder parts of following through with the plan (personally, I go by plan-do-check-act). But unless someone drives the change, you’re pretty much stuck to just waiting for nothing to happen.