≡ Menu
Pawel Brodzinski on Software Project Management

12 Steps to Kill a Company

Here’s a quick guide how to kill a software company.

1. Analyze all your projects. Kill ones, which aren’t directly connected with planned income. No R&D. No product development. That’s unjustified expense.

2. Focus on formal acceptances and then forget about projects. Investing effort in projects which are already paid is unnecessary and unwise.

3. Forget about quality. No one would pay for the quality. And it’s much cheaper to develop some string-and-bubble-gum solution.

4. Trick your clients. It’s not about delivering them solutions they’ll be happy with. It’s all about soaking money out of them. Being honest doesn’t bring you closer to the goal.

5. Expect you’ll be asked how to deal with every problem. When people decide to deal with issues on their own yell at them. Tell them they’re wrong and they should look for a solution somewhere else.

6. Fire some people. Show the rest they should be afraid of you. Show them you have a big gun and you won’t hesitate to use it.

7. Let people go. When someone wants to leave let the damn traitor go. There wouldn’t be any use of him anyway. And you cut costs too which is a great move during recession.

8. Force people to do tasks they don’t like. More of them will go.

9. Don’t show up too often. Show people you have a lot of important things to deal with and you just can’t be in the office every single day to hear their complaints.

10. Don’t talk with people. They can’t tell you anything interesting. And talking with them is a waste of time. Your time. Your precious time.

11. Don’t trust your team. Don’t tell them anything important. Cross-check each thing you hear. Show them they can’t cheat you.

12. Lie when someone asks tough questions. It’s easier to sell some made-up crap than to face a problem. When they find out the pattern they’ll stop coming to ask you anyway. A win-win scenario.

in: entrepreneurship, software business, team management

4 comments… add one

  • Glen B. Alleman January 30, 2009, 11:09 am

    Pawel,
    I can see everything except 1 and maybe 2.
    If a team is spending budget in a commerical enterprise, they should have notion of how the firm will recoop their investment. What is th eprimary reason for their work?
    What does “done” look like for a project? When should the firm stop making it “better?”

  • Pawel Brodzinski January 30, 2009, 11:40 am

    Maybe I’m biased but for me not moving forward means moving back.

    If the company works on custom projects only and each of them is different from the rest 1 may be irrelevant. You do what clients tell you to do and so you don’t work on products (understood as software implemented repeatedly). That’s more about delivering services. Then you don’t have to think much about product development. However I find a situation when the firm isn’t able to repeat implementations very rare. If you can implement the same piece of software twice or more you’ll do it because you maximize your profits this way. And then you have to improve your product. Stopping development will result in losing market chances thus losing money.

    Of course in each case we could discuss what done means, but I’m yet to see:
    – a software product which can’t be improve
    – a software product whose users don’t want new features
    – a software product which is perfect for every potential customer and there’s no need to adjust it

    At least it is so in markets I worked in. I have no experience in areas you specialize in so the perspective can differ.

  • Joanna Grzywna March 6, 2009, 3:43 am

    Nice summary of thing that really happened recently :)

  • Pawel Brodzinski March 6, 2009, 3:48 am

    Actually there is a place which was my role model on the subject, although it’s fairly typical when some mess ends up in dead body instead of great perspectives which were on banners of people bringing new order.

Leave a Comment