There is simply no place for a big ego in any position within any company. While it is true that there is a high degree of correlation between passionate inspirational leaders and people who have a need to talk about how great, intelligent or successful they are, we would argue that it is also true that those people would be that much more successful if they kept their need for publicity or public recognition to themselves. The concept isn’t new and is embodied in Jim Collins’ concept of Level 5 Leadership.

CTOs who need to talk about being the “smartest person in the room” and CEOs who say “I’m right more often than I’m wrong” simply have no place in a high performing team. Such statements alienate the rest of a team and very often will push the very highest performing individuals – those actually getting stuff done – out of the team and out of the company. These actions and statements run counter to building the best of teams and over time will serve to destroy shareholder value. The best leaders give of themselves selflessly in an ethical pursuit of creating shareholder value. The right way to approach your job as a leader and a manager is to figure out how to get the most out of your team in order to maximize shareholder wealth. You are really only a critical portion of that long term wealth creation cycle if your actions evolve around being a leader of the team rather than an individual. Take some time and evaluate yourself and your statements through the course of a week. Identify how many times you reference yourself or your accomplishments during the course of your daily discussions. If you find that you are doing it often, take some time to step back and redirect your thoughts and your statements to things that are more team rather than self oriented.

It is not easy to make this type of change. There are people all around us who appear to be rewarded for being egoists and narcissists and it is easy to come to the conclusion that humility is a character trait embodied by the unsuccessful business person. But all you need to do is reflect on your career and identify the boss to whom you had the greatest loyalty and for whom you would do nearly anything; that boss most likely put the shareholders first and the team always. Be the type of person who thinks first about how to create shareholder value rather than personal value and you will succeed!

We mentioned in a previous post, Business Acumen and the CIO/CTO, that we would provide a list of our recommended reading material.  We’ve decided to break our list into three sections, business, technology, and just for fun we’ve thrown in some fiction.  This isn’t a complete list, so don’t expect to read these books and be a technology or business genius.  This is just a starter list that we feel every CIO/CTO should have read.  There are plenty more great business, technology, and fiction books that we all should keep reading.  Let us know some of your favorites.

Technology
The Mythical Man Month - Frederick Brooks
Design Patterns: Elements of Reusable Object-Oriented Software - Gamma et al
Patterns of Enterprise Application Architecture - Martin Fowler
The C Programming Language - Kernighan & Ritchie
The C++ Programming Language - Bjarne Stoustrup
The Art of Computer Programming - Donald Knuth
Data Structures and Algorithms - Aho, Ullman, Hopcroft
Inspired: How to Create Product Customers Love – Marty Cagan
The Singularity Is Near - Ray Kurzweil
On Intelligence - Jeff Hawkins & Sandra Blakeslee 
A New Kind of Science - Stephen Wolfram

Business
Purple Cow, The Dip, etc - Seth Godin
Good to Great, Built to Last - James Collins
Crossing the Chasm - Geoffrey Moore
The Art of War - Sun Tzu
The Prince - Machiavelli
Malcom Gladwell - Blink and The Tipping Point
Black Swan - Nassim Nicholas Taleb
The Innovator’s Dilemma, The Innovator’s Solution - Clayton Christensen
Competitve Strategy - Michael Porter

Fiction
Works by William Gibson i.e. Neuromancer, Spook country, etc
Works by Neal Stephenson i.e.  Quicksilver, Cryptonomicon, etc

We work with many early stage startups in which the early and critical product phases including discovery, prioritization, specification and the later equally important product phases including product validation (am I getting the results I expected?) are either not performed well or sometimes not performed at all.

Sometimes the company feels that it doesn’t have the money necessary to fund a team of product professionals and attempts to limp along using the entrepreneur’s early vision with the help of some intrepid engineers. Sometimes the company feels that product professionals simply aren’t needed, even going so far as to cite agile methods as the reason (see later posts to explain why agile doesn’t eliminate the product manager position). Oftentimes the company just hasn’t had the opportunity to realize the benefit that a real product professional can offer to their product development lifecycle.

For those of you hoping for a quick and simple answer to the question above, we’ll give it to you right now: Yes – you need product management and you need to staff that team with product management professionals. Marty Cagan does a great job of describing what a product manager’s responsibility is here.

We are of the belief that building the right product is every bit as important as building the product the right way. The former is accomplished by having a disciplined product selection process that is informed by a professional product management team which in turn analyzes the customer needs, competitive landscape and strategic benefits of different options within the product portfolio. The latter (building it the right way) is an engineering responsibility informed but ideally not limited by the specifications that an professional product management team creates.

Equally important is the need for a product discovery phase. This phase is often ignored within many product development lifecycles and includes determining whether there is a product that can succeed within your target market as well as exploration on the topic of what that product might need to do to properly capitalize on the market opportunity.

Ensuring consistent vision through a single organizational owner of the product is yet another benefit to having a professional product management group early. Continuity helps ensure that lessons are both recognized and hopefully retained through organizational muscle memory. Evaluation of product results as measured within the business metrics creates a continuous process improvement feedback loop that helps grow those organizational muscles over time.

Finally, creating a sufficient backlog of product specs within an organization separate from engineering helps to ensure that engineers stay focused on creating shareholder value through implementation rather than specification.

So yes, you should have a product organization and yes they are a team separate from your engineering team. Build one now and help your company grow!

Almost everyone explicitly understands that physical activities such as golf or running or weight lifting require lots of repetitious practice in order to get better but most people don’t recognize that mental activities and business processes require the same practice.  We all studied in school to learn languages, algorithms, etc. but most of us either swore off studying upon graduation or forgot that study and practice are prerequisites to proficiency and excellence.  From the engineer to the manager to the CTO, everyone has skills and processes that need to be practiced and critiqued in order to improve.

As professionals no longer under the guidance of professors, we need to take responsibility for our own continuing education.  If you think that coding new features will provide you with enough stimuli for expanding your skill set, you should reexamine that idea by looking back over the past twelve months to see what you have learned that makes you a better engineer today.  It is most likely that if you have relied solely on assigned features you have fallen into the trap of using what you know to code them rather than stretching to learn new designs, patterns, or algorithms.  The wondrous thing about programming is that there are many ways to solve the same problem, some faster than others, some more eloquent than others.  We recommend a couple practices to help the engineers continue to learn and perfect their skills but these can really be expanded to other groups such as QA.  The theme behind these recommendations is leverage the shared knowledge of the entire organization to learn from each other.  This is one reason the whole is greater than the sum of the parts.   

Start your engineering all hands meeting with someone presenting a creative solution to a problem.  Have the engineering managers or architects decide whose solutions qualify for being interesting enough to share with the group or leave it to the individual engineers to decide.  Another idea for ensuring that you and other engineers continue to learn is practice code reviews.  Engineers sometimes get persnickety about someone reading over their code but this is a great way for the reviewer to learn new techniques as well as the engineer.  A final suggestion is to establish a Joint Application Design process where members of the operations team join the engineers and architects in the design process of the feature.  This inclusion of different perspectives will help broaden all participants understanding of technology. 

In terms of practicing processes this is similar to practicing skills.  If you never exercise the process or you do so in a halfhearted manner, you will never be good at it and when the time comes that you need that process to work perfectly it will assuredly not.  Some of the processes that get skipped too often are failovers and disaster recoveries.  If you don’t practice failing over when the failure occurs that requires a failover the process will not work.  It will either take way longer than you thought, result in unexpected outcomes, or possibly fail to work at all.  Obviously you must do these without impacting the production site but it is possible to exercise the failover without bringing down production. 

Remember what Sun Tzu said in the Art of War:  “The more you sweat in peace, the less you bleed in war.” 

Image provided by Mike Kline

As we’ve discussed before in articles like Be A Leader!, the primary job of a CTO is to help the executive team maximize shareholder value.  Notice our choice of verb in the last sentence, “maximize”.  It is a much stronger word than what an average performing company would select – that word typically being “create”.  Maximizing shareholder value is the goal of a high performing team – a team which desires to say that “no other team in our position could provide the type of shareholder return that we do”.

The CTO however cannot maximize shareholder value and potentially can’t even prove that he or she is creating shareholder value without a set of aggressive goals along with the metrics and measurements that help define success or failure enroute to achieving those goals. 

We prefer to group our goals thematically, making it easier to determine how the goals impact the maximization of shareholder value.  Our themes include the reduction of cost, availability, the efficiency of engineering spend, the effectiveness of our product selection process, quality, and time to market.

Cost
No list of aggressive goals is complete without finding a set of goals to minimize the cost of operating a SaaS site.  In our experience, the best cost metrics are those normalized by transaction (cost per transaction) or normalized by cost of transaction type (cost per checkout, cost per signup, etc).  The associated goal is to reduce the cost by some relative value over time or to reduce the cost to an absolute value thereby increasing profit and shareholder returns.

Availability
No SaaS site can realistically operate in this day and age without considering the impact of availability on revenue.  Our desire here is to identify the lost opportunity (in most cases lost revenue) associated with outages rather than just the amount of downtime a site has.  While measuring absolute downtime is valuable and should be tracked if possible, the measurement of revenue loss as a percentage calculation is more easily associated with shareholder value maximization (less revenue loss the better) and further takes into consideration that most sites don’t produce as much revenue in the middle of the night as they do during the middle of the day.

Engineering Efficiency and Productivity
You can’t be maximizing shareholder value if you aren’t measuring and improving your engineering team.  These measurements are arguably difficult, but we try to break them into two component parts: 

1) Efficiency - How many engineering days are you getting out of the theoretical maximum?  This is a measurement of how many engineering days you lose due to environment issues, training problems, tool issues, etc.  Most organizations that don’t measure this are surprised that their engineers spend well over 33% of their time on things other than designing systems and writing code.

2) Productivity - How much do you produce per engineering day? This one is tougher and there are lots of metrics out there from which you can select, KLOC, stories, function points, etc.  All of them have issues, but that’s no excuse not to select the best for you and measure how well you are doing.

Product Efficacy
Simply put, this is a measure of how your product choices are performing.  You undoubtedly have more ideas than you can implement in any given year.  Are you choosing the right things?  Are you hitting your key metrics such as increasing revenue, decreasing drop outs, or increasing signups?

Time to Market
Assuming that you are building the right things, are you getting them out to the market in time to create barriers to entry and/or switching costs?  Are you faster or slower than your competitors?

Quality
How defect dense is your product?  Are you fixing the problems in engineering and product management that lead to bugs in production?  Are you making the right time, cost and quality tradeoffs?  How many defects do you introduce per new release, line of code or story?

You may have several other key metrics that you use and which you find valuable and we’d love to hear about them.  What you cannot do, at least without significantly damaging shareholder value, is ignore the need for improvement.  You simply cannot improve your team’s performance without a core set of metrics against which you measure absolute and relative performance.  And if you are not measuring your performance you simply cannot increase and ideally maximize shareholder value.