Guide to a successful IT startup
Rule # 1: your dev team is not that important
Even if your project is an IT project, don’t be fooled: the first step to success is expanding and improving your marketing and management departments, not the dev department. Marketing and brand/product managers are the key figured, while the developers only pretend to be important and in reality they are extremely easy to replace. Will you be able to find another equally good manager? No. Managers are in great demand, while developers are in desperate search of new job all the time and you should not fuss about them at all. You know how peevish the devs are, it’s hard to find developers who will fit each other and make a really good team. So, since it is hard, just pick your devs randomly and forget about them, instead focus on other things: advertising, clients search and ordering really cool branded merchandise (you are plain crazy if you think that your project will ever be successful without mugs and t-shirts with your brand name on them).
Rule # 2: more meetings!
A working day without at least one meeting is as good as dead to the company success. People love to talk, so let them talk as much as possible — don’t worry, surely they will find some time to work later, when the meetings are over. You know what? The best scenario is meetings all day long, isn’t it heaven? Your teams will discuss EVERYTHING, nothing will be kept aside. What’s that? The actual work? Well, there’s always nighttime and weekends, and these hours should definitely be meetings-free (except for the team-building social calls which should be scheduled at least twice a month). One interesting research says that JavaScript developers strongly prefer to work at night, while Swift developers really love to work Sunday mornings and Saturday evenings, so let them do that and spend all your actual working hours on virtual coffee, sprint planning, sprint refinement, sprint follow-up and sprint failure analysis. Because, like I said, talking about work is way more important than actual work.
Rule # 3: use dev-QA
Why wasting your money on a QA department when you already have a development team? They know the code, right? So surely they can do the quality assurance themselves — it’s the same thing as code review anyway. The actual QA engineers could be a great pain in the ass, they want salary, they want attention, they always find bugs, sometimes they even find bugs in production — who do they think they are? Way better to make developers test everything, and if they start to say something like ‘I don’t have time for this, I must be working on my tickets’, well, just ignore them. Devs can behave like little children sometimes, they don’t understand that combining actual development and QA is a god-intended way to do their job. And if you still have bugs in your software even after the devs finish their QA part of work, well, it’s definitely the devs’ fault. Maybe punish them a little, pay a bit less, add a couple of working hours here and there — motivate them to do QA better!
Rule #4: set unrealistic goals
Wait, did I say unrealistic? I meant bold. Don’t be afraid to follow your dreams and do dream high. For example, if you want to deliver a brand-new high-quality app in three months, just remind yourself that you can do better than that — give your dev team three weeks instead and you’d be surprised of how fast they can work. Sure, they will complain a lot, some of them may even leave, but that’s how devs are. Just ban words like ‘impossible’ and ‘unreasonable’ from their vocabulary and they’ll do fine. Also, never believe your devs when they ask for more time to work on some new feature. Devs are sneaky, they don’t need more time, what they need is motivation — hence, more meetings! More branded merchandise for each employee! Surely they will become much more productive by wearing a t-shirt with your company logo.
Rule #5: use only trending technologies
Because if something is trending - it sure is good for your project, how can it not be? You should never miss a new framework — make your team to switch to it immediately, so that you all can brag about how cool your company stack is. You should never miss a hip trend. If the modern IT world is burning OOP at the stake — you should do the same, even if your specific app actually might benefit from using classes. Join the trend, burn it and switch to functional approach, because the crowd is never wrong and the in-fashion thing is ALWAYS a winner.
Rule #6: if your app is not working - add new features
Remember to add as many new features as possible, especially if your app’s performance is deteriorating and/or if you are approaching a deadline. New features will sure make everything better! But be careful: your developers might try to trick you into so-called refactoring or demand fundamental logic changes in order to improve app’s quality and performance. Do no listen to them! Just imagine how long it will take to assess all the potential problems in your app - it might take weeks, even months! On the other hand, introducing a new feature will distract users from app’s bad performance. No one will notice that their phone is overheating if there is a new super cool neon-glowing pop-up calculator on the screen. Remember that a new feature can be developed in just a couple of days, especially if you are not wasting any time on the QA. Having a release anytime soon? Add a couple of last-moment flashy features and secure its success!
Rule #7: be as fuzzy as possible in your user stories and epics
It’s hard to define an effective task, it’s even harder to know for sure where this task will lead you, so don’t even try, just use two or three sentences to describe a functionality you want and let the developers work thing out by themselves. With all their fancy education and experience they sure must think of something good. And if the result of their work is not what you’ve expected — no problem! It’s just a little bit of redundant code, throw it away and make devs to rewrite the whole thing. Repeat this cycle until you are satisfied or until all your devs have left the company.
