Official Blog

“When our first parents were driven out of Paradise, Adam is believed to have re-marked to Eve: ‘My dear, we live in an age of transition’.” (Inge 1929)

We started out a couple of months ago with this series on scalable startups with a reflection on organizations as lump of butter in a sea of milk. Organizations are social arrangements. Hence our next focus was the core constituent of any organization: Its people. A well-crafted strategy is worthless without a committed crew. The focus on people is core to what we do. Nonetheless, an organization is no end in itself. The fuel that drives the engine forward is customer needs. We cherish users like nothing else: They come first.

We argued forcefully for smaller organizations. Instead of large anonymous corporate monsters we made a case for smaller and nimbler units. We also outlined how to maximize involvement and reduce the useless part of management: Let people decide. To put these decisions into action we rely on a project methodology – Scrum – that finely aligns overall goals, immediate tasks, people and resources.

A particular issue we dealt with is how to get work done. Instead of word wilderness and excel wasteland we draw on the advantages of Wikis for documentation and a powerful task tracking tool. Both tool sets are completely web-based and accessible from everywhere.

In terms of actual setup and operation of an online platform we learned a lesson or two from our previous engagement at local.ch. A must is a shared nothing architecture plus automated building of the software application. To ensure consistency and reliability we made testing a daily priority.

The virtualization options available today are essential for a startup. We can cut down very considerably on our asset investment in servers and other bulky infrastructure items.

The outlined setup of a scalable startup is very much the realization of what Peter Drucker sketched out in his essay on The coming of the new organization over twenty years ago:

“The typical large business 20 years hence will have fewer than half the levels of management of its counterpart today, and no more than a third the managers. In its structure, and in its management problems and concerns, it will bear little resemblance to the typical manufacturing company, circa 1950, which our textbooks still consider the norm. Instead it is far more likely to resemble organizations that neither the practicing manager nor the management scholar pays much attention to today: the hospital, the university, the symphony orchestra. For like them, the typical business will be knowledge-based, an organization composed largely of specialists. … For this reason, it will be what I call an information-based organization.”

A little over two decades later, the startling development of the Internet has driven much of the transformation from an industry-based economy to an information-based economy. Multilevel hierarchies have given way to clusters of business units coordinated by market mechanisms rather than by layers of middle management. The large enterprise structures designed for the business environment of the 1950s and 1960s – firms that typically sought economies of scale through central planning and control mechanisms – are quite likely not the most adroit forms at meeting the current competitive environment that demands both efficiency and effectiveness. Companies track opportunities and resources on a global scale. In an attempt to maximize return on assets, firms perform only those functions for which they possess or can develop expert skills. Activities that can be performed quicker, more effectively or at lower cost by others are outsourced. An intricate network of formal and informal relations ties the firm together. The momentum is paced by information technology.

Back in 1978 Hiltz and Turoff summarized this phenomenon as follows:

“We will become the Network Nation, exchanging vast amounts of both information and socio-emotional communications with colleagues, friends, and ‘strangers’ who share similar interests. ... we will become a ‘global village.’ ... An individual will, literally, be able to work, shop, or be educated by or with persons anywhere in the nation or in the world.”

True.

_______

Series Overview

• Organizations – A lump of butter
• Focus on people – They are the one
• Rule #1 – Customer First
• Smaller organizations: The sum of the parts
• Project management: Skip management
• Turn the waterfall upside down: Scrum
• Abolish (MS) Office: Wiki will do
• Process & control: Do a Jira
• Shared nothing architecture: A solo performance
• Automation: No one around
• Virtualization: Really no one around
• Testing: To err is human
• Conclusions - The Network Nation

_______

Drucker P.F., “The Coming of the New Organization”, Harvard Business Review, January - February 1988, pp. 45-53.

Hiltz S.R. and Turoff M., The Network Nation: Human Communication via Computer, London: Addison-Wesley, 1978.

Inge W.R., Dean of St.Paul’s London, Assessments and Anticipations, London, 1929.

In the contemporary world Michael Foucault, a French philosopher, thinks that organizations are places of controlled violence. Another tradition embodied by the American philosopher John Dewey, views organizations as edifying forums.

Whatever we think of organizations, either as incubators of new cultures, or as defined by the cultural milieu of our societies at large, most, including the cited philosophers, think they are artificial and therefore open to to being remade.

One area how we on purpose remade our organizational setup was the development process and issue tracking. Scrum, our preferred project methodology splits our entire project into stories and tasks assigned to two-week sprints.

Years ago we would handle project tasks with huge Excel sheets. Not a very amusing job, especially if you had to track a larger team. The burden was even greater on the team having to track their tasks.

During these celebratory days of 40 years Moon landing, I always wonder how the folks did it at the time without Wikis and without digital task tracking. 40 years later the problem is solved – digital distributed task tracking does the job. At Nektoon we use Jira.

Jira is a sister product of the Confluence, our Wiki software written by Atlassian. We simply got used to their product after our happy contact with their Wiki software. And additional benefit is, that both are tightly integrated.

Every issue, task, bug, improvement is recorded in our Jira. On a two week basis we assign these issues to individual members of the team. Once you start to work on an issue you register your work: We comment on the progress of our work and clock the time spent on each task.

With this we accumulate a body of data that allows us:

• To increase the quality of planning, scoping of our issues and projects, and
• To improve the actual implementation.

Furthermore the system allows: 

• Each team member to see at each moment what open tasks there are, and
• To whom they are assigned to
• What the progress on each issue is
• How efficiently and effectively we move forward.
• In case we run off course by too much, to see this early on and decide what measures to take.

For us the relevant part is the transparency of our issue tracking. We are able to manage hundreds of issues, assign accountability and ensure that things get done.

Next in the series how to build a scalable startup: Shared nothing architecture.

Most theories of editing are based on the idea of a single author. Stillinger, an American professor of English literature, calls this the Myth of the solitary genius, and points out that most “works can and frequently do have multiple authors, sometimes with divided and even conflicting intentions among them”.

Friedell, an Austrian historian, is more candid and reckons the discussion about plagiarism to be the most unnecessary controversy in history. Nature does not allow dishonest business, he writes, and goes on to unveil that Alexander borrowed from Philip, Augustine borrowed from Paul, Schiller borrowed from Shakespeare, the latter was influenced by Plutarch. Friedell concludes that dark times like the Middle Ages are always the result of insufficient intellectual larceny. He would have loved the Internet. Goethe, a German poet, rightly questions the sense of asking a well-fed man about all the ox, sheep and pigs he ate to give him strength.

Back in 2005 when we started with local.ch, we had to conceive and build the platform within just six months between October 2005 and March 2006. We were a team of nearly 40 people from six different companies. First, we split the platform into different building blocks (see previous post). Each sub-team had an organizational and conceptual challenge to document and a requirement to update and get updated by all the other sub-teams.

Most of you know what now happens next: An avalanche of E-Mail with zillions of attached specification documents, presentations, Excel sheets and more. After just a few weeks, nobody would ever know again which was the latest presentation, which was the agreed specification, which was the most up-to-date business plan Excel, etc. A nightmare!

What matters at launch – and this differs sharply to Roger Federer’s single achievements – is a team effort focused on a well-executed solution. It is not important who wrote what, but what we wrote. A solid specification is a collaborative effort. Thus we were looking for a highly collaborative platform for specification and documentation: A Wiki.

Wikipedia is well known to all. Within no time it surpassed the venerable Encyclopedia Britannica. Collaborative editing proofed a wining concept. A little less known is that the same technique may be applied to company internal collaboration, too. At least back in 2005 it was a novel concept.

A Wiki enables documents to be written collaboratively using a Web browser. Its main advantages are:

• Collaborative authoring: Anyone can access any page and edit any page
• Everybody sees what’s happening
• Each page has a stable URL
• Automatic versioning for documents
• Search across the entire Wiki

Basically it’s massively distributable collaboration: People located at different places can work on the same document.  

I don’t want to hide a number of disadvantages I came across spanning four years of excessive Wiki usage:  

• It requires Internet connectivity to collaborate. Offline is off work. Happened to us when our service provider once put us offline for two (sic!) days.
• The flexibility of a Wiki's structure can mean that information becomes disorganized. A Wiki needs constant care.

The adaption curve was not a linear road. For quite some users to work with a Wiki was a laborious task at first. You edit online and all colleagues immediately see what you do was an odd notion. Plus we realized that the MediaWiki [ http://en.wikipedia.org/wiki/MediaWiki ] syntax proved quite difficult for some users: Some clever clogs simply attached word documents to Wiki pages.

Over Christmas 2005 Toni and myself evaluated a number of alternatives. We wanted a Wiki with a rich text editor for people to avoid the Wiki markup. We choose Confluence from at the time little known Australian startup called Atlassian. A choice we stuck to ever since. As a matter of fact, a couple of friends from liip, namics, Zeix, Blogwerk, PubliGroupe et al. came to learn from us and subsequently introduced and enhanced Wikis in their companies (in case you want a live demo contact any of us).

No surprise then that pretty much the first thing we set up when starting to think about our new company back in 2007 was a Wiki. We could asynchronously work over weekends and late at night and yet still see at the very same time what the others were doing.

Today we collaboratively work in our Wiki on specifications, technical documentation, business issues, project management, bookkeeping, people affairs and we open up our Wiki for our cooperation partners. What counts is not the single genius but the joint effort.

Goethe would have approved.

Next in the series how to build a scalable startup: Process & control.

_______

Stillinger J., “Multiple Authorship and the Myth of Solitary Genius”, Oxford: Oxford University Press, 1991.

Friedell E., "Die Kulturgeschichte der Neuzeit", originally published in 3 volumes, Vienna, 1927-1931, München: Beck, 1996.

Most smaller and larger organizations are stuffed with folks holding the title “project manager”. For starters: These jobs are probably the most essential jobs any company has. If your engineers aren’t good, you sure have erroneous code, but persistence will fix the issues. If your marketing folks aren’t good you sure will have a difficult time getting the message out, but a bit of external help will make up leeway. If management is no good, the board hopefully fixes this issue quickly. Yet if a project manager fails you’re in deep trouble. Why? She’s the one that holds together the strings of a project (1). If she’s good, things – aka projects – just happen. In case he holds the strings together poorly, the project will most likely end up an utter failure.

Yet, most organizations have way too many project managers on their payroll doing way too many futile things. This report, that chart, lots of meetings, more E-Mail. Their bottom line contribution: Zero, worse, probably negative.

Why? Let me explain.

Most organizations are led by business people (as opposed to engineers). Both groups tend to mingle mostly among like-minded people. It’s simply easier to find a common language. As a consequence business people tend to hire business people, i.e. ‘project managers’. And as most organizations have always lots of things to accomplish (not least to satisfy the egos of some higher ups), a lot of project managers get hired.

The outcome: an oversupply of project management folks. At the same time the number of engineers stays mostly the same (You know, focus on costs and headcount and all that…).

The result is an oversupply of project management resources compared to engineering resources. The following figure illustrates this point: disk A denotes the available project management resources. These generate a equally sized demand for engineering resources (this being the maximum load this project manager team is able to handle in terms of projects, tasks and workloads). Disk B represents the available engineering resources.

The effect is a significant oversupply of A versus B. In a market economy there are two possible solutions to this imbalance. Price and or quantities available in the market space will adapt until the market clears.

Unfortunately this is not the free market but the rather closed compound of a firm. So what will happen?

Each project manager has been given a specific set of goals. Yet the available engineering resources will not match the combined demand by all project mangers. The consequence is fierce political infighting over scarce resources (2). People start to focus on internal politics instead of external product value for your customer.

First observation: Too many project managers ensure internal feuding instead of external customer focus.

We tried to avoid such a situation at local.ch. We basically never employed a project manager. How did we do it

• In a team of 32 (3) of which 22 were engineers, we had two engineering directors. Their task was to ensure a smooth engineering operation. On the one hand they were the prime interlocutors for the business people with their requirements. Second, they were responsible for the overall engineering direction. This did involve only a minimal part of day-to-day project management.  
• As outlined in the previous post, we split the local.ch platform into several building blocks and assigned a team and team lead to each block (we had a frontend, a backend, a classifieds, a guide, a mobile, a mapping, a product, a sysadmin team, though a couple of people were in several teams).
• Each team was responsible for its own objectives, tasks and their timely execution. Each team was tasked to ensure that its individual plans would not collide with the plans of adjacent teams and their respective release plans.  
• We met every Thursday to commonly elaborate and agree the main release goals. We started with a general update on the progress of the entire platform, followed by a coordination meeting attended by all team leads plus whoever had an issue to raise. Once this overall release plan was agreed to, we delegated everything else to the teams. We tried hard to limit these Thursday discussions to the most top level items only, delegating all subsequent detail discussions and decision making to the parties directly involved. When I say “tried hard”: we tried to stay focused, but sometimes fell short (4). But who doesn’t occasionally?
• We relied extensively on agile development methods. More on that in the next post.

The result – with all shortcomings – were very dedicated teams. They rose to their responsibilities and started to own the issues. They took pride in getting things done quickly, efficiently and effectively without much management. Things just happened. And they happened quickly: In the frontend team we were on nearly a daily release cycles, in the backend team they were not far behind.

Second observation: true responsibility is a powerful motivator.

The basic recipe is a transparent split of building blocks and assigned responsibilities. Plus maximum delegation of decision-making combined with a set a set of simple and commonly shared ground rules. And then get out of the way and let excellent people do their job.

Next in the series how to build a scalable startup: Scrum.

_______ 

(1) For proponents of the Spider versus Starfish theme: Even a pretty self-organizing team, will need some time to re-calibrate if you take out the team leader.  

(2) There is another solution though: Reduce the number of project managers up to below available engineering resources. But then again, who wants to cut those project roadmaps to size?

(3) Of these 35 colleagues, 25 were on the local.ch payroll, long-term partner companies employed 7.

(4) For readers from local.ch and friends: I know, we all did live up to this better pre-Amundsen. For all other readers: Contact me for details.

I am writing this in our hotel in Silicon Valley. I am here as a member of the Swiss Silicon Valley Association. It is a week long trip touring the valley, visiting various companies and Universities such as Sun, Google, Stanford University, Berkeley, Radar Networks. Fun and very valuable input to our work at Nektoon.

Two things struck me during the past days. First, the valley is large in its geographical expanse – at least for somebody from Switzerland – and yet it has the feel of a small village. There are hardly any highrise buildings. Old Palo Alto main street is about as exciting as the main street of Wil. Yet, the names reverberate in my years: Menlo Park, Mountain View, Palo Alto, Sunnyvale. Before coming here, I imagined this to be big cities in themselves, packed and bustling with activity. So many companies are located here. Yet the feel is distinctly small townish.    

Second, this observation translates to the companies as well. You see the company signs in this or that business park. Illustrious names: Sun, Oracle, Salesforce, Netlogic, Mozilla, Oracle, Apple, etc. From afar I often thought: This must be a mighty and big places. Yet standing here, it is about the same as passing say the Technopark in Zurich.  

It seems to me that the company founders simply never wanted to leave university and replicated the campus feel of Stanford University to their workplaces. Sure, Sun is a large behemoth; sure Google is not that smallish startup company anymore. But even these places, especially Google, have that distinctive campus feeling.

On the campus at Stanford we were visiting the Center for Foresight and Innovation. The department provides one of the more sought after classes: Industrial design. The students are together for one year developing on behalf of a company a working prototype. A small team put together to solve a big problem.

From the experience at our previous gig, I strongly believe that smaller and independent teams produce better results. You focus on the issue at hand, instead of coordination and issue handling within and between big teams. There is surely a wide body of research literature on this. I keep it with the findings of this book “The Starfish and the Spider” by Ori Brafman and Rod A. Beckstrom, and confirm their findings: The spider, with its brain, head and body, represents hierarchal order. In contrast, the starfish, an undifferentiated neural network, represents decentralization. Generally, Starfish organizations are far more flexible and adaptive than spider organizations. At local.ch we adapted as much as possible to this type of organization. Instead of issuing codes of conduct and direct orders we set out 9 golden rules – call them norms of behavior, and made sure that all understood the common goal of the platform. Then we let the teams pretty much figure out themselves how to go along.

To ease this process we split the platform into different parts and defined the interfaces between these building blocks. The teams could now work pretty independently on their parts, without having to overly liaise with the other teams and their may be differing timelines.

In addition we developed a set of work practices adapted to this work style. Cédric, the driver behind all of this, wrote about the setup in his blog. To glue the independent teams together and to ensure that there is lot's of communication within the teams we used Skype chat. Skype has the unique feature that chat is historized – when I come back and start my computer the chat meanwhile messages exchanged show up. The second success factor we found is the widespread use of Wiki and task tracking software (more of that in a forthcoming post). Plus we put up whiteboards on every wall possible to allow for quick and visual problem resolution.  

In the beginning a few employees had some issues with this approach. But once the folks realized that they are really and fully in charge they took the responsibility and started owning their issues. The book and our experience confirm the findings of Cyril Northcote Parkinson in his famous study on optimal team sizes (link to pdf): “When any organizational entity expands beyond 21 members, the real power will be in some smaller body”. Powerful small teams are better at execution (1).

Next in the series how to build a scalable startup: Project management.

______

(1) By the way: Never create teams of eight. They fail abysmally. You don’t agree? Read this  

It was a fun and exciting day in Venice Beach. We were heading home to our budget hotel in downtown Los Angeles. Little did we know what excitement was still to come.

It was in the summer of 1988 during the summer school recess. My best friend Daniel and myself traveled for 5 weeks through the USA on a Greyhound Ameripass. An epic journey from coast to coast. On that fateful Saturday we were the second night in Los Angeles. To cover for our travel expenses I had American Express Travelers Cheques, Daniel had cheques from another issuer.

In our room we made a bad discovery: Our room safe was broken open. The travelers cheques gone.

The break-in came as a shock. Okay, the hotel wasn’t a five star hotel, but it was probably still the most expensive hotel on our shoestring trip. It was Saturday evening and we carried only very little cash: We were broke and jittery.

In distress I called American Express to block the cheques. After just a few moments I had a polite Amex representative on the line. I explained my case in my best high school English. A little moment later I had a German speaking agent on the line. That eased the proceedings considerably. I detailed what happened and no more than ten (10!) minutes later the case was solved: Amex offered replacement travelers cheques to be picked up at any Amex office of our convenience (When we arrived in Las Vegas the day after – a Sunday – the office clerk had everything ready) and they even dispatched a messenger – it was Saturday evening by now after 11pm! – with $200 cash to cover for all expenses until then.

Even today I am pleasantly surprised by their service. We were two poor high school students and surely not high-worth clients. Yet Amex helped, even providing assistance in our mother tongue and dispatching a courier on a Saturday evening. What a difference with Daniel’s travelers cheques issuer. We had to spend two hours in a downtown LA police station to get a police report the issuer requested. The police escorted us back to the hotel, because they deemed it unsafe to walk. And we chased the replacement cheques for the next two weeks.

No prices for guessing which credit card I signed up to the moment I could afford one. I’ve been a member ever since on just that basic assumption: Whenever I am in trouble again on a trip Amex will help. Amex earned back their ’88 investment many times over.

First observation: Put your customer first and your customer will put you first, too.

I know: It’s a worn saying “put your customer first”. However, how many times have you been let down lately by a company you trust? At our previous gig we tried to live up to above outlined standards. We had a simple rule: Customer first. Illustration: On each page users can provide feedback. And feedback we got! Funny feedback, lousy feedback, good suggestions, deserved criticism and well earned praise.

Kerstin and myself spent countless hours answering every feedback (3). We got much out of this: We could resolve the issues of a large number of our users and ad clients. Example: Back in 2008 we received an angry E-Mail from the mayor of the municipality of Charrat in the canton of Wallis. They changed some weeks on beforehand parts of their street naming and our map wasn’t reflecting these changes. After a longer conversation with the mayor his anger gave way to satisfaction. We provided him with a detailed explanation of the current situation and how to change.

Second observation: Each (negative) feedback is an opportunity.

There is a fine line between listening to feedback – adapting your service – and ignoring feedback – keeping your service the same. Mostly, only a tiny fraction of your customers speak out. They are the vocal minority as opposed to the silent majority. Therefore before deciding on adapt or ignore we always tried figure out how a proposed change or status quo would affect all of our customers. We tried hard to aggregate the feedback into meaningful categories. And often we tested the alterations extensively. How to decide: Change if this modification can make at least one individual better off without making any other individual worse. The better you do this, the closer you are at a Pareto optimum.

Next in the series how to build a scalable startup: Smaller organizations.

_______

(1) At the end of the conversation I asked where the agent was sitting. She was based in Utah. I later discovered why: A lot of folks of Mormon religion travel the world after school. On returning they bring home souvenirs and foreign language skills. Should I ever want to open a call center in the US, the first place I will go is Utah. 

(2) Since, I’ve been coming across this story: May be Amex is changing after all to the worse? I sincerely do not hope so.

(3) Flowers where flowers belong to: Kerstin in her unrelenting manner answered much more feedback than I did, and surely her answers were ever more to the point than mine.

This post may be reduced to the max: Hire better than yourself.

A startup is like an extreme sports crew doing team bungy jumping in the morning, some swamp soccer for lunch and a bit of high-risk river rafting in the afternoon to get clean again.

Do it alone? No chance.

To succeed you’d better be a good team. A really good team, actually. Your survival depends on your teammates. So you better select your teammates carefully. And ideally they are better than you. Because the moment you jump, you want to be sure that your mates fixed the bungee rope well; because your teammate may mark the goal that you missed; because with your power subsiding, they may still plough the river’s rapids.

Obvious truths you chip in?

Yes, and yet I observed quite a number of organizations behaving quite differently indeed.

A startup experience is a roller-coaster ride of failure and success, of sensations and passion, a mix of persistence and perseverance. Simply, intense emotions. It’s fun, it’s tough, it’s rough, it’s highly rewarding. Who do you want to have with you on that journey?

Guy Kawasaki, a renowned entrepreneur, puts it this way:

“In the Macintosh Division, we had a saying, “A player hire A players; B players hire C players”--meaning that great people hire great people. On the other hand, mediocre people hire candidates who are not as good as they are, so they can feel superior to them. (If you start down this slippery slope, you'll soon end up with Z players; this is called The Bozo Explosion. It is followed by The Layoff.) I have come to believe that we were wrong--A players hire A+ players, not merely A players. It takes self-confidence and self-awareness, but it's the only way to build a great team.”

It’s a bit like recruiting a squad of first-rate people and get them to do serious stuff. It’s a bit like selecting and training a football team. The selection of who’s in is essential. Yet, the quality of the players is a necessary but not sufficient pre-condition. It requires hard training to get to the top league and remain there.

At a recent event we were asked how we did it. There is not a single answer. Rather a collection of bits and pieces that form our experience.

Most recruitment talks last about an hour. The interviewer and the interviewee talk about the latter’s CV and the future job. Both sides have a strong incentive to cheat. The employer tries to paint the future job as interesting, full of opportunities, full of promise, full of perspectives. The job applicant portrays his past accomplishments in a jubilant tone.

This is mumbo jumbo talk, an unaccommodating palaver. Both sides are not much better than a greasy backyard car dealer. And worse to come, quite often an offer is made without any further clarifications or any further talks to future co-workers. No wonder that this turns sour quickly.

First observation: Get recruiting right.

Recruiting is like a blind date. Before the date, i.e. the job interview, both sides often know as much about each other as two hormone driven singles on the way to their first date: A basic profile, i.e. CV, a couple of E-Mails, a brief instant messaging chat. And dating experience shows: It’s a bad idea to commit with your brain sedated by a couple of gin tonics. The chance to upgrade to the next level is minuscule.

Recruiting needs time. Lot’s of it: Several rounds of interviews are our norm, calling up references, serious discussions with all involved, and sufficient time to let the decision mature before even entering into contract negotiations. Both sides want to be sure that it is a fit. Once you are committed, though, you should act decisively and proceed swiftly to get your new employee on board.

This upfront investment may sound expensive. Yet, any dismissal and subsequent re-hiring are way more expensive.

Once your new colleague is joining the ranks, you must make sure he or she is integrated quickly and thoroughly into the team.

Second observation: Get the assimilation right.

Quite often your first day is nice: Some flowers on your table, a brief meeting with your new boss, an even briefer encounter with your bosses boss. The secretary – nowadays lovingly referred to as office manager – walks you around. Later you sit in your cubicle, a white page with your IT credentials in front of you and you don’t know what to do. You feel left out. Over there you hear an intense discussion, here somebody passing, nodding in your direction yet not stopping, your first assignment (read the company manuals) completed and no other assignments in sight. A growing feeling of frustration sets in.

A company is more than its products. It’s an essential set of values, of believes, of rules and process. How on earth can you let that pour soul alone?! Sure most companies offer newcomer training, some get-together. But that’s it. By far not enough to pass on the company essentials.

How to do it differently? Do all of the above plus much more: Do assign someone from the team as mentor and make him accountable for a successful assimilation program, do regular meetings with all involved, create follow-up course, go to an off-site meeting, etc. etc. Basically invest time.

I call it the bow wave recruitment process: We willingly invest upfront seemingly unreasonable amounts of time for hiring and assimilation. The alternative: jigsaw recruitment. You save a few hours and bucks upfront, but you pay dearly later: People quitting, re-hiring, and so on.

Figure 1 - Bow wave versus jigsaw recruitment strategy

In concluding, it’s like forming and sustaining a wining football team: The player selection is essential; the continuous training is as essential. You have a bunch of stars (Get rid of those that just think they are stars). Now get them to play well: The coach recognizes the specific talents of each team member, and should be able to tease out the very best of each of them and in combination between them. The main question is: How to contribute to a compact, dependable, focused and hungry team? How can we get the very best out of each other? How can we surpass ourselves and do that bungee jump, master these dangerous river rapids, and score that unscorable goal.

Next in the series how to build a scalable startup: Rule #1.

This is a first in a series on how to build a scalable startup.

In this series we outline some aspects of how we did scale our previous company from zero revenue to a figure well above CHF 41 million p.a. with a highly positive net result(1) within four years, what we learned from it and on what we pay particular attention for our next startup Nektoon.

What is a scalable startup? Expressed in monetary terms: the revenue curve grows more rapidly than the cost curve. To put it simply: As of hitting intersection A in below figure your startup turns a profit and starts to pay back incurred startup costs.

Figure 1 - Startup Costs & Revenues

That’s at least the expected pattern after an initial setup and investment phase. However, this is a bit simplistic, I’m afraid.

At the heart of every company, especially startups, are its people. They are the essence of any company. And people don’t scale. In the morning between the hours 9am to 10am you can do one thing and be present in one spot, do one sales pitch, head one meeting, etc. That is one of the list, not two, not three, but only one item at a time. So a scalable startup is to some extent a myth.

Yet if you can’t scale your startup you aren’t likely ever to earn a decent salary or cash in big time on your shares. How to circumvent this contradiction?

Organizations - A lump of butter

Before going to some minutiae about scaling let’s start with the question "What are organizations?” The subject produced an entertaining and varied body of literature. We do not discuss this here in full but just state the obvious: many if not most of the big international organizations are perceived by the rank and file and actually most customers as dinosaurs. Sure some are gentler than others, some nimbler than others, but fossils still.

The average manager passes his or her days working their E-Mail client or on the move their Blackberries, producing E-Mails with cc lists next to which any decent VIP guest list at an average club pales. Mostly they attach large Powerpoint presentations, lengthy Word memos and garbled Excels. Now with the exception of some printed contracts emanating from Word I never saw a proper business earning a mainstay in the marketplace on just that: MS-Office output (2).

First observation: Real work is mostly something else than MS-Office output.

Yet corporate offices thrive on that stuff. The problem is just: this doesn’t scale. Sure the cc list scales, but this has no notable impact on the bottom line.

Second observation: Large organizations exist.

“[Aren’t firms like] islands of conscious power in the ocean of unconscious co-operation like lumps of butter coagulating in a pail of butter-milk?” (Robertson 1928, 85)

The body of literature on the reasons of existence of the firm is as wide as this ocean of milk. Two of the more influential books on the subject were written by Ronald Coase – The Nature of the Firm (1937), and Peter Drucker – The Concept of the Corporation (1946).

Coase was the first to note that there are transaction costs involved in using markets to exchange goods and services. The cost of obtaining goods or services may add substantially to the price of the good or service. Previous economic theory held that in efficient markets it is always cheaper to contract out than to hire. Coase suggested that firms will arise when they can produce cheaper internally.

Coase was already aware of the decreasing returns to the entrepreneur function. It took management guru Peter F. Drucker to table the first thorough study into the nature of corporations. In his seminal book Concept of the Corporation he studied mighty General Motors. They were very pleased with his book until they discovered to their dismay his suggestion to decentralise the company in order to even become more successful (Something they took only a bit more than 60 years to digest and finally start doing).

So, firms are indeed like a block of butter.

Next in the series how to build a scalable startup: Focus on people

_______

Robertson 1928 Robertson D.H., The Control of Industry, revised edition, London: Nisbet, 1928, as cited in Malmgren H.B., “Information, Expectations, and the Theory of the Firm”, Quarterly Journal of Economics, LXXV, 1961, pp. 399-421.

(1) local.ch is part of the joint-venture between stock traded Swisscom and PubliGroupe and does not disclose any detailed financial information. Nektoon is privately held.

(2) The notable exception being consulting companies that perfected the art of delivering nothing for something; see the delightful book Consulting Demons.

A lot of people labor their day away without much thought at what they do. They don’t take a particular interest in what they do, nor are they particularly proud on what they do. They exchange time for money.

What a waste of time, talent and work.

Example: on many Swiss trains there is a Minibar service. A little trolley serving coffee, tea, croissants in the morning, sandwiches later in the day. A steward accompanies the trolley. And these folks often look like a sheepdog on the sixth day of rain. Not a faint smile; not a hello when passing; conversation is reduced to basics: customer “Coffee”, the reply after serving “3.80 please”. Not an experience to repeat (even though the coffee served got remarkably better – and a lot more expensive).

There is the odd man out: a steward often doing the Lucerne Zurich line. He comes singing and praising the day and any of his customers. He wishes everyone a nice day whether you buy something or not, and if you buy a coffee the croissant is just a smile away. A superb steward with satisfaction in what he’s doing and pride in his work.

Why this difference between him and the rest of the stewards?

In the days when international rail travel still counted for something, the company was called SSG – Schweizerische Speisewagengesellschaft. Starting in the 90ties a series of mergers, acquisitions and rebranding followed. There was a co-operation with the railway restaurant owners, a rebranding as Passagio Rail together with a take-over by Autogrill, an Italian company, a merger with the Swiss part of Mitropa, a rebranding as Elvetino, recently it was folded back into the federal railways, and I probably miss an act or two of this saga.

Over a countless number of management changes the company has probably been reduced to a set of Excel sheets without spirit. People up in management simply pressed and press the lemon ever more based on tour reports and other filtered information. I am a regular train passenger. In the past years I never saw a manager accompanying a steward to get street (better: train) smart.

The consequences: shrinking turnover, increasing personal turnover, shrinking results, increasing management stress, evaporating company spirit, and at the end a devalued and run down company with a notable exception or two. No wonder that the company has been reshuffled about every three to four years.

It needs not to be that way.

A vocation can be more than just a work (V). Active interest in what you do and pride on what you do will change everything. Run the equation. Set interest or appeal in your work (I) and pride (P) each to zero and you have just work. Invest in both and the same amount of work will produce far superior results. No matter how you measure interest and pride, any value above zero will do the trick.

You say, tedious work like running a Minibar up and down a train can neither be interesting nor particularly satisfactory? Wrong. As student I earned my living doing exactly this: running Minibars up and down trains. At the time we had some superiors who knew how to instill a certain sense of mission in us stewards. We took a keen interest in what we did and were proud working for the railway. From time to time a superior accompanied us, improving our steward skills and praising us on our achievements. Success was celebrated and it was a fun atmosphere. Even on the fully packed Sunday evening Zurich to Geneva Intercity train Müller III and myself had much excitement working the aisles. On arriving at midnight in Geneva, we regularly booked record revenues. Something that counts, if you’re just paid by commission.

It boils down to a simple management ground rule: focus on people, not on numbers.

A more academic but exciting view on the same subject was Barry Schwartz’s talk at this year’s TED conference: let people do the right thing - focus on virtue, character and practical wisdom instead of rules, bureaucracy and incentives. 

As a sidekick to our current gig, we perform a bit of consulting. A fiddly way to preserve cash (What do I do at 8am? Work for my client thus creating a chargeable hour thus neglecting the actual reason of being of our company, or work full speed for the glory of our startup and burning cash. A wicked choice at times.)

The other day somebody contacted me to get a bit of advice for her new startup idea (anyone else interested in no-nonsense, hands on counsel, please contact us at “info at nektoon dot net”). It’s something about – ouch, I am not allowed to tell you. As a matter of fact she required me to sign a weird legal document lovingly referred to as Non-Disclosure Document (NDA) first.

The basic mechanism is easy: Before talking about your grandiose invention with somebody else, you let that party sign a document stating that all discussions and materials disclosed during those discussions remain confidential under the threat of heavy fines.

In principle a fine idea. In the context of a startup there are just a number of little snags.

For starters: Basically you want somebody to sign a NDA who you don’t completely trust. Well if you don’t trust somebody, then don’t do business with that somebody.

A NDA also rests on the assumption that the opposite party has droves of idling people hanging around and waiting for the moment that you disclose your brilliant idea to steal it and implement it on their own. Well that is not the case. The other company is either in an adjacent or tertiary business. They have other things to do and no company can afford hordes of clever people on the beach. And lastly: If you go straight to your competitor - your fault.

Plus, as a startup you anyway don’t have the means to enforce a NDA and pursue a breach of contract. You simply don’t want to invest the time and the money litigation would require.

Sure, large corporations fancy these NDAs but mostly for altogether other reasons: Some middle manager wants to cover his ass.

Clearly, there are instances where you should make your opposite party sign a NDA. In the moment you talk to any banker or lawyer. They are used to this paperwork and should you forfeit your chance of a bit of small talk over the signing of the NDA, you will miss out later. The others will definitely miss something and make you feel it.

Talking of banks: A couple of years ago we developed Website solutions for a number of large banks all sitting atop each other at a quite small place. Each made us sign such a NDA with lots of penalty clauses included if we ever talked to one of their competitors about that bank’s particular setting. Each of the banks asked us immediately after signing what we can tell them about internal matters at the other banks…

In the end, protective paranoia is not the answer. A reputation built on trust and hard work protects your idea better. Getting a successful product to market should give you all the profits you need to defend yourself via litigation if it should be necessary. If it won't, you are probably proceeding with the wrong product idea.