Category Archives: Startup Operations

Stop Losing Ideas: A Proposal for 21st Century Employee Communication

Steve Bland recently wrote this interesting post on why he thinks traditional board meetings are a waste of time. He proposed an novel hypothesis of “The Boardroom as Bits,” whereby founders/CEOs spend 1 hour per week providing updated information to their board members and advisors via a blog.  He argued that this communication method would:

  1. Provide a structure for entrepreneurs to regularly check their progress and re-visit their plans.
  2. Provide more regular, asynchronous updates to board members and advisors — as opposed to just once every 6 weeks.
  3. Facilitate real-time coaching.
  4. Enable coaching despite long-distance separation between the company and its advisors.

Steve backed up his hypothesis with promising results from an experimentation at Stanford.

Why Not the Entire Company?

I went for a run along the Delaware River after reading Steve’s post and I started thinking about whether this idea could be useful for an entire startup company, not just the executive team and board.

I recognize that one of the main issues with board meetings is that they’re only scheduled every 6 weeks; they’re not real-time. In a company this shouldn’t be the case: the employees show up to the office and interact with each other daily. But hear me out…

At my first company, we frequently struggled with three issues:

  1. We had more good ideas than we had time to pursue. We didn’t have a good system for capturing new ideas, vetting them, and then executing on the best ones. This created some frustration amongst our creative employees, since good ideas were frequently neglected.
  2. We subjected ourselves to time-wasting debates and endless pontification. People didn’t take (or have) the time to really think through their positions. As a result, old debates were frequently rehashed.
  3. We lacked materials for on-boarding new employees and orienting them on past projects. Megabytes of documentation were buried on the company server and weren’t written in a readily-accessible manner. “Training” typically consisted of throwing new employees into projects and expecting them to teach themselves to swim. This approach wasted countless manhours…but we had no good alternative.

At one point, we tried establishing a company wiki…but it lasted only a few months. It was yet another IT item to support, required “curation” to keep it organized, and didn’t integrate well with our other communication channels, like email.

So…here’s the idea: Establish an internal, private, employee-only blog. Everyone can make posts and add comments. A blogging engine like the one I use (WordPress) would automatically email new posts to all employees and simplify organization of the posts.

Upwards Communication

Whenever someone has a new idea for a project they can’t implement by themselves or within a small group, they’re expected to spend 1 hours writing it up as a short blog post. The blog engine makes it incredibly easy to add photos and other media to illustrate the problem. Once it’s posted, the idea is automatically distributed to all employees. This allows — for example — the CEO and engineers to be exposed to the issues the guys in production are struggling with and their solutions without every employee having to speak with every single other employee every day. Unlike emails, the posts don’t get buried in the daily deluge.

A blog would allow people to post comments to engage in discussion and flesh out the idea (contribute to cost estimates, explain how the idea would affect their work, etc.). The original author can update the original post based on this feedback. Negative “sniping” comments are easily deleted, but fact-based critical analyses are available for everyone to see. It’s also clear who originally came up with an idea so that credit can be given where credit is due. The blog posts turn frustration among the “troops” into ideas…and reduces whining…as people record and distribute their ideas. Meetings are no longer derailed by tangential discussions, since people can park new ideas on the blog to develop and discuss later. Management can occasionally parse through the blogged ideas and pick the top ones to implement.

Downwards and Lateral Communication

The management team can also post occasional company-wide updates or use it to record policies and procedures. Engineering project teams can document their design ideas on the blog and brainstorm pros and cons. It becomes a record of what ideas were considered and becomes a training tool. New (and existing) employees can review the posts so that they can learn from past design efforts…regardless of whether the originator still works at the company.

Writing is Good for Your Health…If Done in Moderation

In this post I wrote about the tricky balance required in a startup between staying lean and implementing new processes to keep a growing company efficient. I always erred towards too much process and my co-founder always erred on the side of being too lean. The problem with this blog idea is that it could become a huge time sink, with people spending more time polishing their posts and debating via the comments section than actually getting work done.

That said, I’ve found writing as an excellent way to explore, organize, and develop my ideas, even though it does take time. The more I do it, however, the less time it takes. I’ve especially appreciated the ease of sharing and discussing ideas with others via a blog. I’m curious whether these benefits could be applied to an entire organization and whether they’d outweigh the negatives. I’m interested to hear your thoughts. Is this the right 21st-century communication tool to apply to a startup?


Becoming a “Real Company”

This is the first in a series of articles I’ll write on Startup Operations. The other articles are in the “Menu” links in the sidebar and some are also linked at the bottom of this post.

One debate that resurfaced countless times at my first startup was whether and when to put in place processes, policies, and systems. I found that many of the early employees fell victim to the “startup doll house fallacy.” Startup companies are not dollhouses (small versions of big companies). Just because big companies operate a certain way — they’re organized by departments, have hierarchies, have precisely defined positions, have layers of budgetary approvals, etc. — that does not mean that startups should do the same. The lesson is that if you’re in a startup, take advantage of that freedom…don’t be too eager to act too big, too fast. Wishing your company did things “like a real company” is a sign of immaturity. Do it your way.

In my company, the process-averse guy usually won the debates, so we stayed lean. After ten years of operating this way we brought on board a new CEO. Two weeks into the job, he commented to me, “I’m amazed how well we do the difficult engineering tasks…and how incredibly bad we are at doing the things that should be easy.” We had erred on the side of being too lean. As a company grows, its systems need to grow with it. Four co-founders can work and communicate efficiently by yelling over the cubicle wall or sharing spreadsheets. Those techniques won’t work in a 50-person company, which needs ways to document plans, track inventory, and assemble products consistently regardless of which schmo is doing the work.

Bill Gross provides a great perspective of this with his talk on the four complimentary skills needed throughout the life of a startup (Entrepreneur, Producer, Administrator, and Integrator).

The “entrepreneur” and “producer” personality types — needed most during the early years — tend to avoid new processes like the plague. This works well in a small team. “Administrator” and “integrator” personality types — needed once the company grows and has some paying customers — will want to implement systems in order to improve the efficiency of communication and standardize work methods. The four personality types frequently can’t stand each other, which is why this debate about processes and systems frequently becomes so heated.

So, how do you make sure that your company’s processes develop with the company and make your team more efficient, not less? The default approach for an inexperienced employee is guess how the team will function together and then create a form that someone needs to fill in. WRONG! The better approach, I’ve found, is to muddle through a few times, then have everyone look back and capture in a simple flow chart how they made it work.  If a template document is required in order to standardize things, then create that, too…but think twice or three times before making it mandatory. Then iterate and improve from there.  Be careful…it’s easy for certain employees, especially engineers, to enjoy this type of work. Assign someone the very-part-time responsibility of quality manager so the engineers aren’t tempted to spend hours inventing new systems for themselves. The goal is to make the team more efficient, so spending hours and hours in reinventing or perfecting the documentation totally defeats the point.

Here is a list of some processes, procedures, and tools (in no particular order) that eventually become necessary in startups at various stages in their growth. The ones that have links have a blog post describing them in more detail. My background is in companies that design and build industrial equipment and do a lot of government-funded R&D work. If your company is a dot-com, software, or service company, some of these may not apply. Use your own judgement.

If you’re interested in one in particular…or if you think I’ve missed one…just let me know in the comments section or via email.

  1. Sales bid approval – prevent the sales guys from over-promising and get buy-in from the engineers. Important to implement early on.
  2. Training and onboarding – new employees can take up to a year to be fully productive and are a drain on existing employees in the interim. Minimize that training process. Show them what work has been done in the past, who to talk to for help, where to find information, the company culture and “way of doing things,” etc…and make sure everyone is exposed to the same materials so you all speak a “common language.” The only way to do a good job of this is to start building it early on, a little bit every month (it’s one of the reasons I’m writing this blog).
  3. Project management – define the steps that projects go through, what documents are created and, more importantly, what documents don’t need to be created. Improves efficiency in engineering if they’re juggling multiple projects.

  4. Project baselining and revenue recognition – set deadlines, define billing milestones for accounting, track how much work has actually been accomplished. Important for companies that do government R&D work, especially once their revenues exceed $3MM. Simplifies communication between engineering, management, and BD.

  5. Sales process – adopt a standard software tool like to track leads and opportunities, which is useful once you have more than one or two sales guys. Even earlier, define how sales forecasts are estimated, since actually hitting sales targets is the most important thing to keeping the business afloat (followed closely by actually delivering what you promised).

  6. Financial forecasting – define standard revenue and cost centers, define budgeting process. Important to have a rough process early-on that you can refine as you grow.

  7. Timecard software – incorporate a standard online software tool; there are dozens available. Important for companies that bill hourly — such as service and government R&D companies — and for manufacturing companies for calculating COGS. Track actual manhours spent across multiple projects, allow project managers and accounting to easily generate reports, catch under-utilized people or poorly-run projects early on.

  8. Financial software – adopt a software tool like Quickbooks to keep track of the books. This is probably the first tool implemented by anyone who’s actually serious about running a business.

  9. Inventory and purchase order (PO) tracking – adopt a XXX software tool, which is important for manufacturing and government R&D companies, especially once they grow above 30 people. It improves efficiency for project management, engineering, and accounting.

  10. Configuration control – Disciplined revision control is the most important and least appreciated engineering practice amongst young engineers and entrepreneurs. It’s also a huge time sink if done incorrectly. Initially, excel spreadsheets work fine, but eventually a real software tool is necessary, especially once your engineering team grows above 15 or you start manufacturing.

  11. Templates – Providing templates for specs, data sheets, customer reports, engineering documentation, etc. is one of the easiest ways to save countless manhours of debate and re-work, especially in engineering, and provide a professional appearance in written materials to customers.

  12. Recruiting – Always Be Recruiting. Once you start hiring like gangbusters or get above 20-30 employees, some standardization and tracking is necessary to make sure you’re looking for and finding the necessary skill sets.

  13. Compensation – Not standardizing your compensation method and not communicating it to potential hires and existing employees is the fastest way to piss off everyone. Be open and consistent from day one.

  14. Annual ops plan – 5-year revenue forecasts in glossy business plans are a huge waste of time. It’s difficult to predict what the world will look like one year out, especially in a startup where things are changing every day. If anything, have the team write a 1-year operations plan (ops plan) that sets the targets in stone.

The goal for a startup is to remain lean and efficient. Most of the time being efficient means avoiding bureaucracy and red tape, but on occasion it means standardizing on a simplified, proven way of doing things or using software tools to eliminate clerical work. Startups change constantly, so figuring out how to be work efficiently as a group is a never-ending effort. As you try to find that balance, aim for “progress, not perfection.”