How to Cheat the Iron Triangle With Tony Schwartz

Jun 15, 2013 | Updated Aug 15, 2013

There is an old saw that every software engineer eventually stubs a toe on:

"You can get it done on time, you can get the features you want, or you can get it at the price you planned on paying, but you can't achieve all three simultaneously."

In my personal experience every technology project and startup is about beating this iron triangle of practical constraints. It's a truism that basically boils down to "something has to give if you want to get something done."

I believe the iron triangle applies to almost every human endeavor. From throwing a party to keeping a marriage alive for 28 years, no plan survives it's first encounter with reality. The only real question is which corner of the iron triangle am I going to compromise on? Am I going to give up the features that make my project special? Am I going to stick to my budget? Am I going to accept all the meandering delays that come with getting it right? (If I'm not doing well I occasionally have to give up on two corners of the iron triangle!)

Blizzard Entertainment, a gaming studio famous for producing massively popular games that millions play and actually pay for, is also famous for sacrificing the time corner of the iron triangle. Blizzard never knows when one of its games will ship but when these games are finally in the hands of impatient gamers they are generally epic winners generating billions of dollars. Today Blizzard is hurting and losing millions of subscribers as its current crop of games age ungracefully. True to form Blizzard has already announced a delay in the schedule of its next big franchise Titan. The iron triangle is putting Blizzard at grave risk: By the time Titan is out (2016?) will any gamers still be waiting to play it?

Facebook, as illustrated in the movie The Social Network, put off generating revenue as long as it could. Instead Mark Zuckerberg focused on building a base of a billion users. He ignored the cost corner of the iron triangle to focus on the other: Features and speed of execution. That's why Facebook's engineering motto is "Move fast and break things." It worked! But now investors are worried that the cost corner of the iron triangle will sink Facebook unless the mobile ad dollars start rolling in.

Microsoft has a chronic problem with feature gaps in it's Windows operating systems. Somehow, with all the thought, user testing, money, and time invested in Windows 8 they forgot the Start Button. But that's really the tip of Microsoft's problems with the iron triangle. Unlike Apple and Google who tend to solve a user's problems deeply Microsoft only goes so far, probably to stay on schedule or on budget, and then leaves a mess of edge cases and compatibility problems. Microsoft likes to pretend that the feature gaps are a product of open systems but they are not cheating the iron triangle with that excuse--just their users.

If you can't cheat the Iron Triangle, how do you live with it?

Tony Schwartz has the answer and last Thursday he came to visit HuffPost to help us figure it out. Tony is a guy full of energy and runs a consulting company called the Energy Project. Tony has the passion of a man who has solved a critical problem and wants to share that solution with the rest of the world.

Now, if you've gotten to this point in my blog post you might be thinking, "Oh, I get it, this is a sponsored blog post! One of those 'native advertising' things that got The Atlantic in trouble and Buzzfeed does so well."

Brothers and sisters I share your cynicism. I know from humbling years of bitter experience that you can't cheat the cruel iron triangle anymore than you can create perpetual motion, turn back time, or unsend poorly written emails. However Tony's answer is not a quick fix. It's a new way of thinking about the problem of constraints and reminds me of a completely different solution to the iron triangle that we in technology land have been using for years to tame all three corners: To be on time, on budget, and with all the right features through "managed balance."

Tony's ideas boil down to three simple principles:

  • Manage energy, not time.
  • Be aware of where you are and choose to be there.
  • Remember that pausing to renew isn't optional.

In software development, we have a system called Agile, that boils down in same way:

  • Manage effort not timing.
  • Meet with your team members every day and take each other's temperature.
  • Work in fixed cycles with a time for reflection and learning at the end of each iteration

Both Tony and Agile will tell you to sprint. To get off the endless treadmill of slogging through work while shackled to our personal iron triangles. To stop trying to squeeze more hours into an already over scheduled work day.

Sprinting, in both Tony's and Agile's terms, is being focused 100 percent on what you are doing to get it done while setting limits so that you don't work passed what is healthy and optimal. As a young man I used to "burn the midnight oil" and take pride in multitasking and sleeping as little as possible. But I soon realized that coding while tired lead to more bugs than bugfixes, that multitasking means every tasks takes longer, and that sleep isn't optional.

A sprint has a clear beginning and a clear end. A sprint contains a prioritized list of tasks or a measurable goal. When a sprint is over you stop to rest and reflect on success or failure and take the time to plan the next sprint. In Agile we software developers call the measurable goals "story points" and the rest period a "retrospective." Tony, who started out in life as a journalist and writer has his own personal sprint technique that he uses to write his books alternating periods of intense productivity with family time and exercise.


The best part about Tony's Energy Project is that he is preaching these "human friendly" solutions to corporations and governments. It turns out that treating your employees like machines and focusing on what Tony calls "the un-renewable resource of time instead of the renewable resource of energy" is bad for the bottom line. I know quite a few Agile coaches who would agree.

Years ago I was the CTO for an ad serving startup. The day came to release our new, updated ad server to our customers. We stayed up almost 48 hours debugging it. The long we worked, the more errors we encountered. The only reason we succeeded was that one engineer, gave up, went home, and got some sleep. When he returned to find the rest of us half dead watching the ad server fail he shooed us out of the way and fixed the bugs quickly. But ultimately we didn't learn from that lesson and the company failed. Tony Schwartz can easily tell you why.