Earned Lessons

Twitter Summary: Hiring is Timing. The timing of who you need, when you need them, and when they are available.

I have had the joy of helping three friends get job offers in the past few months at two Seattle area startups (www.groundtruth.com and www.jambool.com). Offering to help people is nothing new, its just that the last few months have had an unusually high hit rate for matching people with a unique skillset and introducing them to companies that needed those skills now. The whole process reminded me of an adage I was taught at my last startup that “Hiring is Timing.”

Deciding what you need next at a startup is generally simple. If something is not getting done and is core to the business, you should either prioritize the job higher for the people working at the company, or hire somebody to do it. If you don’t have the money for it you either need to raise the money, or generate enough to support the role. Resource constraints (Lack of money) really help the prioritization process. In a software company, I have always heard the rule-of-thumb is that you shouldn’t really need to worry about hiring a full time HR person until you hit employee 25 or in-house legal help unless you are creating revising lots of contracts and have the revenue to support them.

Twitter Summary: Given the well known increased risk of burnout during “Crunch Time,” why do developers put up with it?

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.

Twitter Summary: In transitioning roles from engineer to manager, the hardest skill to learn to enjoy was “Short Attention Span Theater”

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.

Twitter Summary: Should we patent this?

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.

Two posts came out in the past few months that I would like to highlight as they both served to remind me that just about every organization is striving to make great environments for their employees and their customers.

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.

Twitter Summary: An advocacy post for using SCRUM for your project management needs.

My affection for SCRUM as a project management tool emerged from my dislike in writing project status reports. SCRUM is a project management process that has its roots in Japanese new product development. It focuses on increasing the speed of delivery and functionality.  The advantage of using SCRUM is that it creates a single common vocabulary throughout the company. Thus, when the delivery of a project is discussed everyone is using the same language and tools to communicate priorities, progress, rate of progress, roadblocks, and amount of work remaining. There is so much good information about SCRUM available, I will use my blog post just to highlight the interesting side effects that I have seen.

I have used SCRUM-like techniques to track projects and deliverables in most of the organizations I have worked in the past 10 years.  Yet most of the projects still had many elements of the Waterfall development model that I learned and used in college and used while developing medical and avionics applications. These ad-hoc project management practices mostly worked, but there were occasional lapses in deliverables that caused the usual scrambling to determine why some pieces were late and why we the delays weren’t know about sooner. It wasn’t until my last startup, that we adopted the full SCRUM process at the encouragement of our advisors.

The biggest change in adopting the full SCRUM process was the use of the “Information Radiators” which were either simple white boards with sticky notes to indicate: Product Backlog, Sprint Backlog, Blocks List, or lined paper with a graph that showed the Burndown Chart of how many activities were remaining to be done.

The beauty of using SCRUM and all its information radiators meant that I no longer had to write a project status report. Everybody in the company was educated in SCRUM and how it worked. Anyone could walk into the project room, review all the information radiators and know exactly where we were in the project, how the current sprint was progressing, and what amount of work was remaining before we could call the sprint “Done”.   We took advantage of being a small single office team and just posted everything using the available wall space. (Our implementation would not work well for a team member working remotely, but web based toolkits are available that make remote SCRUM project management a possibility.)

After several sprints of product delivery we realized each of the information radiators had a special role in helping improve the process for the next sprint. If we neglected to update the burndown chart, it was because we were slipping. If we neglected to update the product backlog, it was because our priorities were changing. If we neglected to update the sprint activities, it was because something was incompletely understood and we didn’t know what it meant to be “Done”. Any time we neglected an information radiator, it was usually because whatever information that element was trying to communicate was failing and we didn’t want to write it down.

The keys to our successful adoption of SCRUM were:

• Require everyone involved either directly or tangentially to read the book. Agile Software Development with SCRUM
• Leave the SCRUM on a page [pdf] littered around the SCRUM area so that people can be reminded of all the critical components and roles of SCRUM.
• Get your SCRUM Master trained by a 3rd party to get used to working with the flow of the project.
• Use the Information Radiators as they provide a constant status and reminder to the whole team as to how the project is progressing.
• Make sure that the Sprint Review Meeting is held and that there is time spent focusing on how to make the next Sprint better. This was critical in helping us get better at delivering, and building a stronger product every sprint.

I have yet to find a better project management technique for developing products for the web. In running  a project using SCRUM, the activities bear a strong resemblance to what is done with Openspace Technology to run meetings. In using both techniques to communicate and plan, we were able to create an environment where the team members were participants, actors, and communicators in helping evolve the project and the company.

Twitter Summary:  Open compensation systems seem ultimately fair, so why do closed compensation systems still dominate?

Compensating engineers and managers in most organizations is a haphazard affair. Most organizations have “pay ranges” where they are provided a window of salary that each employee should be for stock, cash, bonuses, and even the amount of office space allocated for each employee level. If compensation ever felt “unfair”, it was more often caused by the secrecy surrounding the compensation process then any actual structural unfairness in the system. Most software engineers were in a few thousand dollars of each other, and by the time we are talking about 6 figure salaries,  “fair” was really just worrying about pride or status. However, it is hard to make people feel they have gotten a fair offer if the whole system is clothed in secrecy and they don’t feel that their compensation reflects the projects they have completed.

One solution is to have a transparent compensation process that can be inspected by the team and they can help contribute to its ultimate success. It is possible to run the largest of organizations with an open/transparent compensation system as the military and the U.S. government have published all their pay levels and expected benefits. Why don’t more companies open up their compensation for their employees to help contribute?  In my search for open and team based compensation systems my favorite example has been Joel Spolsky’s Fog Creek Software Compensation System. I was lead to his plan by the compelling article “Why I never let employees negotiate a raise”.  The summary is that if there is an issue that requires a raise for one employee, the company should consider if every employee at that pay level should get a raise. Frequently, the issue of a raise is simply the engineer is having some issues with some other aspect of their job. By having an open compensation system, the engineer can understand what it would take to increase their compensation individually, or by making the company more successful such that the profit sharing mechanism benefits them and all their colleagues.

Closed compenstation systems have difficulty getting it right for team based development methodologies such as Agile development. Agile software development practices require a different way to think about how to align team goals with the incentive to launch goals. Mary Poppendieck’s article on Managing People and Projects(PDF) is a great example of what a manager can do if they are trying to help create an appropriate reward structure for a team within a closed compensation system organization. The compelling part, is that if you follow her guidelines it will eventually lead you to a transparent/open compensation system as advocated by Joel Spolsky.

There are ultimately some holes in these compensation systems as they don’t take into account organizations that have roles that have been traditionally incentive based. An example of this is a sales force, that is provided a bonus if they sell a certain amount of the company’s product, however as a whole these seem like a great way to think about creating a company’s compensation plan.

Twitter Summary: You are going to spend a lot of time with your early hires. Make sure you enjoy their company.

A special case in interviewing is finding and assessing co-founders and early employees.  The first hires are critical as they will help dictate the direction and eventual outcome in success of the company.  The interview process for early employees is different in that the people you are typically interviewing are referrals or perhaps “friends of friends.” Generally these are people who have been successful in some other organization and your job is to determine if they can successfully help you bootstrap your small organization. Spending extra time with them during the interview phase is especially important as you will be spending many more hours with them getting the company off the ground.

The interview questions in this case are not very different. However, the skill set you are hiring for is broader and personality attributes are much more important.  Interviewing early employees should take more time as you need to assess if they have all the skills you require.  Following up with the referral candidates is also critical. Even if the candidate is not offered or decides not to accept a role they may turn into an invaluable resource for other future hires.

Key traits to look for in early hires are:

• Can you spend a lot of time with them?
  • Rather than a 1-3 hour interview, spend a full day with each other talking about the business or social matters.
  • Consider taking a trip with a potential candidate to a client site to see if you would enjoy working with them.
• Would you want to be in a foxhole with this early member?
  • Does the candidate have a wide range of skills or more importantly the enthusiasm to do things beyond their skillset in order to get what needs to be done completed.
  • Consider asking the candidate how they deal with stress, both their own and others? Startups are by definition stressful environments and having a candidate who is self-aware to provide a good answer with examples is really important.
• How do they deal with ambiguity?
  • All early stage companies lack phone systems, HR resources or people to help with basic maintenance tasks. In the absence of information, a policy or even an ability to do something, what is their approach to make sure the task is completed.
  • If the garbage is overflowing do they (a) Take it upon themselves to do it, (b) complain about the garbage overflowing, or (c) create a schedule to rotate who takes out the garbage until an office manager or someone is hired to take care of it as a permanent responsibility.

This post was inspired by Mark Goldenson’s comment in an earler blog posting.