The guys at 37signals not only have an eye for details, but also an ear for their customers. Only 36 hours after launching their web-based CRM tool Highrise, they announced changing their usage plans in response to customer feedback.
For example, there's now a "Solo" plan for lone warriors that need lots of the features of the "Plus" plan, but no additional user accounts. And every plan had its storage space increased.
It's so easy to conquer your market. Just switch from "Know your enemy" to "Listen to your customer".
"I ask you, where else can you catch a behind-the-scenes glance of some very awesome people?"
Awesome" might be a bit of a stretch in the case of "Rockstartup.com This website (from where I got the quote above) claims to be a reality TV show about the infamous web startup PayPerPost.com. I can only guess that the purpose of Rockstartup is to display PPP as a hip, relentlessly honest and real hands-on startup.
But watching these two episodes only conveyed to me that PPP has to be a bunch of clueless dolts:
The IT guys are in real stress. But that doesn't surprise me, seeing how they determine their project deadlines. This time, the change has to be finished for the board meeting. If they hold their board meetings periodically, this probably isn't a very realistic way of setting milestones.
I sympathize with how they crap their pants deploying live. It seems that there wasn't time for testing at all. In their place, I would get the heebeejeebees, too. But in their place, I would also refuse responsibility completely. I may handle my personal web server that way. But if you have a serious business, deploying untested versions is pure negligence. And they get what they deserve -- the site goes down.
It may be the way the video clip is cut, but it seems like the team lead is reporting immediately to his boss (which is the CEO of PPP) that "a network circuit blew." I'll have to watch it again to look if there's a BOFH excuse calendar somewhere...
And it gets worse:
All right, PPP has guys running around claiming the title "Code Ninja" who test a secret new feature on their public blog because that's the only one they have. And they don't seem to mind very much. Let it put me another way: they don't seem to have much of a mind.
Another brilliant idea demonstrated is executing database queries on the production database. Whoops, forgot the WHERE clause. Database FUBAR. Well, there's always the backup. Oh, there isn't? Hooray, site down again.
This time, by the way, it's a demonstration for investors that's putting everyone under severe pressure.
I wonder if these people don't know better or if they just are denied the necessary resources, mainly time and budget, to do their jobs right. Working in the IT department of one of Germany's biggest web companies, I know how doing the job right looks like:
- When determining project deadlines, you make sure everyone has the same understanding of issues and consequences. That shouldn't be difficult when the CEO resides just a few tables away.
- You employ only people that know what secrecy means and are able to read the corresponding passages in their contract.
- You don't deploy software into the production system without having it tested on a staging system. For that purpose, we've built a huge VMware farm that resembles the production environment as closely as possible.
- You have people who are responsible for operating the production system and who are the only ones having the necessary access rights. Those are different people than the developers.
- You don't do manual queries on production databases that haven't been approved by the chief DBA. If you do, you don't do them at times when they can severely disrupt the service.
- You have standby databases in the case the main one is hosed. Since unintended content changes will get replicated, you also have a backup. One that's as fresh as possible and that has been proven to be recoverable.
And as a manager, I don't think humiliating your staff by making them wear a ridiculous hat if they make mistakes betters the situation. To err is human. To make people afraid of errors means adding just another source of mistakes. Your job as a leader isn't that simple. You have to determine the causes of the mistakes your people make.
- If it's lack of knowledge, train them.
- If it's pressure, improve their working conditions.
- If it's lack of resources, get them what they need.
- And if it's negligence, hold a private feedback talk to make them understand that diligence is crucial for your operation. If they keep on being stupid, don't fool around with hats. Fire them.
I really wonder if "Rockstartup" means that this company is going to sink like a rock. At least, that's the impression I got from those videos. I really put a lot of time into deciding what I write in my blog about my work and what I don't. And hey, of course there would be many juicy bits to report every week. But if I published such proof of incompetence as these clips, I'm afraid I would not only get fired but would disappear under dubious circumstances...
This is what Damien Mulley has to say about me:
Jochen Lillich is a lumberjack. He's a lumberjack and he's ok. He's a lumberjack and he's ok and he sleeps all night. This is his Twitter This is his feedburner feed He cuts down trees, skips and jumps, likes to press wild flowers.
Damien, thanks for the link love, but you're wrong. I usually don't skip and jump.
(And how do I get this tune out of my head again now?)
It's time to be afraid when your minister for economy and technology utters the following, don't you think?
Thank god I have people that operate the Internet for me.
This indeed was said by Michael Glos, german minister for economy and technology, at a visit to CeBit,6298,16863,00.html, the world's biggest IT fair.
Well, there goes the neighborhood. I guess I'll be going soon, too.
(via Indiskretion Ehrensache)
As soon as you start working with other people, you have to communicate. Especially if you have to manage a team or department or if you take part in a project, you depend on continuous information about the work of others because it affects your own work. But even between people in a department that have different areas of work, a continuous flow of information about their current work fosters transparency and the exchange of ideas and helpful hints.
For that purpose, the IT department I work in has been practising a kind of reporting named "daily" for years now where employees write a short summary of their finished work day. Recipients of this daily report usually are direct coworkers, members of a common project and other interested people throughout the company. To make sure these reports contribute to transparency instead of clutter, I ask my employees to focus on three key aspects. They're easy to remember because in german, they all start with an "e":
- Results ("Ergebnisse"): What were your achievements today, what tasks did you finish? Those are important because there almost certainly are people waiting for those results.
- Decisions ("Entscheidungen"): What did you decide to do or not to do? Since every non-trivial decision affects other people, it's good to inform them about it.
- Findings ("Erkenntnisse"): What became clear to you today, what did you learn? If you discovered interesting things, tell others about them -- they may find them profitable, too.
Recently, I added a fourth aspect:
- Good news ("Erfreuliches"): I just can't get enough of those.
As you can see, I don't see a point in reporting unfinished tasks because that would be the kind of micromanagement that makes people feel rushed and forced to waste time writing about a task instead of doing it. What use does a line like "still working on Project X" have? If Project X isn't finished yet, it's completely reasonable to suppose there's still work being done on it, isn't it? But if "a network outage prevented me from working on Project X", it's worth mentioning because that fact surely is interesting to the manager of Project X.
Until I installed a weblog software on one of our intranet servers, the dailies were sent by email. My team was the first to start blogging their dailies, and over the following weeks the other IT teams fell into line, blogging their daily results, decisions and findings. Coworkers can subscribe to each RSS feed separately, and I additionally installed a feed aggregator that delivers the collected blog entries of the whole department.
Our "Daily Blog" has become an important communication tool. Managers and coworkers get up-to-date information about what a team is working on, what's going well and what problems arose lately -- without having time-consuming meetings. And via the comment section, people can respond with questions or additions, therefore starting dialogues.
And there's another, hidden advantage: by writing about it, people deliberate about their work. So, there's not only a communication aspect, but also a reflection aspect in our blogging. Both effects combined really make the time spent writing daily blog entries worthwhile.