Another good challenge of our application: The Business Chuchi is a gathering of folks here in Zurich talking about the business aspects of online applications. Tonight was our turn. Great feedback from the folks present. Thank you!
Heute Abend spreche ich bei Reto Hartinger's Internet Briefing über neue Technologien für ein interessantes Web-Erlebnis. Am konkreten Beispiel zeige ich, welche Erfahrung wir mit Friend Feeding, Remix the Web, skalierbaren Infrastrukturen, etc. gemacht habe.
Die Slides sind hier hinterlegt (PDF, 205kb), ein Memonic Set mit den wesentlichen Links und Erkenntnissen ist hier zu finden.
“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
_______
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.
Last Thursday and Friday Patrice and myself travelled to Munich. And if you travel, you have something to tell (Citation by Matthias Claudius, 1740 - 1815).
We were invited to present Nektoon at the 5th Venture Day of Swiss Technology. Around 6pm we gathered on platform 14 at the Zurich main station. Soon Jean-Pierre Vuilleumier, the managing director of CTI Invest, joined us.
We got ourselves a place in the restaurant coach. It’s a long journey: four and a half hours for roughly 300 km. Luckily the line is about to receive an upgrade after years of neglect. Then again, this would cut short our amiable and enjoyable trip by an hour...
After aperitifs, Dominik Tarolli from Procedural joined us in St.Gallen. I knew his blog – swissstartups.com – before, yet never met him so far. Another plus of our in person get together, I finally got it what their city engine does – amazing stuff!
After some E-Mail back and forth Matthias Sala from Gbanga joined us, too. Gbanga’s wants to create interactive mobile games. They had a first test run this summer with the Zoo Zurich.
Picture by dselz
Though an interesting crowd, hunger looming I couldn’t fully kick the habit and check my Twitter stream to discover Moritz Adler from Blogwerk tweeting that he sits in that same restaurant coach. Where? Meanwhile the coach became quite crowded with Oktoberfest goers.Ah, there he was.
The six of us represent quite an interesting mix of Swiss ICT startups: Gaming, publishing, 3D rendering, fluid information and Mr. Startup Network. A few startup cock-and-bull stories later (To Dominik: Will do what you requested) we arrived in Munich where some still hit the remains of that Oktoberfest evening.
In the morning we met at the Literaturhaus in the center of Munich. How fitting: The opening speech was by Quillp, a digital book publishing site. Next to the afore mentioned there were a number of other startups from the biotech and life science (BLS) sector present.
To listen to the BLS startups was particularly fascinating. Two things struck me: We in the ICT industry are used to short development cycles. They operate in an environment where time to market is measured in years rather than in months. We may start our next venture on a shoestring; they need heavy investment over consecutive years in people and infrastructure. Obvious if you think about it, but easily forgotten if you labor day in, day out with just your notebook on our Ikea desk.
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:
Furthermore the system allows:
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:
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:
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.
Project fiascos usually have managerial consequences, and it was only a matter of time before the ripples from the great computer revolution produced a metamorphosis in the way large and complex IT projects are managed.
Luckily for us, this happened well before we were born.
That was back in a time when computers were the size of a truck. Beasts such as Univac and IBM 700s or on the other side a URAL-2 computer from the Soviet Union.
The invention of computers was closely followed by its Siamese twin: IT project failures. The history of information science is littered with such examples.
Back in the fifties and sixties line managers would perform the work required by his line organization and then throw the “ball” over the fence hoping that someone from IT development would catch it. Once thrown over the fence the line manager would wash his hands off any responsibility. In case something went wrong because the ball was no longer in his yard. The IT people claimed that the requirements were subpar and threw the ball back. However, the real problem with this approach was that the actual customer had no single contact for their questions.
This debate generated some notable books. One I like particularly is Fred Brooks’ “The Mythical Man-Month: Essays on Software Engineering”. It is based on his experiences at managing the IBM OS/360 project.
Back in the nineties a couple of people started to look over the fence to Japanese product engineering and software development techniques. One such technique is called Sashimi. Out of this technique grew Scrum.
The basic issue with the traditional waterfall models of project management is their focus on quality and low cost. The scrum inventors realized that software projects need in addition speed and flexibility. And they observed that there are people actually doing the project work and there are others with a more casual interest in the project’s outcome:
A pig and a chicken are walking down a road. The chicken looks at the pig and says, "Hey, why don't we open a restaurant?" The pig looks back at the chicken and says, "Good idea, what do you want to call it?" The chicken thinks about it and says, "Why don't we call it 'Ham and Eggs'?" "I don't think so," says the pig, "I'd be committed, but you'd only be involved." (Quelle)
The “pigs” are committed to building the software, while everyone else – “chickens” – is just interested but sort of indifferent to the outcome – they never committed themselves fully. This distinction plus the particular agile setup of the methodology are the distinctive marks of Scrum. Today a growing body of evidence suggests that agile methods greatly improve software quality and project success rates.
At local.ch we were using agile methods, building the platform in release cycles of about 4 weeks. Over time some teams started to use Scrum. At Nektoon we set out to apply Scrum fully right from the start.
How do we do it?
First we fixed late last year the strategic goals for 2009. These goals have been broken down into a roadmap for the year. Example: We fixed last year the goal of a beta release late spring. Today we’re one two-week sprint off this goal.
The next level is our product backlog. Here we write down the big tasks. We refer to them as stories. For each story we award a point on a scale from 1 to 5 as an indication of its complexity and difficulty.
Every other Monday morning we sit together and sort through this product backlog. First we prioritize and then in a second step we pick the stories for our next two-week sprint. In turn each story will be split into tasks. For each task we allocate an estimate on the number of hours required for completion. Then we go and work.
Important: We decided to do this not just for engineering stories but for business stories, too. Example: For marketing purposes we currently are producing a brief video clip. Thus we created a story “Video Clip”. This story and associated tasks are part of the current sprint.
Then there is the issue of controlling: Every morning we sit together and quickly go through three questions: What did I do yesterday, what will I do today, is there anything blocking me? To update everybody we create a status update in our Wiki (More on that in the next blog post).
At the end of each sprint we go through each story, demo the developed features or present the business related stories. This is important to get a feedback on overall progress.
You might say for a startup with just five people on its payroll, this is a bit too much. We think it isn’t. The pace and rhythm we set now for our company will be the pace and rhythm of our company in the future. We try to achieve a couple of simple things with this approach:
Next in the series how to build a scalable startup: Abolish MS Office.
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
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.
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 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.
| More memonic photos |
