Did you know FaceySpacey is the creator of Redux-First Router and Universal?
The Startup Incubator.
Your one stop social media shop
Resource Categories:
Non-Technical
Technical
Refer A Friend
Popular Articles
DEVELOPMENT TOOLS 1 - VERSION CONTROL (Mercurial)
CONTRACTING 2 - TOP 10 EASY SITE CREATOR TOOLS
Subscribe
- Non-Technical
-
Business
-
CONTRACTING 1 - HOW TO GET IN & OUT OF CONTRACT DEVELOPMENT CONTRACTING 2 - TOP 10 EASY SITE CREATOR TOOLS CONTRACTING 3 - MUST-KNOW SaaS TOOLS FUNDING & LEGAL 1 - HOW TO FUND A STARTUP FUNDING & LEGAL 2 - STARTUP CONTRACTS HIRING 1 - INTRODUCTION TO OUTSOURCING HIRING 2 - FINDING THE FIRM TO HIRE HIRING 3 - MANAGING YOUR NEW OUTSOURCED TEAM HIRING 4 - OFFSHORING HIRING 5 - BUILDING A TEAM
- HIRING 3 - MANAGING YOUR NEW OUTSOURCED TEAM
HIRING 3 - MANAGING YOUR NEW OUTSOURCED TEAM
So you found the team, how do you not fuck it up along the way? Yes, I used an expletive in my tutorials, which I usually refrain from doing. The reason I’m using it now is because it’s so easy to be the wrench in the machine if you’re new to this whole software development thing.
The ways you may fuck it up are:
1) changing specs, i.e. changing what you want for your product -- this is the biggest one
2) talking your developers’ ears off so they have no time to work. This is a problem because you’ll most likely undermine your confidence/trust in them, while making yourself seem less knowledgeable. If you’re not technical, you’re only going to show them all your flaws. Keep your communication concise.
3) being funky with money, i.e. changing payment milestones and terms as you go. Just don’t do this. If your team is having a hard time meeting a milestone, at the beginning be lenient with paying early if they really need it, and near the end be less lenient.
4) by not having enough milestones. Have as many as you can.
The biggest no-no is obviously changing your specs in the middle. This is obviously easier said than done, and it’s the cause of 95% of all software contracting failures. It’s so easy to happen. Save extra money in your budget for when it does happen because it doesn’t, and of course spec like a motherfucker and read our Speccing Tutorials. If it does happen, be prepared to fairly and decisively work out a new contract for the additional work. Be the the first one to bring up new costs for it. Don’t make yourself look like an ass by trying to get work for free, by framing every new feature as a bug or extension of a previous feature. When you do that, you’ll just give your developers excuses to screw you in the future by not finishing your project. Be the blueprint for morality when it comes to pricing stuff out and negotiation. You’ll get more results by giving a little (or a lot) in this area. Save aggressive pricing for larger parts of your application, and for little things allow yourself to give your developers a great price.
In general, bad pricing for your developers will always come back to you. You really should be looking to pay them more than they’re used to for the same amount of work, and just keep your product small. This way they’re happy to build it. If it turns out to take longer than they thought, they’ll have less excuses to make because they were once very happy with the pricing. So don’t be afraid to take on more than their bid for the initial pricing of the complete project. That said, make sure to get a price for the complete project at the beginning, not just the first phase. Otherwise, the latter phases will inevitably be a whole lot more expensive. The reality of it is you’re inventing something new--not just making a company site--and 9 times out of ten the project will be underestimated. You really should be building an in-house team, but you don’t have the funds for that. So in this reality, it’s just a must you lock yourself into a price for the whole thing from the beginning.
Another reality is take one eighth of your budget and build the initial launch with that. If the economics make sense, i.e. for $20k you can get to launch, do it. More often than not, since you’re building something innovative of real value, it will take at least $100k to get your initial launch product done. But again, if you can get it done for a lot cheaper, do so, and save yourself a lot of heart-ache. Still apply these techniques, and just improve upon them from phase to phase. The goal is to always get what you wanted for the amount of money you first planned, and without exhausting your developer resources until they don’t want to work with you anymore, which is a very common occurrence. So that said, don’t plan half your product for $20k. Do it at $40k then, and save yourself a $110k buffer (i.e. if you’re total budget is $150k). You need your firm working towards complete products. It’s a lot easier for them to get off the hook and therefore build a lot less and fix a lot less bugs, if all that is expected is a partial product. When they’re working for something launchable--and you need to first make it very clear that they’re working for this--they’re going to go a lot farther for you. They’ll seal up minor product misses on your part.
The point is they need to be on the hook to get a product done, not just your precise specs. What I’m saying is you gave your very thorough specs to help them, but your contract with them still needs to be “complete products.” That means they’re taking some of the product responsibility on their back. If there are disagreements of the intent of the product, you need to be fair, and able to lose at least half the battles over whether something was in the spec or not (i.e. in order to maintain their trust in you). What this will do is enforce how serious you are about holding them to completing a product, not just the great specs, which will inevitably miss a few things. You need to be disciplined in sticking to your word that you gave them to build your product, and not a different product through feature requests you added. In doing so, they’ll honor their word to complete your product, and patch a bunch of product holes.
The last thing you must do is make the team you hire find do their own speccing of the product before you hire them to build it. You should pay them for this pre-phase. This phase includes them internally speccing your project more deeply at a technical level, finding product holes, and getting answers from you for what to do to solve these holes. It’s your last time to make sure your plan for what you want is complete.
You can get a price for the overall project before or after this. If you get the price after, it may be bigger because they find that their is a bunch of stuff they didn’t think of before. If you get the price before, it will inevitably be less for the inverse reason. So depending on how tight your budget is, you choose what you want to do. If they overprice, it will mean you have longer until they start giving you shit for the project taking forever. Personally, I’ll take the quote ahead of time, and earn bonus points for giving out additional money and bonuses if things are taking longer. That will go a long way.
One of the things about developers you must know is that they’re not greedy, but need things to be fair with pinpoint accuracy. They’re programmers. They believe everything can be programmed, i.e. that there is a science to every equation. Between each other, developers have a very strict code of right and wrong because they can point out precise flaws in each other’s code. I.e. if they have a debate about some technical theory, they can actually box it out in a code, while the rest of us are left making empty statements to each other that we don’t have to prove. This culture leads to a built-in justice system. And believe me, it will carry over into how you deal with them, even if you’re not a coder. That said, I have no problem with developers underestimating. It’s their responsibility. I can’t afford to be in an all too common bad situation where I have no extra money from a client but need to get a feature done for a client because he’s expecting it and also doesn’t have an extra money. In the layer cake of contracting that I’m in, I’m at the top and therefore deal with the least technical of clients. Therefore, I’m going to get more product blunders on the part of my client where they forgot to make it clear that they really needed a feature, and truly without it their product isn’t launchable. However, developers I hire are lower down the layer cake. They’re receiving detailed specs from me, and are on the hook for less such bonuses to complete a product. So therefore, because I do provide such detailed specs, I don’t need baby developers I hire if I think they’re underestimating themselves. I feel completely justified in that. However, I will add bonuses to ease the pain if things get difficult along the way. This is how I stay in equilibrium in this cut-throat justice system between developers. In short, my clients above me in the layer cake will expect more extras missed in the spec and pay more, but developers I hire will give less extras and I’ll pay less. Of course there is a markup too, but I’m talking as if that’s not part of the equation, i.e. like when you remove inflation from economics calculations.
All in all, money is a very important part in dealing with your developers. Be on point with it as you things you missed in the spec come up. Prepare for that as much as possible by speccing like no other. Save extra money in the bank if you can’t. And build tight relationships with your guys. Not being a doosh bag is currency!
Related Entries
- CONTRACTING 1 - HOW TO GET IN & OUT OF CONTRACT DEVELOPMENT
- CONTRACTING 2 - TOP 10 EASY SITE CREATOR TOOLS
- CONTRACTING 3 - MUST-KNOW SaaS TOOLS
- FUNDING & LEGAL 1 - HOW TO FUND A STARTUP
- FUNDING & LEGAL 2 - STARTUP CONTRACTS
- HIRING 1 - INTRODUCTION TO OUTSOURCING
- HIRING 2 - FINDING THE FIRM TO HIRE
- HIRING 3 - MANAGING YOUR NEW OUTSOURCED TEAM
- HIRING 4 - OFFSHORING
- HIRING 5 - BUILDING A TEAM
SMM 3 - FORMULA TO FIND INFLUENCERS