An oldish but still useful post on how to demo software by Joel Spolsky.
The only interesting way to design a demo is to make it a story. You have a protagonist, and the protagonist has a problem, and they use the software, and they... almost solve the problem, but not quite, and then everybody is in suspense, while you tell them some boring stuff that doesn't fit anywhere else, but they're still listening raptly because they're waiting to hear the resolution to the suspenseful story, and then (ah!) you solve the protagonists last problem, and all is well. There is a reason people have been sitting around telling stories around campfires for the last million years or so: people like stories.
As with all advice, Spolsky's rules should be tuned to your purposes but the ideas are solid for anyone who talks to groups of people. (via stamen)
Joel Spolsky, popular tech writer and founder of Fog Creek Software, has an article in the September 2008 issue of Inc. called How Hard Could It Be: How I Learned to Love Middle Managers. In it, Spolsky details how he came to the idea of building a small company where middle management was unnecessary. He took particular inspiration from an article he read about a GE plant.
It was about a General Electric plant in Durham, North Carolina, that made jet engines, and it offered a portrait of the perfect work environment: a factory that had more than 170 employees but just one boss. All the engine technicians reported directly to the plant manager, who did not have the time or the inclination to micromanage. There was no time clock, and people set their own schedules. Pay was egalitarian (there were only three pay grades), and workers who assembled the engines could switch tasks each day so their jobs were not monotonous. The result? In terms of quality, the plant was nearly perfect. Three-quarters of the engines it produced were flawless, and the remaining 25 percent typically had only a slight cosmetic defect.
The no-management rule worked at Fog Creek for a time but as the employee count crept up, cracks appeared in the system. Employees became disgrunted, in part because of a perceived lack of availability of the only two members of management, the CEO (Spolsky) and the president. To fix the problem, Fog Creek established a small layer of middle management.
First, we eliminated the need to get both me and Michael in the room. You have a question? I'm the CEO. Talk to me. If I want to consult with Michael, that's my problem, not yours. Second, we appointed leaders for two of the programming teams -- in effect, creating that layer of hierarchy that I had tried to avoid.
And frankly, people here seem to be happier with a little bit of middle management. Not middle management that's going to overrule the decisions they make on their own. Not symbolic middle management that only makes people feel important. But middle management that creates useful channels of communication. If my job is getting obstacles out of the way so my employees can get their work done, these managers exist so that, when an employee has a local problem, there's someone there, in the office next door, whom they can talk to.
Given his inital progressive approach to building a company, I'm surprised that Spolsky didn't try something a bit different. For instance, Adaptive Path is structured using an advocate system. AP co-founder Peter Merholz explained the system to me via email.
It's a way of avoiding typical management structures, where you have people reporting up a hierarchy. Our current structure has two levels... Executive management, and everyone else. That "everyone else" doesn't report to the executive management. Instead, the report to one another through the advocate system. Each employee has an advocate. An advocate is like a manager, except they don't tell you what to do. They are there to help you achieve what you want, professionally. Employees choose their own advocates. They simply ask someone if they would be their advocate.
Merholz allows that what the advocacy system doesn't help with is communication across the organization -- the very problem that was plaguing Fog Creek -- and would likely work best alongside a light layer of middle management. But with the right guidelines and some slight changes, I believe it could work well in a company of 20-30 employees.
The Grey Dog's Coffee restaurants -- there are two locations in Manhattan -- use a slightly different system of rotating management. Co-owner David Ethan explains.
From a historic perspective, I like to think that it's one of the few truly bohemian places left in New York City, just based on the way we run it, like a commune. The management system here is that everybody manages. In order to work here you have two tries to show you can manage the place and if you can't, you're fired. Everybody manages about one shift a week and everybody's equal. People work hard for each other. I don't want to let you down because tomorrow it will be me. And I think they enjoy the responsibility of running a New York City restaurant. They get to pick the music, set the vibe, the lighting, everything. And they're all pretty laid back, so it's got a bohemian nature.
Running a restaurant each day and operating a software development company are quite different (for one thing, having a new boss every week wouldn't work at a company like Fog Creek), but rotating managers on a project-by-project basis might work well. (BTW, I think Adaptive Path at one point rotated the presidency of the company through each of the founders in one-year chunks.)
Pentagram's organizational structure provides a third possible way of avoiding a traditional system of middle management...although probably less germane to the Fog Creek situation than the previous two examples. The company is composed of several loosely connected teams that operate more or less autonomously while sharing some necessary services. Pentagram partner Paula Scher explained the system in her book, Make It Bigger.
As a design firm Pentagram's structure is unique; it is essentially a group of small businesses linked together financially through necessary services and through mutual interests. Each partner maintains a design team, usually consisting of a senior designer, a couple of junior designers, and a project coordinator. The partners share accounting services, secretarial and reception services, and maintain a shared archive. Pentagram partners are responsible for attracting and developing their own business, but they pool their billings, draw the same salary, and share profit in the form of an annual bonus. It's a cooperative...
She goes on to add:
Pentagram's unique structure enabled me to operate as if I were a principal at a powerful corporate design firm while maintaining the individuality of a small practitioner.
Working small with the resources of a bigger firm, that's the common thread here. I imagine there are many more similar approaches but these are a few I've run across in the past couple of years.