Crossing paths with Ron Shaick

Today, I’m just writing a story that I like to tell for fun and to say farewell, nice job to Ron Shaick.

In 1980, my dad brought an Apple II+ home (48K of memory and a single 5 1/4 inch floppy disk drive) to do some spreadsheet work using VisiCalc (Dan Bricklin‘s concept), Excel’s great, great grandfather.  I was 16 at the time, and this simple introduction was all that I need to find my passion in life.  I loved to play games on the computer and my parents insisted that I balance my computer time with something  productive.  So I learned how to program the Apple in Pascal – a few game of course, something about dropping depth charges from a surface ship to sink submarines in a 48×32 graphics display.

In 1982, I was graduating high school and I had been accepted to the University of San Francisco; I was going to study mathematics and get very far away from home.  I also always wanted to buy a motorcycle and was never allowed – probably related to my uncle loosing a leg in a motorcycle accident a few years earlier, or maybe my parents where just plain smarter than I was.  In any case, I asked for permission again and again the answer was “no, too dangerous”.  But this time, I was 18 and free.  Right?  Since I had earned money of my own, I proceeded to buy a brand spanking new Honda 400E low rider.  Very sweet.  My parents did not like that move at all and they decided that they weren’t going to pay for my reckless California escape plan.  Oops, and there was no plan B as all my friends sailed off to college.

I found a job baking croissants for Au Bon Pain at Logan airport, starting at 4:30 AM.  It was ok, even fun, riding my motorcycle to the airport early in the morning until about October.  Wearing a snow suit in November was a bit of a bummer.  I baked thousands of croissants and delivered product to 11 carts spread throughout airport terminals.  The cart person would sign a delivery receipt and at the end of their shift, they would inventory their cart, count their money and bring their receipts back to the office.  The office manager would reconcile inventory, cash and receipts by hand – a good amount of work, recounts, etc.  I saw an opportunity to write some software – yes, Apple II+.  I showed the software to my office manager, who liked it.  She introduced me to Ron Shaick – the CEO of Au Bon Pain.  Ron offered to buy the software for $1500 and even better, he wanted me to write software for their 5 stores.  Let me see, work in an office during the warm portion of the day for $10/hour or continue that 4:30 AM motorcycle thing to earn $2.50/hour baking croissants.  I shared an office with Ron in a 2500 square foot office space, writing accounting and inventory control software in Basic on an IBM System 23 as Au Bon Pain expanded their store footprint – Harvard Square, Fanueil Hall, The Burlington Mall, the Airport and Copley Square were their first store locations.

In the meantime, I did decide to get a bit more serious about going to college – but I was still a thick headed, motorcycle riding, financially strapped independent.  So, I worked hard to get into the University of Massachusetts at Amherst in February of 1983.  At the time, Ron was driving hard to build the Au Bon Pain’s empire – many stores were opening and he built a new factory, corporate office in the old navy yard in Boston.  So, I had plenty left on my plate.  Ron asked me to continue writing while in school, returning to Boston monthly to provide update and discuss new stuff – no high speed Internet in 1983.  Again, a great deal for a college kid paying $2300/semester for school.  This continued on for a few years – Au Bon Pain opened many, many stores throughout the US they needed more than a part-time college kid.

A few years ago, I searched for Ron and found that he was CEO of Panera Bread.  Ron is a winner and a great CEO; He was smart in 1983, he worked very hard and he succeeded over and over again.  It was a good experience to work with Ron, I learned many things.  I probably should have stayed at Au Bon Pain rather than going to college.  A few years ago, I bought some Panera stock and I keep fairly close tabs on the company.  Earlier this year, Ron announced that he will retire in May.  Wow, what a run!

Freedom is not free

Yesterday was tax day, I filed in early February so instead of scrambling to finish up my taxes, my thoughts wandered towards how expensive it is to run our country and what we spend money on.  A hop, skip and jump later I was thinking about the old saying “Freedom is not free”.  But this isn’t a tax rant, sadly we’re actively fighting two wars right this second.  There are incredibly brave American moms, dads, daughters and sons risking everything, willing to give anything.  Wearing my parent hat, I can not imagine how this happens – I simply can’t get my head around it – full stop.

Nary a word in the press these days (go look right now on CNN.com’s home page, 200 links and nothing about either war) and most Americans here at home lead a normal day-to-day life (Yesterday, I started my day with a celebratory tweet about free coffee at Starbuck, Wahoo!) – probably without much thought about our friends and family in harms way.  There are generations of people, many millions, that have similarly given to help us live in a great global society.

Freedom is certainly not free.  There are plenty of ways, easy ways, to reach out and help or simply say thank you.

Getting Things Done

Cover of The 7 Habits of Highly Effective People

My wife finally convinced me that “Java Thread Programming” was inappropriate beach-time reading.  I doubt that business books is exactly what she had in mind, but over the years I’ve managed to fill a good sized bookshelf dedicated to many of the classics, “Swim with Sharks Without Being Eaten Alive”, “The Art of the Deal”, “Hard Drive”, “Only the Paranoid Survive”, “From Worst to First”, “Getting to Yes” and of course, Steven Covey’s “Seven Habits of Highly Effective People” and “Principal Centered Leadership”.  When they all started sounding too familiar, I moved onto “Playing Poker Like the Pros”.

Recently, I read “Getting Things Done” by David Allen to see what all the hoopla was about.  Again, much of it seemed like more productivity pundit preaching only this time with a bit of modern day infomercial style.  In a nutshell here is the GTD “system”:

1. Write everything down in a trusted place that fits within your personal style
2. Organize your inbox:
- Eliminate things that aren’t yours or are not needed right now
- Convert to actionable item or project
3. Do your stuff within the context of any given moment, consistent with your time and energy
4. Iterate and re-factor faithfully
5. Periodically, review with various levels of granularity the vertical projects, and horizontal focus, strategy.

I suspect most of this book’s appeal is based on the bottom up approach to productivity, where as most others philosophize about top down goal driven performance and don’t offer much practical guidance.  GTD is also fairly light about the key step – do your stuff within the context – which got me thinking about how this compares to Steven Covey’s disciplines.

Covey’s book presents a very compatible, illustrative guiding framework for creating a balanced decision context when contemplating what things you’re going to do.  Covey contends that we all have natural needs that must be fulfilled in order to lead balanced, happy and healthy lives.  The four broad areas of human need are the physical (the need to live), the social (the need to love – no not tweet), the mental (the need to learn), and the spiritual (the need to leave a legacy).  When all of a person’s needs get fulfilled in proper balance, that person experiences a “Fire Within” that drives him forward, or as Allen writes, you’re operating in the zone.

Covey also provides GTD compatible guidance on how to select projects that are consistent with your time and energy. Covey proposes that all activities can be classified into four basic categories or “quadrants” based on two measurements: Urgency and Importance.  The following matrix illustrates how to categorize projects or tasks based on these two criteria.  Quadrant II should remain a person’s primary focus when planning and Covey states that people frequently ignore Quadrant II (“fire prevention”) in favor of Quadrant I (“putting out fires”) or, worse yet, the trivial activities of Quadrants III and IV.

	Urgent	Not Urgent
Important	Quadrant I ➢ Crises ➢ Pressing problems ➢ Deadline-driven projects, meetings, preparations	Quadrant II ➢ Preparation ➢ Prevention ➢ Value Classification ➢ Planning ➢ Relationship building ➢ Needed relation ➢ Empowerment
Not Important	Quadrant III ➢ Needless interrupts ➢ Unnecessary reports ➢ Unimportant meetings, phone calls, mail ➢ Other people’s minor issues	Quadrant IV ➢ Trivia, busywork ➢ Some phone calls ➢ Time wasters ➢ “Escape” activities ➢ Irrelevant mail ➢ Excessive TV

Relationship building is a key Quadrant II activity. An important concept introduced by the Quadrant II focus is that of the role.  In relationships, each individual serves in a role of some sort.  Examples include: parent, employee, employer, club member, etc.  The concept of the role offers a valuable grouping and planning tool when determining what GTD projects and tasks to perform over a given period of time.

Finally, when Covey’s top down meets Allen’s bottom up, there are a lot of practical techniques for integrating both productivity systems.  For example, you could color-code or tag your GTD stuff with Covey based quadrants and roles.  Neither quadrants nor roles are part of Allen’s system, but integrating these two systems can help further organize your stuff, clarify context and help keep important/non-urgent as well as important/urgent tasks on track and your various life roles in balance.

Product Management is Really Business Operations

Again from the interview trail, I find myself talking about the importance of Product Management – especially when talking with troubled businesses or companies struggling to scale beyond the $10M stage.  Most of these companies believe they have technology challenges but I quickly realize that they suffer from under investing in real product management.  I firmly believe that if product management is flowing through, unchecked, to technology then all types of bad behavior typically evolves.  Product Management is one of the most important disciplines in a technology company, certainly a top priority for both startup and scale.

I’ve seen quiet a few different implementations depending on company goals, size and corporate culture.  Some worked really, really well but I suspect would fail miserably in different environments and different economic climates.  Most startup technology companies fail to separate this discipline to create autonomy and fail to hire a senior, experienced leader that can guide difficult decisions.  Perhaps the most disastrous that I’ve seen exist when folks are avoiding real product management behind the mantra of following an agile discipline – they are not mutually exclusive at all.  In fact, I believe that agile engineering is highly dependent on real product management.

One of the best was at Third Screen Media, after being acquired by Advertising.com (AOL/Time Warner).  The model was really based on a role better described as focused on business operations rather than classic product management.  Oh sure, we did many of the low level product management tasks.  We listened to customers, CEO, founders, marketing, sales, services and engineering.  We built feature trackers, road maps, requirement documents, etc… But the prioritizing context for many product management deliverables was primarily OIBDA (Operating Income Before Depreciation and Amortization).  We held product management responsible for regular operation’s financial performance, specifically profitability in continuing business activities.  In other words, Product Management was the company’s arbitrator of all fantastic, must have ideas, visionary and advanced technology marvels – but, we needed to understand how each would earn us profits.

Several unique and valuable results emerged from this model.  First, continuous feature tracking and road map work was essential to documenting that we were listening, thinking and deciding.  Not just favoring the squeaky wheel, five hundred pound gorilla or chasing the deal.  This helped us keep track of tons of great ideas, interests and helped us understand opportunity cost and risk.  By maintaining a context, we could quickly sort new ideas into our thinking and almost immediately reflect back a position.  The discipline was instrumental in keeping existing customers happy because we became consistent, stable and reliable.  Customers and partners appreciated the discipline because they could make important business decisions based on reliable information rather than waiting for vapor to materialize – even in the cases that they were not going to get what they wanted, when they wanted it.

But that was just professional Product Management done well.  Our guys were really managing business profitability – because most products don’t make money by themselves.  You have to sell products, maintain products, release enhancements, supply services, operate infrastructure, patch bugs, etc…  So, in the end, did we make money?  Did we build the right features?  Does it work well?  How many customers use it?  Do they use it the way we designed it to be used? Do we invest more to enhancing it, and if so, how much, when?  What were the goals?  And maybe just as important should we kill something and stop investing?

And while some may think that this feels like big company stuff, it wasn’t – we were still a relatively small operating unit at AOL, similar to a venture backed startup.  I’ll even argue that this discipline in a young firm will starve off one of the classic startup failings – lack of focus.  In other words, if you can’t describe, quantify and measure in the marketplace then you’re not ready to invest in the feature.

Big surprise – if you’re building a profitable technology product company then you’ll need to invest heavily in product management.  It is crucial to a focused agile technology discipline.