The art of building software: November 2010

Monday, November 29, 2010

The Chief Technology Officer of a Software Startup

During early phases of a software startup, you don’t want to be management top‐heavy, yet it’s important to bring on senior people for continuity as you scale the organization up because these people can and should set the culture for the company going forward.  Once set, cultures are harder to change.  At the beginning, you need “player / coaches”; that is, people who can be an individual contributor, manager, and leader. The CTO in such a company should initially multirole as needed the roles of chief architect, lead programmer, and VP of Engineering, eventually replacing these with full time positions at the right time.

It’s important for the CTO to select the right technology platforms and tools early on in a startup, as well as play a key role in hiring the team and setting up the team culture, development infrastructure and development processes that can scale.  To be successful in doing that, the CTO absolutely must be a visionary technologist and quality coder with the ability to learn new technologies as needed.

A common view of the CTO role is that they do not need to have strong technical skills.  John Wren Medcof shows this well in this picture on the right from his web site.  I disagree with this model, and think that a CTO needs to excel in all these domains.

While the CTO is responsible for the technology, the continuous product and project management decisions of how to balance milestones, resources, and features as development progresses must be a cross functional team decision. No one person has all the knowledge to do this. In larger organizations, you form a cross‐functional product team to balance the three factors (time / features / resources). However, in early startup stages, the executive team may need to actively multirole this until sufficient staff is in place to offload this burden. I use the word “burden” because it takes some investment of time in order to make the best call to balance these factors. 

If the executive team is also playing the role of the cross‐functional product team, the executive team meeting should be kept completely separate from the cross‐functional team meeting. The two meetings often have different people leading them as well. Usually a CTO or product manager leads the product team, but that doesn’t have to be the case.

The CTO should know when it’s time to hire people, and what kind of skill sets are needed. When the size of the engineering team hits a certain point – perhaps around 5 people and still growing, another layer of management may be introduced – this typically reports into the CTO but this is not required. The next manager brought in should either be at the Director or VP level, and that person may need to be a player / coach until the team grows to a size where the manager can’t simultaneously write code and manage.  As the team grows larger, additional layers of management should be brought in.  There are "phase changes" of sorts that an engineering organization (and the company as a whole) goes through when the total size hits certain ranges.  A CTO should be prepared to  help the company through these transitions.

So to summarize, the CTO may well start off as a strong individual contributor, but that function should gradually be reduced as the team grows in size. With that said, in order to maintain his or her edge and to retain “street credibility”, I believe a CTO must continue to develop and write code, as well as facilitate the architecture, and mentor others on the engineering team.

Most of the CxO’s on the executive team must play both an internal‐facing leadership role, and an external‐facing role facilitating investment and sales. The CTO is no exception. Initially as the company is getting going, probably more emphasis should be placed on the internal role. As the company grows, the CTO should transition to a having a larger external impact, through multiple channels. The CTO is often brought along as a “big gun” for important sales, in order to talk tech with the customer’s tech people. The CTO is usually part of the investor pitch team as well, as investors need to know that the company has what it takes to deliver the goods. In addition, the CTO should develop an external reputation for technical excellence and thought leadership, in the industry and his CTO peers in other industries. This is accomplished through several mechanisms such as blogging, articles and press releases, and talking at industry events.

I’ll close by saying that a major challenge of being a top CTO, is maintaining that technical edge that allows you to be a “player” in the player / coach model, yet spend enough time on the external facing role and continue being a thought leader. You can’t do this by just coding a few hours every couple of weeks. You need to sink your teeth into some problems.

Sunday, November 7, 2010

Passion, Joy, and Software Startups

Passion and joy are two of the most important parts of life, so as a software developer I think it's important to understand how to create a software career that brings us the most passion and joy.  As this eHow article on How to Follow Your Passion says:
Remember that following your passion is the most important thing you can do for yourself when it comes to your career. The majority of people are programed to not follow their passion when it comes to their career because they still fear the unknown. But following your passion early on is a must if you want to live a succesful fulfilling lifestyle.
One of the best things about America is that our culture supports entrepreneurs who build their careers by following their passion.  Although there is an interesting counter-point to this: The average Peruvian is 3.5 times more likely to start their own small business than the average American.  Maybe I should start my next startup in Peru.

According to the respected publication The Economist, between 1996 and 2004 America created 550,000 small businesses every month.  Wow!  And one of the best things about being a software guy in the Bay Area of California where I live, is that we are home to so many software startups.  In the SOMA area of San Francisco where I've worked at several startups, the number of startups has just started surging in 2010, according to The Wall Street Journal.  As SFGate puts it:
In San Francisco's South of Market neighborhood, Internet-based software startups are thriving despite the worst downturn to hit California since the Great Depression.
Some of you at this point will be saying, "but how many of those startups survive?"  The table at right shows the percentage of startups still in business up to 10 years later.  This data is from the Bureau of the Census produced for the Office of Advocacy of the U.S. Small Business Administration.  Another data point comes from Scott Shane's excellent book, The Illusions of Entrepreneurship.  In it, he states that one third of startups are successful after seven years, which agrees pretty strongly with the U.S. census data.  Scott characterizes this as "only one third", but I think of it like, "Holy Shit!  That's good odds.  Just have to try a few times and I'll get it.  Might even get lucky and hit my first one out of the park."

I believe following your passion is part of American culture and especially Bay Area culture, and is part of self-actualization.  This is pretty deep spiritual and philosophical territory.  Earlier this year I blogged over on my personal blog about the relationship between self-actualization and destiny.  Interestingly, Scott Shane states that the main reason people start a small business is to avoid working for others.  I think that perhaps it's harder to self-actualize if you're following someone else's business.

When you reap the reward of joy from pursuing your passion, you may also accumulate some amount of wealth - perhaps even a lot of wealth.  It's easy to forget that the value of following your passion is the joy you reap from doing just that - not so much from the wealth you accumulate.  In fact, one famous study suggests that lottery victims experienced less overall happiness than accident victims.  I take that to mean that wealth in and of itself doesn't bring joy or happiness one bit.  It comes from following your passion.  I love this quote from Health Guidance in the article True Wealth Will Make You Happy But It Must Be "True":
True wealth lies in defining ourselves by who and what we are, not by what we do or do not have.
Many software startups that started with lots of passion become successful, so they grow big and then they have a problem as they grow larger: Innovation and the entrepreneurial spirit flicker out.  How do they keep the innovation and entrepreneurial spirit alive as they grow?  Google has made famous (but did not invent) the idea of reserving a certain percentage of everyone's time for innovation - their famous 20 percent time.  Google says this in their section on an engineer's life at Google:
We offer our engineers “20-percent time” so that they’re free to work on what they’re really passionate about. Google SuggestAdSense for Content, and Orkut are among the many products of this perk.
I think the key part here is giving people a way to "work on what they're really passionate about".  By implication, the other stuff they're doing, well - they're not so passionate about that.  Hmm... That kinda sucks then, doesn't it?  That means 80% of your time is spent doing relatively boring stuff, and that to me seems like a high tax.  I'd kinda like it if I spent much more of my time working on stuff I'm passionate about.  Where can I do that?  And the fine print of Google's employment contract says they own 100% of any vision I create in my 20% time, so I'd like to keep at least some of that for myself please.  Where can I do that?

I believe there are at least two routes to finding more passion.  One route is to find someone else with passion that's out there building something, drink from their cup of passion (which should be overflowing), and then you will join with others in this way.  If you're following this route, I think it's important to find a group of people with passion for what they're doing - don't settle for people that don't care so much about what they're building.  If that kool-aid cup contains apathy, you will most likely have a bitter taste in your mouth.

Another route to passion is to realize your own vision in the form of a startup business, based on an idea you're truly passionate about.  How do you know if you're passionate about something?  I like the way Ryan Hoback puts it in his posting The Passion Behind Business:
When I get excited about a new venture that I have been developing, I feel the excitement run deep through my body. A feeling of invigoration comes across me. When a new idea comes to my mind, I begin to get happy like a little child opening a present on their birthday. You see, this is passion, and this is what successful business organizations are built on. Passion. Passion is the driving force and inner desire among entrepreneurs and leaders across the world which makes you want to continually pursue going above and beyond.
 Cash Miller puts it this way in his article Why is Passion in Small Business Necessary?
The number one asset a small business owner and entrepreneur needs to have is passion. Passion for your business is an essential ingredient when building a business. It can help to energize you when times are tough and it can help fire up your employees. Passion is what makes people believe. Do you have that passion?
So maybe you do have all the passion in the world, but most likely you don't have the personal resources required to start your own business all by yourself.  It takes a lot of time, which means you can't use that time to earn income, which means you must have a means of sustaining yourself while you're building your business.You can't eat passion for breakfast.

In addition to your own time, you must invest money in one way or another, either by eating into savings, or in the form of opportunity cost - lost opportunities for earning income, or in the form of loans, or an angel investor.

In addition to investing time and cash, if you're doing something really big, you will need to team up with other like-minded entrepreneurs as partners.  You will all need to drink the same passion, and it will take time for you to all get on the same page and share a passion for the same vision.

Tuesday, November 2, 2010

When not to use Agile

When building products with teams of people over the course of months, I think the Agile project management approach works best.  I have my own customized Agile approach I like to use that I'll likely describe in a future post.  But first, this posting describes when not to use Agile.

I've been noticing an increase in the number of extremely short, tactical coding exercises to deliver urgently needed functionality within hours or days.  More and more, I see people doing things like: throwing together a web site, building a prototype, creating a custom ETL solution, creating a new kind of widget, fending off a hacker attack, or creating a new report.  Sometimes the code may only be used once, or it might be used for years.  Often times these coding exercises must be delivered as quickly as possible, and with no advance notice.

I've found the best way to deal with these situations is to immediately create a team composed of the people that need to work together to deliver this.  Have them meet and figure out who's going to do what and when, and then they go off and do it.  No sprint meetings, no burn down charts, no stand up meetings - the team just gets the job done.

The challenge here is that the set of people that are working on these types of urgent tasks may largely overlap with the set of  people working as part of an Agile team, and they will most likely be in the middle of developing work that they've committed to delivering by the end of the sprint.

I think there are a few solutions to this problem, each with pros and cons.

First, you can reserve a certain total percentage of your Agile team's velocity for urgent tasks - say 20%.  This basically comes off the top of the total team velocity that you start with at the beginning of a sprint planning session.  At the same time, you identify a few stretch tasks in the sprint - bonus features that are either in the next sprint or that would be really nice to have.  If you don't use up your 20% reserve, you can tackle some of these bonus features.  The down side of this approach is the extra cost for context-switching mid-sprint; it takes extra time to switch between a person's sprint tasks and their 20% urgent task.

Second, you can just make sure that these two sets of people don't overlap - reserve different people for the short, tactical projects and manage that pool of people differently (but also probably not Agile).  You can periodically swap people between these two sets for cross training purposes.  The down side is that this probably requires more total people, so it's much more expensive.