Big Things

At the Web 2.0 expo today, Tim O'Reilly (a keynote speaker) quoted a wonerful poem, written by Rainer Maria Rilke. I felt moved and wanted to share.

Click here to read it.

How many of our battles are big ones?

General Conference on iTunes Store

General Conference for the Church of Jesus Christ of Latter-day Saints is now available on the iTunes store. Click here to get it.

You need to have iTunes installed on your computer.

Tapping with a Sledge Hammer

Last week brought a most excellent event: pinewood derby.

Oh yes. Pinewood derby.

Pinewood derby is a cub scout event where dads cub scouts take a block of pine wood, four nails, and four plastic wheels and create a car. They then race the cars along a track against all of the other dads cub scouts. Dads Cub scouts look forward to this event all year long.

Talk about a rich environment for potential blog entries!

We got the car painted the night before (an improvement over past pinewood derbies) so we planned to wait to put the wheels on the car until the next day when I would "get home early."

Of course we had a late meeting the next day. I live almost an hour away from the office so I called Lani to let her know I would barely make it. We decided that she would bring Alex, the car pieces and a hammer to the event.

A hammer. Not a sledge hammer--a hammer! The axles for these things are tiny little pieces of metal. If you're not familiar with pinewood derby, there are tons of legal tricks you can employ to make your car faster: lubricate the axle, use a drill press to drill new holes closer to the edges, make one of the holes a little higher off the ground than the other three, carve out most of the body and add weight to the back, etc, etc, etc. But no tricks will compensate for bad wheels or bad axles. And in my hand were four tiny little nails and a gigantic hammer. Since we seemed to have no other choice, we lay the car on its side and prepared to insert the axles by pounding them into the soft wood.

A friend stopped us and held up a tiny little hammer. "Try this," she said with a smile.

Back in November I wrote about matching great systems with great people to increase effectiveness. The point, in the conext of this metaphor, was that if people aren't getting the job done, check that you've got the right tools before you blame the worker.

Unfortunately, we often try to do too much with tools and process. We use a sledgehammer for a small job.

In our shop, we have a process we use for accomplishing projects. Most feel the process is too cumbersome and slow. However, when faced with some kind of persistent problem the same people who complain about the burden of the current process want to add more steps or controls, making it even slower or bureaucratic feeling.

If you assume people have good intentions, you can often accomplish the same things through simple training. In our department, we have a number of requirements for software development projects:

  • Language must be Java or .NET.

  • Code coverage for unit tests must be a certain percentage.

  • All of the functional disciplines (like interaction design, development, QA, database, etc.) must be consulted on the plan.

  • Resources must be freed up and ready to go.


When we began implementing process in Church I.T. we had a tendency to put controls and process in place to make sure all of these things happened.

However, process shouldn't be used as a gate unless it's absolutely necessary. Rather, people should be trained to understand expectations and they will, more often than not, comply!

Why use a sledge hammer on a pinewood derby car when you can use a tiny little tapping hammer?

Assume people are well-intended and teach them what they need to do to be effective!

Grow Your Own CIO

In a post back in March, I posted that an effective executive recruitment strategy can be to grow people inside your organization.

Book Club: Mormon Scientist: The Life and Faith of Henry Eyring


Mormon Scientist: The Life and Faith of Henry Eyring is the latest book I'm reading. Henry Eyring was a pretty remarkable scientist, garnering many of the most distinguised prizes for scientific contribution, and was a faithful Latter-day Saint. He spent a great deal of energy convincing people that science and religion are fundamentally different pursuits and can therefore co-exist peacefully.


The book is written by his grandson, Henry J. Eyring, who takes an interesting approach to detailing Erying's life. Rather than proceeding through a chronology, Eyring divides the chapters by attributes he might have gained from his forefathers.


Here's a quote from the book:


"The lesson of Henry Eyring’s life is that simple people, people just like you and me, can change the world. We do it a little bit every day. And we have the potential to change the world much more, if we can better understand and use our unique gifts."



Need a CIO? Grow Your Own.

In this post over at CIO.COM, Susan Cramm makes the point that the average I.T. professional who feels he is ready to be a CIO isn't ready at all. She makes a call to CIOs to inform their people that they need to get more "business experience" and to develop "senior level relationships."

Her charge is noble, necessary and terribly difficult. Many I.T. professionals lack skills critical to being successful in a C-level role. To many I.T. professionals, a vertical career track requires technical depth and specialization. Consequently they spend a disproportionate amount of time developing technical skills and not enough time on skills that would help them get into and navigate within the boardroom.

Skills like:

Communication. My department works on hundreds of simultaneous projects. In addition, we operate hundreds of different products and services continually. It's critical that we keep our customers and our management aware of what is going on in the shop. I plead and beg our engineers and project/program managers to write very simple, understandable status reports. It is a constant struggle. A member of my office reviews (and in the past has typically re-written) every one of them. We have a hard time talking without jargon and acronyms.

Relationship Management. When I worked in computer games at Microsoft I often had to "check out the competition" and so played an awful lot of games for a couple of years. I remember telling my wife, Lani, about this great new game called Everquest where you could meet new people, develop friendships and have fun together, all in a virtual world. She said, "Gee Joel. It sounds almost as fun as real life." Hmmm. Sarcasm. The fact is that relationships are easier on line than in real life. If things aren't going well, you log out or you just "block" the other person. You don't have to co-exist in a meaningful way--the biggest source of conflict is deciding who gets the +4 magic, +4 intelligence mace you picked up off a monster your party just clobbered. I know I.T. guys who get along socially just fine in on line games and who struggle to go out to lunch periodically with their customers. "I don't really have anything to talk about with them." "I'm too busy."

Business Acumen. Our shop is going through some growing pains this year as one of our focuses is on writing effective business objectives for a project. It's hard. Engineers think about solving problems very naturally. We don't always think about cost justification. Why does it make business sense to upgrade your application server? "Well, the cache is filling up and we're queue'ing requests. That's why." Upgrading may make all the sense in the world to a technologist who understands what's under the hood, but a business person might decide that the business consequences of not upgrading are acceptable in light of the cost of upgrade. This is particularly relevant at the Church where we have to take extra precautions to keep costs low. Many basic business skills like cost-benefit analysis, contract negotiation, and others are not even taught in computer science or information technology programs, and when those skills are taught, they atrophy in I.T. people who are not being required to use them.

In our department, we're taking steps to help our professionals develop these skills. I'll talk about those steps in the next post.