AKF Partners

Abbott, Keeven & Fisher PartnersPartners In Hyper Growth

Category » Book Reviews

The Phoenix Project – Book Review

After several friends recommended that I read the book The Phoenix Project, I at last downloaded it to my kindle and read it on one of my transcontinental flights. I really enjoyed it and thought it was both entertaining and enlightening which is difficult to accomplish. However, I don’t believe it goes far enough in describing how the most modern and efficient technology shops run. More about that later, first a recap.

The story line is that the fictional company, Parts Unlimited, is failing to keep up with competition and at risk of being split up and sold off. The root cause of the company’s issues are IT. We join the story after two IT executives are fired and the hero of our story, Bill, is asked to take over as the VP of IT Operations. He is introduced to his sensei, Erik, a tech / business / process genius, who leads Bill through the path to enlightenment by comparing IT Operations to a manufacturing plant. Through this journey the reader is introduced to concepts such as kanban, work-in-process (WIP), work centers, Theory of Constraints, Lean Startup, and the overarching concept of DevOps. In fact the book ends with most of the main characters at a party where Bill reflects “Maybe everyone attending this party is a form of DevOps, but I suspect it’s something much more than that. It’s Product Management, Development, IT Operations, and even Information Security all working together and supporting one another.”

I’m a fan of DevOps but to me the integration of tech ops and development is one small step for technology driven companies. In order to truly be nimble and effective, teams need to incorporate development, tech ops, product management, quality assurance, and any other function such as marketing or analytics that are needed to make the team autonomous. We’ve written about this concept several times The Agile Org, The Agile Org Solution, and The Agile Exec. We call these teams PODs and most importantly they need to be aligned to swim lanes in the architecture. By doing this, you essentially create mini-startups. These teams can make decisions themselves, deploy independently, and are responsible for their service from idea to production support.

I really enjoyed the book The Phoenix Project and I too highly recommend that you read it, especially if you are not familiar with the concepts mentioned above. As the authors are obviously talented writers and technologist, I would love to see them write another book that takes Parts Unlimited to the next level by creating autonomous teams. The authors hint at this concept when they state

“You’ve helped me see that IT is not merely a department. Instead, it’s pervasive, like electricity. It’s a skill, like being able to read or do math. Here at Parts Unlimited, we don’t have a centralized reading or math department—we expect everyone we hire to have some mastery of it. Understanding what technology can and can’t do has become a core competency that every part of this business must have. If any of my business managers are leading a team or a project without that skill, they will fail.”

Hopefully this is foreshadowing of another book to come.

Comments Off on The Phoenix Project – Book Review

Why We Write

For those of you who dream about writing a book and getting rich from all the royalties, please think again. That is unless you have the last manuscript from The Girl with the Dragon Tattoo series. The reason is that according to recent surveys, authors on average earn as little as $5K annually. True, some authors such as J.K. Rowling have sold over 400 million copies and make millions in royalties. But of the ~275K books published in the US each year, only 1,000 of them sell more than 50K and only 25,000 sell more than 5K. 93% of all books published sell less than 1K copies. The average royalty rate is around 8% of the actual sale price which is lower than the list price because of discounts to the distributor, etc. So, if an author sells 5K copies of their book, each for $20, their earnings are (5,000 x $20 x .08) = $8,000. Not bad but when you consider it takes hundreds of hours of work to write, illustrate, edit, and proof a book the ROI is pretty low.

So, why do authors write? Certainly there are personal reasons such as self satisfaction, name recognition, etc but I think authors, especially those who write several books, want to share their story/message. If you couldn’t tell from our blog, site, consultancy practice, books, etc we’re passionate about scaling. As technologist, we’ve felt the pain of struggling with scalability issues. We’ve had to explain to our business colleagues that customer facing features had to be delayed because we had to work on keeping the site up. We’ve felt the pain and over the years we’ve learned how to scale. It definitely wasn’t overnight and we made our share of mistakes but ultimately we were taught or figured out methods that work when scaling systems. We want everyone to know about these methods. Whether we get the chance to meet with your team in one of our engagements, you read our blog, or you buy the books we want people to know about these concepts.

Help us get the scalability message out by liking and sharing our books’ Facebook pages The Art of Scalability and Scalability Rules or their official websites theartofscalability.com & scalabilityrules.com.

This is why we write. We are passionate about scaling and want to share our knowledge with people. We hope you enjoy reading our writing and most of all we hope you get at least a couple good ideas on how to scale from it.

Comments Off on Why We Write

Enterprise Cloud Computing – Book Review

A topic of particular interest to us is cloud computing so I picked up a copy of Gautum Shroff’s Enterprise Cloud Computing: Technology, Architecture, Applications published in 2010 by Cambridge University Press. Overall I enjoyed the book and thought it covered some great topics but there were a few topics that I wanted the author to cover in more depth.

Enterprise Cloud Computing Book Cover

The publisher states that the book is “intended primarily for practicing software architects who need to assess the impact of such a transformation.” I would recommend this book for architects, engineers, and managers who are not currently well versed with cloud computing. For individuals who already possess a familiarity on these subject this will not be in depth enough nor will it have enough practical advice on when to consider the different applications.

Of minor issue to me is that this book spends a good deal of time upfront covering the evolution of the internet into a cloud computing platform. A bigger issue to me is that coverage of topics is done very well at an academic or theoretical level but doesn’t follow through enough on the practical side. For example, Shroff’s coverage of topics such as MapReduce in Chapter 11 are thorough in describing how the internal functionality but fall short on when, how, or why to actually implement them in an enterprise architecture. In this 13 page chapter, he unfortunately only gives one page to the practical application of batch processing using MapReduce. He revisits this topic in other chapters such as Chapter 16 “Enterprise analytics and search” and does an excellent job explaining how it works but his coverage of the when, how, or why this should be implemented is not given enough attention.

He picks up the practical advice in the final Chapter 18 “Roadmap for enterprise cloud computing”. Here he suggests several ways companies should consider using cloud and Dev 2.0 (Force.com and TCS InstantApps). I would like to have seen this practical side implemented throughout the book.

I really enjoyed Shroff”s coverage of the economics of cloud computing in Chapter 6. He addresses the issue by showing how he compares the in-house (collocation center) vs cloud. Readers can adopt his approach using their own numbers to produce a similar comparison.

The book does a great job covering the fundamentals of enterprise computing, including a technical introduction to enterprise architecture. It will of interest to programmers and software architects who are not yet familiar with these topics. It is suggested by the publisher that this book could serve as a reference for a graduate-level course in software architecture or software engineering, I agree.

1 comment

Book Review: The Lords of Strategy

OK, this isn’t a book review as much as it is a comparison of how the iterative and rapid “productization” of strategy closely parallels Agile methods of software development.  But first, here’s an overview of a particularly good book – Walter Kiechel’s The Lords of Strategy.   I flew through the book – not because I wanted it to end but because I couldn’t put it down.  It’s an incredible history of the people, organizations and ideas that developed the concept of corporate strategy and it’s full of incredible facts and observations.  Take for instance that the notion of strategy consulting as purveyed by the likes of BCG, Bain and McKinsey is only roughly 30 to 35 years old and that perhaps even more interestingly the notion that a company exists to create shareholder wealth is only about 30 years old.  The book does a great job of explaining not only the history of the ideas behind strategy consulting, sometimes told alongside the biography of their inventors, but how those ideas affected the industry for better and for worse.  Ultimately it describes how these ideas “quickened the pace of capitalism” though the reader is left with figuring out whether we are better or worse off for the change.

What struck me as particularly interesting in this book is the parallels one can draw between how corporate strategy (including the product and services surrounding it) developed and how Agile methods of solution development should work.  The germinating idea behind strategy was the identification of the “experience curve” by the Boston Consulting Group.  This curve identified through trend analysis that the longer and more experienced a company became, the lower its cost of producing a certain good or service.  This notion, though flawed (experience alone isn’t what drives cost), came quickly and was brought to market quickly by BCG.  In rapid fashion, the company built upon this to develop the growth-share matrix as its second “product” offering.  Both of these ideas together led to a grouping of offerings that suggested companies take on debt, reduce costs, differentiate themselves on price and expand shareholder value.  The success of BCG led to McKinsey joining the ranks of strategy consultants, Harvard Business School changing its curriculum (via Michael Porter who had now built his own strategy framework – the famous 5 Forces analysis) and created Bain and Company.

Key here is the evolutionary nature of strategy as a product.  In the very early phases, the offerings were quite frankly wrong.  We know now that the notion that companies differentiate themselves on price alone in every industry is flawed.  But the firms and institutions that supported strategy as a product and intellectual endeavor did not try to offer the absolute best solution – they attempted to bring an appropriate solution to the market and then modify it from there.  In effect, for the time, their solution was the minimum viable product.  Did their approach work?  Billions of dollars of consulting revenue and profits and billions in market value would argue it was an effective approach.

While these companies didn’t realize it at the time, they were in fact practicing agile development.  They didn’t know end user requirements – how could they?  The market wasn’t created yet.  They created a quick offering and iterated upon it, simultaneously changing the market demand and adapting to both the shifting demand and their growing understanding of what strategy needed to become.

Where else might agile methods apply?


Book Review – Web Operations

Web Operations: Keeping the Data On Time By John Allspaw and Jesse Robbins, is a collection of essays and interviews dealing specifically with web operations. The book’s stated goals are to explain the skills needed in web operations, demonstrate why it’s important to gather metrics, describe common approaches to database architectures, and define what to do after a problem occurs. I think they succeeded and would recommend this book to any technologist responsible for a highly available system. As one would expect, I enjoyed some essays more than others but overall found myself nodding my head in agreement with many of the authors.

The authors John Allspaw and Jesse Robbins, in addition to a long list of contributors such as Eric Ries, Paul Hammond, and Justin Huff, have terrific CV’s that demonstrate their first hand knowledge of what it takes to run large scale web operations. John is currently a Technical Advisor at Etsy and was formerly the Engineering Manager of Flickr Operations at Yahoo!. Jesse is the CEO & Co-founder of Opscode and worked at Amazon.com with a title of “Master of Disaster”.

Unlike other collection of essay books such as 97 Things Every Programmers Should Know, which I enjoyed but found disorganized (see my full review here) Web Operations is well organized starting from general overview discussions to specific and actionable examples. The first chapter is an overview of web operations from a career perspective and the book continues with chapters discussing such topics as continuous deployment, infrastructure as code, community involvment, dev and ops collaboration, relational databases, and noSQL databases.

Put this book on your reading list or download it to your Kindle/iPad to read on your next flight. Be prepared to bookmark or highlight many of the authors’ insights that you’ll want to remember and share with your team.

For people interested in more books that we recommend, check them out at our Amazon store.

Comments Off on Book Review – Web Operations

Technology Governance – Lessons from 13 Bankers

13 Bankers describes how our current banking system is broken. Equally broken is the governance of most high tech companies that don't have a technologist on their board of directors.

13 Bankers, by Johnson and Kwak, is an interesting but at times text-bookish read on the history, successes and failures of banks in the US from the time of the founding fathers to the recent mortgage induced meltdown.  The book makes a compelling point that effective bank regulation cannot happen while former bankers are so tightly tied to American politics (witness Paulson, Geithner and several other former bankers as recent Secretaries of the Treasury).  Given the size and influence of the remaining 6 large banks, the authors argue that the banks have effectively created an oligarchy.  The authors defend their position through recent events; even after one of the worst financial meltdowns of all time we have yet to reign in the level of risk taking of these modern goliaths.  Banker compensation is at a near all time high, high risk financial products continue to be developed with little or no oversight and the taxpayer has funded all of this with below market loans in the form of TARP.  In every other meltdown in US banking history, we have swung to tightly regulate and control the banks while in this one we simply loaned them money and went back to business as usual.  The authors implicitly argue that Jefferson’s (who was against a central bank for fear of it having too great an influence over government) worst fears have been realized.

The book is informative, and it got me to think about governance overall – especially over technology functions within companies.  Just as the existing board structures in coordination with the government seem to be ill equipped to properly govern and regulate modern banks, so too are too many product companies ill equipped to govern their technology efforts.   CEOs often do not have a deep technical background and while we’ve written that they do not necessarily need to be technical, we’ve also stated that they should ensure that they have the appropriate internal technical talent and outside technical governance.  I’m not talking about the tired old topic of internal IT governance here, though that is still important.   This is about ensuring that the governance of the company is correct and representative of shareholder interests.

Looking at the boards of most companies private and public companies, you will not find many successful technologists as directors.  These boards are likely to have former CEOs, CFOs and CMOs but precious few of them will have former CTOs and CIOs.  Given the level of spend within technology companies, what could be more important than ensuring that spending and focus is appropriate to the needs and the direction of the company?  Given that the product is what creates shareholder wealth, what could be more important than having someone with relevant technical product experience on the board of directors?

A lack of understanding of the risk of certain financial products (especially in the case of debt derivatives like CDOs) on the part of boards of directors and regulators is at least partially to blame for the most recent financial failures.   If former bankers sitting on these boards of directors can’t understand the firm’s financial products, how can a board devoid of technologists have a chance of understanding the ins and outs of developing the company’s products?

While clearly not of the magnitude of our current bank governance problem, it is at least a problem that should be solved as technology continues to play a larger role in each of our lives, our companies and our futures.

Comments Off on Technology Governance – Lessons from 13 Bankers

Book Review – The Big Short

Michael Lewis tells the story of how CDOs killed our financial markets.

The Big Short puts the cloudy mechanics underlying the real estate bubble into easily understood layperson’s terms.  Michael Lewis is perhaps one of the greatest story tellers of our generation, and his ability to describe complex situations simply while telling a human interest story in a novel like fashion is in my opinion unmatched.

The Big Short explains the world of CDOs and CDSs, while simultaneously telling the stories of how they came to be and how they contributed to both the creation and popping of the bubble.  Lewis also does a great job of explaining how both Moodys and Standard & Poors failed to properly protect investor interests.  The punchline:  Debt that would likely have a high default rate and therefore low ratings was  repackaged into new securities and given new, higher ratings.  The theory by bankers, analysts and rating agencies was that by bundling several states worth of mortgages into a single instrument, risk would go down because not all states would have high rates of default at the same time.

Lewis, and this book have taken a great deal of heat and criticism from articles he published in 2007.  His comments echoed those of Alan Greenspan, and are supported in a fashion by the efficient market hypothesis.    Lewis is cited as having been a huge supporter of derivatives as an efficient mechanism to redistribute risk.  But The Big Short isn’t a change in position, an attempt to argue that he didn’t make those statements or an acknowledgement that he was wrong.  It’s just a well told story, in typical Lewis fashion, of one of the worst financial events in recent memory.

Comments Off on Book Review – The Big Short

Rework – Book Review

I heard that the guys at 37signals were Tim Ferriss fans, and as a result I was a bit leery of their book ReWork.   I was surprised by how much I enjoyed it.  The book is full of folksy, practical wisdom for small companies and small group leadership.  Much of it is extensible to larger product teams.  I loved the book despite a few claims that are just not true in my mind.

I think there are three great themes throughout the book that make it a must read for executives, product managers, managers and engineers.  The first is that you can always do less.  We all simply try to build too much worthless crap into our products.  As a result costs go up, deadlines are missed, morale tanks and budgets are blown.  Striving to do less is a great idea when developing products.  Small, evolutionary changes beat the big bang in our experience as well.

The second great point is that one should grow profitably and try to avoid taking outside money.  Being the master of your own destiny and beholden to no one except your customer makes work so much more enjoyable than trying to please customers and shareholders.  Cash is king – just make money!  Be profitable.  Don’t measure yourself by employees – measure yourself by profits.

Their third point is the notion of work life balance.  Sleep is essential to creativity and productivity.  Burnout is the enemy of companies, culture and people.  The new world order includes working across geographies, from home, and from different hours that fit the needs of great employees.  I couldn’t agree more.

While I loved the book and could go on about some of their other good points, I believe it’s also important to address a few flaws.  The authors say that learning from mistakes is overrated and cite a HBS/HBR article indicating that successful entrepreneurs have a higher success rate on successive tries at new companies than entrepreneurs who have failed.  I don’t doubt this statistic, but as it applies to learning from failures it does not pass the nonspuriousness test; there are other potential and even more plausible explanations for this statistic.  Success begets success, attracts other people who are likely to be successful, attracts better funding and advice, etc.  Academic research shows that we do in fact learn from failures – as long as they are the “right type” of failures and as long as we process them correctly.  Whether you learn or not is an individual characteristic.  I doubt this is a Stanford vs. Harvard issue – we all know we can find information that backs our points if we look hard enough.  The point is that you can learn a lot from failure – both your failures and the failures of others.

I also do not believe that their wisdom in its totality is extensible to all businesses.  Generally this is true of any “wisdom” – but they would seem to believe that what makes them successful as a business will make everyone successful.  Quite honestly, they are successful at least partially because they are in a market segment that is underserved and simply unattractive to many other companies.  There’s nothing wrong with that – in fact it’s a great business opportunity and I would love to have their business.  But some companies need capital (especially hardware companies) and need larger numbers of employees to capitalize on market opportunities that might otherwise be taken by competitors.  Can these companies be even more successful by employing the 37signals approach?  I believe so.   But the competitive dynamics are different and the 37signals approach needs to be tweeked as a result.

Lastly, I simply do not agree with their view on workaholics.  The authors seem to claim that workaholics are intellectually lazy.  I haven’t found this to be true in all or even most cases.  Some of the smartest people I know work quite a bit and they aren’t intellectually lazy at all.  Some people (like me) who aren’t so smart use commitment to make up for their lack of IQ.  I do agree that we shouldn’t expect people to be workaholics, but to say that they are intellectually lazy seems a bit overboard to me.  No doubt that the authors have had bad experiences with people who are overly committed – or perhaps they simply haven’t seen people who work both hard and smart.

In summary – this is a great and easy book to read.


97 Things Every Programmer Should Know – Book Review

97 Things Every Programmer Should Know is the third O’Reilly’s 97 Things series.  Editor and contributor Kevlin Henney has done a nice job bringing together some insights from some of today’s most experienced and respected practioners. The book is a compilation of short essays ranging on topics as diverse as Bugs, Error Handling, Customers, Refactoring, and Expertise.

Having tossed my hat into the ring of debate of whether software development is a craft or an engineering discipline, I was thrilled to see essays such as Neal Ford’s “Testing Is the Engineering Rigor of Software Development” that states “Compared to ‘hard’ engineering, the software development world is at about the same place the bridge builders were when the common strategy was to build a bridge and then roll something heavy over it.”  Along this vein I was intrigued by how many times the authors used terms such as ‘simple’ or ‘beautiful’. Peter Sommerlad suggest that we treat our code like “a poem, an essay, a public blog…” while Linda Rising uses the phrase “…a beautiful piece of code this is.” In fact there is an entire collection of essays around the theme of “Simplicity”.  This brings up my one and only annoyance with the book, the organization of the essay’s by title. There is an index of the contributions by category but the actual essays are laid out in alphabetical order. I would have much preferred to read all of the essays on a particular theme together without having to flip through to find them.

The purpose of the short essay is not to answer all your questions or be a definitive guide to programming. Rather the purpose is to provide a starting point for a conversation. To this end, I think a practical way to use this book whether in academia or a development team would be to assign groups of essays to be read ahead of time to stimulate classroom or team meeting discussions.

To highlight a couple of my other favorite essays, I particularly enjoyed Marcus Baker’s whimsical treatment of convincing someone to install your software in “Install Me” and being a script junkie myself, I found myself nodding in agreement with Cay Horstmann’s “Step Back and Automate, Automate, Automate.” As a conversation starter, thought provoker, or small collection of wisdom’s, you will likely enjoy many of these essays yourself.


The 4 Hour Workweek – Stories from a Life Hack

I wish I had come up with the term “life hack”, but I didn’t.  I first heard it from my partner Mike Fisher who applied it to Tim Ferriss during our discussion of his book “The 4 Hour Work Week”.  Wikipedia indicates that “life hack” is a programmer’s term used to describe what we’ve sometimes called a “simple solution to a complex problem”.  I’ve never heard it used that way before, so in my world the credit will always go to my partner Fish and his definition.   A life hack, says Fish, is a person who takes shortcuts through life to achieve personal goals.

Don’t get me wrong, I’m not jumping on the “I hate Tim Ferriss” bandwagon simply because he is a seemingly overly self promoting, ego centric, self involved individual (fyi – I can’t stand those types of people).  In fact, I think his book has a number of well disguised great points in it.  I also admit that I suffer from a bit of book envy – his has been on the NY Times bestseller list for over a year and the best our book has done is to reach number 256 on the Amazon best seller list for a couple of hours (you should still buy it by the way – it’s calling you – you “need” it)

The first point that I love is that Cash is King, though Tim really doesn’t call it that.  Good job Tim for restating and obfuscating something taught (but ignored) in finance classes the world over.   Way to repackage an important lesson!  Unfortunately, Tim doesn’t seem to understand that if everyone simply goes for the high paying low work “cash today” jobs our last bastion of supremacy – the high tech startup community – would cease to exist.  Name one company that changed the world in terms of products or software that did so without having to sacrifice cash today for a huge shareholder reward tomorrow.  Sure, there are companies like 37 Signals that do an incredible job at balancing their business and personal lives but 37 Signals isn’t going a Microsoft in the’ 80s, an eBay in the ‘90s, or a Google, Facebook or Salesforce in the ‘00s.    It’s a great idea and it fits the needs of many people.  But if absolutely everyone takes the lower risk, high cash route our innovation and startup engines would crater.

I also love Ferriss’ notion of mini-vacations.  Even in the startup community these can be useful to try to keep employees from burning out and keep companies rejuvenated.  Finally, I like his notion of not allowing other people to control your time.  We absolutely all should be looking for simple solutions to complex problems (the Wikipedia definition of life hack) and looking to simplify our lives and eliminate time drains.

My primary concern with Ferriss’ book is the tone and manner of his approach.  At one point he describes his experience winning a kickboxing championship by finding a loophole in the rules that allow him to simply push an opponent out of the ring and win.  He claims that this action is neither immoral nor unethical.  True, they weren’t against the rules – in fact he studied the rules in order to know how to game the system.  In a game whose spirit it is to test skill, he used the rules against the more skilled player.  By “gaming” (note: not “cheating”) the weight system, he put himself at a comparative advantage.  Great – Tim knows how to screw the spirit of the game by using the rules to his advantage.  While I am a huge believer in cutting through bureaucratic red tape and in testing the rules and eliminating or fixing them when they don’t make sense, I would never suggest breaking the spirit of a relationship or system.  There’s an implied consent to abide by the spirit of engagements (such as tournaments or client relationships) regardless of what the “rules” say.   Breaking that spirit doesn’t make you smarter – it just makes you less honorable.  I’ll make a distinction between honor and ethics here.  Honor is abiding by the spirit of a relationship.  Just ask yourself – would you be comfortable doing business with someone like Ferriss, or would you be worried that he might test the limits and boundaries of your contract given his approach to kickboxing?

My next concern with Ferriss’ approach also has to do with spirit; the spirit and tone of his presentation.  He sounds like he is all about himself.  He comes across as a person who loves himself, believes he is a deific gift to mankind and in general reeks of the same self loving stench as some investment bankers (not all of them mind you – but some of the ones with whom I’ve dealt in the past).   As my partner and I have written time and time again – “Leadership Isn’t About You”.  It’s about the team.  If you preach selfishness, as Ferriss does in his book, you by definition can’t be selfless.  If you aren’t selfless in your leadership, you will sub-optimize your results.  This doesn’t mean you won’t be successful – it just means that you won’t reach the maximum potential.

I absolutely believe we should all look for more “life” in our work life balance.  Work from home, get more done in less time, look to bend the rules or eliminate those that don’t make sense, and understand that cash is king.  We should also hope, however, that there are still some enterprising people out there willing to sacrifice to make huge advances.  So too should we pray that there are leaders who understand that a great team led well can equal more than the sum of its individuals and that these leaders are willing to give selflessly in their role.  Finally, I hold out hope that not everyone will violate the spirit of engagements as Tim would seem to preach.  I believe it is this approach and mindset that is at least partially responsible for the corruption that we see in corporate America, the real estate and dot com bubbles and the failure of the banking industry.  Don’t be a life hack.  Work smarter, play more, get more done – but don’t be a blemish on the face of humanity.

Comments Off on The 4 Hour Workweek – Stories from a Life Hack