I have a new post up at blog@CACM, “Why do Software developers put up with ‘Crunch Time’?“ about managing software developers during the push to launch.

Included with this one is a story about my experience on Amazon Auctions. The blog post was inspired by reading about an open letter posted by the wives of Rockstar games and the months they have been dealing with absentee spouses while they try to release the game, and an article from Harvard Business Review about what motivated workers the most. The serendipity of reading the two the same day was a great reminder of the importance of recognizing the employees are the company’s most important asset.

This winter was the first time in 40 years that I didn’t spend the holidays and New Year’s with friends and family. Instead, I spent time in Peru as a tourist and one week helping to build a community center an hour north of Lima. The Seattle Times has a great article about the project. If you have some money to donate I would encourage you to donate to the Lake Union Crew Outreach Foundation.

This blog article is about a lesson in leadership that I learned helping build the community center. In watching the lead engineer work and manage the effort, the thing that made the largest impression in making the project successful was her constant involvement in every component of the construction. The project was run as an 8 week relay with new people coming on and off the team every week. The factors that made the project feel successful were directly attributable to the following:

1) Leadership by Example -- The project lead was involved with every element of the construction when she wasn’t helping coordinating the volunteer’s effort. Whether it was lifting every bucket of water into the concrete mixer to make sure the concrete pour was going correctly, or coaching the pouring of the concrete foundation she was always present and visible during the critical portions of the project.  I was doubly impressed that there was no job too small. At the end of the day, she would walk the site and carry lumber, or move rebar to the correct location so that it would be available for the next day’s work.

2) Tolerance for mistakes and re-work — One day we stacked a row of concrete blocks in a row 80 feet long and 5 feet high, next to the wall where they would be placed. Unfortunately, the blocks were set in an unstable pattern, some of the blocks were resting on their sides (making them more susceptible to cracking), and they were 4 inches too close to the wall meaning the scaffolding couldn’t move along the wall to place the blocks.  The only solution was to re-stack the blocks. She started the re-stacking and trained the team of 5 on how to fix the problem. Two hours later the re-stacking was done, none of us would make the same block stacking mistake again. As unfortunate as it was that the mistake happened, the only solution was to re-do it and show us how to fix it.

3) Trust and verify — After everyone had left the site, I watched her wander through the interior of the empty structure with a measuring tape verifying the interior plans would actually work for subdividing the space within the structure. I jokingly asked her if she was seeing the forest through the trees, and she replied “Yes.”  Her experience helped her visualize the internal space, and come up with some last minute revisions that would make the site more suitable for its intended usage, and not what was just laid out on the sheet of paper.  A second example would be that she would delegate portions of the project to experienced and trusted team members, but later walk through and confirm or have adjustments made based on what would work best for the work site.

4) Progress — The beauty of working on construction project is that every day you can see the structure change and get closer to completion. One day there would be no roof, and the next there would be a roof installed. One day there would be a mesh of rebar on the floor, and the next day you would have poured a complete concrete floor. Every day the masonry wall would climb steadily higher, and the window and door frames would get placed.  A recent Harvard Business School study of the notes of 12,000 workers the biggest motivator for keeping workers engaged was progress. Progress was more important than interpersonal support, instrumental support, collaboration or “important work.” Simply making progress kept the team engaged.

There are many valid critiques about the project engineer’s leadership methods. Her communication style chafes individuals who want more collaborative exchanges. That said, no one could deny that the progress of the project was proceeding as smooth as it could using a volunteer work force, sub-standard equipment, and dusty/sandy conditions. In looking at the lessons of the project, it is not hard to see how these analogues work just as well for leadership when writing software and building companies.

Addendum: “It Takes a Team”

The project engineer and lead had the responsibility for delivering a large facility in 8 weeks of work using volunteer labor. She had the support of the Lake Union Crew Outreach Foundation who helped do the fundraising, teams who contacted and scheduled the volunteers for weeks, architects who designed the building, runners who helped coordinate construction resources in Peru, and a core team of members who had built similar structures with her in Lesotho. Her responsibility was making sure that the physical construction of the building and the supporting terraces were done on schedule.  The volunteers were people who self selected for the project. They varied in age and ability from 7 to 60+ years, and with no experience working in construction to having worked with the lead on prior similar construction projects.  The volunteers included up to 24 English speakers and 20-30 Peruvian volunteers who spoke smatterings of English. The volunteer experience included more than just construction, as it also involved shared meals, conversation and singing, but those stories are for a different venue.

I love my GPS devices and use them because they provide a great utility in either tracking my running and biking or informing me of the location of the closest coffee house. However, in using them its easy to see how they could be massively improved if they leveraged all the other people who use the devices similarly and anonymously shared the aggregate information. Amazon and Google improved their search engine relevance by getting lots of traffic and aggregating user behavior in web space. I believe that software like Garmin’s Connect and Google Maps could benefit through the use of aggregating people’s behavior in physical space.

Repeating the obvious, to keep a startup alive you need to bring in more money then you spend, and you need the determination to keep up that effort. I recently received documents from a two year old start-up summarizing the steps the company has taken to keep itself alive. In the past year the company looked to raise another round of funding, but with issues surrounding raising money for advertising based startups, they were not able to get a valuation the founders and the seed round investors deemed reasonable. Rather than dilute themselves or run out of money, they chose to: a) Eliminate staff to just the founders, b) Reduce and eliminate compensation to those founders, and c) Take consulting opportunities that are related to the company’s mission but not directly to their goals to sustain the business.  These consulting opportunities relate more to the expertise of the founders, rather than the goal of the company.  They acknowledge that this is not the original long-term plan, but fortunately, the consulting clients are potential future customers of the company’s product.

In reading  “between the lines” of the documentation, I could see that there have been opportunities for the founders to just call it a “good try “and move on to other startups, jobs, or consulting without the overhead of funding this venture.  However, the team is determined to keep on with their mission, and found a revenue source that was “good enough” to help bridge and get to their eventual goals.

Paul Graham’s essays about startups is one of my favorite reads about how start-ups succeed and fail. More important than brains is the commitment to deliver on the goal and to do everything it takes to support the startup. The decision is actually easy: If the money truly runs out, and there are no consulting opportunities, revenue or additional funding, then it really is time to shut the company down. If revenue can be assembled then the next most necessary element is the determination to continue to deliver on the goal.

Twitter Summary: We aspire to be innovative, but unless we are willing to implement ideas and measure them, they will just remain ideas.

I have a new post up at blog@CACM, “Innovation = Good Idea + Implementation + Measurement” about the three necessary components to innovation.

Included with this one is a story about the early days of Amazon.com. The blog post idea came after a morning run with a friend and Googler where we were talking about all the “good ideas” that circulated our respective environments. What distinguished things from being  “neat” to actually “good” was invariably the ones that had the developers actually supplying the metrics with the implementation of their idea.

I loved being employed as a software development engineer.  Technologies and toolkits evolve so quickly that every time you think you have mastered one, there is something new to learn for the next project. Last year’s assumption that machines are too expensive evolves into next year’s plan that includes machines ten times as powerful as the ones you had before for the same price. Last decade’s assumption that disk space is too expensive evolves into this year’s plan that includes more disk space then you thought was possible and for barely any money.  If you’re a person like me that likes to learn, grow and change, it’s a good discipline in which to be employed.

This continuing education, the time spent planning and developing software requires focus that quickly puts engineers in the very desirable mental state of Flow (wikipedia). The experience of getting into a mental flow state is difficult to achieve, but but once there is very enjoyable. You can achieve it in any activity that requires skill and focus. In sports you hear about players getting “In the Zone.” In music you hear about musicians getting “Into the Groove.” As a software developer, my flow was 10pm to 2am when I wasn’t getting interrupted.

Transitioning from an engineer to a manger of engineers requires a change that is completely contradictory to “Flow” and what I affectionately call “Short Attention Span Theater.”  As a manager you are required to coordinate projects and people to be successful. Given the nature of communicating via email, one-on-one meetings, status reports, and conflict management, and the fact that these often happen in short bursts of time, there is no time to get into a “Flow” state. The skills that make a great engineer will not make a great manager.  What this translates to practically is that every time someone walks into your office you have only about 30 minutes to focus on the issues at hand so the person walking in gets the information they need to make themselves and their project successful.

“Short Attention Span Theater” really requires changing your engineering mental framework in order for you to be successful in a manager’s role. As a manger, it is necessary to take the short time you have with each of your team members and make it valuable. “Short” is the operative word since you are expected to provide the same focus on the team and the organization goals at the same time.  Any attempt to achieve “Flow” while being a manager will likely lead to personal or team frustration as it is difficult to both manage and develop software at the same time without some issue getting dropped.  If you embrace “Short Attention Span Theater” as the key to making a whole team of people successful, then although you won’t personally achieve “Flow” state, you will make it possible for a larger group of people to deliver a successful product.

One of the biggest factors to success in weight loss and management is if you are able to simply write down what you eat and have a support group help you along the way. If you can make a tool that makes it trivial to do both you would be more successful in your weight loss goals. The iPhone has some applications for this, but so far the applications I have seen aren’t as seamless as I think they should be in computing food eaten and sharing results with people who are looking to help you.

[For those who like the science behind the statements, the research article was published in August 2008 in the American Journal of Preventive Medicine.]

The rationale for patents is exchanging explicit information for how something is done for an exclusive right to do it that way until the patent expires.  This appealed to me as a software developer. As an open source software supporter, and a life-long student I have always appreciated reading algorithms, source code and processes to figure out how something is done.  Given that we are all standing on the shoulders of giants, it seems only right to share as much as we can to further advance the development of better software and systems.  Developers should be paid for their work, and the companies that invest in sharing how they do something should be given the opportunity to benefit for their contribution.

Unfortunately the perceived and actual misuse of patents in the software industry are legendary. The GIF patent issue in 1994 suprised many developers that a widely understood algorithm was patented and that anyone who used a common image rendering software owed Unisys a usage fee. The Alcatel-Lucent patent infringement lawsuit which is still under litigation generated a $1.52 billion judgment against Microsoft in 2007 for its use of the MP3 encoding/decoding technologies.  Even more tragic are the patent issues for HIV/AIDS related drugs, where  patent protection has made it difficult for poor countries to afford the drug for their populations. India recently rejected the patent applications so that they can provide the drugs at a more affordable price to their citizens.

Given the value created by the patent system in encouraging the sharing of information, a continuous review process would improve the agility of the patent system to reflect the changes and innovations all people would like to see. Microsoft would like to see the patent system be unified into a global patent system.  I think this is an excellent idea on three levels:

1. It would compel a conversation and hopefully create a unified standard about what types of inventions should be patented and for what duration they should be patented.
2. It would compel people, organizations and countries to think globally about the impact of their inventions and create a standard that they should achieve if they want patent protection.
3. All these conversations and standards would have an organization committed to examining and re-examining if it is achieving the desired goal of increased innovation, increased information sharing, and adequate time for inventors to recoup their investment.

Such a patent organization could periodically re-align itself to achieve inspirational goals like the XPrize Foundation and support innovations that would benefit society.  It could offer a 100 year patent to the first organization that creates a cure for cancer, or creates an affordable non-polluting vehicle that can travel thousands of miles. It could create shorter patent durations for software or other technologies that have a short life-span. Given the many approaches to patent reform, it should all be with the end goal of encouraging the sharing of information, providing a standard for establishing the uniquness of an idea, and allowing the inventors enough time to benefit from the exclusive ownership of the patent.

Software patents their use and their mis-use have generated lots of heated discussion on the web. The Cato Institute recently released a document critical of the software patent process.  Tim O’Reilly has been using his media organization to spearhead efforts to reform software patent laws and why it should be done.

However, until these reforms are implemented every startup that invents a novel or unique “something” has to make the decision: Should we patent this?

In a cash strapped startup, patents are expensive and committing money for them gets prohibitive quickly.  Patents  cost $15K to get filed and another $15K in maintenance. In addition, they cost developer time in writing up the invention instead of spending time improving the product. Some of the cost can be deferred for a year by filing a provisional patent for a few thousand dollars, but that just delays the inevitable price tag.  If a patent is contested or you want to file internationally the price only goes up. Patents take several years before they are granted (if they are granted) and then you need to pay to defend them which will cost more developer time and legal fees.

Deciding what to patent can be as hard or easy as you want but it depends on the available budget. In a large company with a large budget for patents, there are the resources to build up an arsenal of intellectual property. There is typically a patent submission form, an internal patent review process, and eventually a prioritization for how well the patent aligns with the company goals.  Anything novel and unique would be considered as patentable and submitted so that they can be someday used as defense from other organizations, when the inevitable infringement lawsuit occurs.

In a small company with fewer resources deciding what to patent is simpler because you ONLY patent if your novel and unique approach is

1. Directly attributable to your ability to make money, and
2. You are willing to go to court to stop other people from making money using the same technique.

If your idea doesn’t satisfy both those constraints, then go on making software and with luck you will be able to avoid most of the patent issues that larger companies need to manage. For example, if you are an online advertising firm you would patent intellectual property associated with advertising and not spend the resources to patent a spell checker that isn’t tied to any revenue source.

Building up a patent portfolio for the sake of patent portfolio is not a way to be successful. Admittedly, patent portfolios can help with valuation of startup, but only if the organization has a viable business model which is independent of any of the patenting decisions.  For a startup company, if the patents do not satisfy the first criteria of being core to the money making ability of the business, then there is no point filing a patent since it will not have the resources in the long term to continue to build the organization, much less defend the patents.

The first is the Netflix “Reference Guide on our Freedom & Responsibility Culture” slide presentation outlining how Netflix chooses to distinguish itself from other organizations. So many great comments are available about it, I will merely add this would be a great resource to crib from if starting a new organization or if you are looking for a successful culture to model.

The second is from Kate Roth that highlights how a high service organization like the Ritz-Carlton encourages and allocates money per employee to impress their guests. I liked this one because it made me think of what employees at a web startup could do to “wow” their customers. In cash strapped start-ups, the “wow” may not be directly monetary, but can certainly be budgeted into the time it takes to deliver a piece of functionality.  This extra functionality would hopefully be something that amuses, astounds or makes the customer’s experience uniquely satisfying in their use of the product.