Outsourcing 101 Part 2 | Mark Stoner

Outsourcing considerations before hiring. Trusted advisor or body shop. Ideally, you want to find somebody that's going to make recommendations. You might have a great idea, vision, even your CTO, your technical team, but it's much better if you have somebody that's going to say, no, I think there's a different way to do it, there's a different approach. You want advice, you want input, not somebody just to kind of build exactly what you have. User interface, user experience, there's much more daily interaction. So if there's going to be challenges with working with outsourcing, it's probably more on that side because there's so much more interaction than kind of development. And if you, as far as web design or mobile design, if you can send samples, 3, 4, or 5 samples of other websites, other mobile apps that you like as far as color style user interface that helps to get everybody on the same page. The other thing about outsourcing is think about dependencies. Are there dependencies? Are you going to have to— if you have a local team, are you going to have daily interaction with— if it's an offshore team or outsourced, whatever, what are the dependencies? Are they going to slow you down if they miss a deadline, if you miss a deadline? For example, we run into it quite a bit that people have an iOS app, mobile app, and they need an Android app or vice versa. That's pretty independent. We just kind of get the specs and go off and do our thing. So there's not the dependencies there as much. I would check references, resumes, or reviews. If you're going to Upwork, I've in a past life, I hired people, it was oDesk, now Upwork, about 13, 14 people from there. My experience with Upwork is you have to kind of test people on a small project, see how they do, give them a little bit bigger projects. So it's kind of the Wild West still, even though you've got ratings there. But the other thing is that with outsourcing, I'd ask for the resumes of the people that are going to be working on your project to really understand their background or interview them just like you were hiring them for your team. I mean, I've done it before. I hired a public relations agency in Paris where they came in with the big guns and then we hired them and then all the junior people were assigned to our account. I mentioned I worked at Accenture, PwC, it's similar. So the question, the point is just making sure the people that are actually working on your project have the right skills and background. You could pay for 1 week of a project as a test. So maybe give them a small project. Some people do it for free. I just offer to pay for a small project. I mean, if you don't really have a technical background and you want to test people. Single point of contact is important also for development. Somebody that's a project manager, somebody that's overseeing working with you. Maybe you're working with one person, but as you go into a bigger company, you don't want to be shuffled from one person to the next. Some of the areas to be careful about, the one-man band or less than 10-person company. I just run into it weekly, go to startup events and presentations and so forth. Sometimes they had a bad experience in Ukraine, they'd never consider it again or whatever. Sometimes the one person has great experience, they're the right fit for you. Sometimes smaller companies though, somebody goes on vacation, the project dead or they really don't have the experience. So just, as I said, kind of check them out before. Are you paying them to learn? I mean, do they really know Ruby or Python or whatever they're doing? Hosting, we recommend Amazon or Rackspace, or one of our clients last week told me they use OpenShift. In other words, some people will recommend their own hosting service or they have a hosting service. I'd say just after the staging Go with Amazon or go with a name hosting service so you always know where it is. Part of the outsourcing, the intellectual property rights, you're paying for development. What's going to happen to that? Mitesh can talk a little bit about that, the source code transfers. And then consider outsourcing. I mean, as you scale, once you get kind of a bigger project or 10 people, 8 people, 5 people, whatever, You might consider having a third person, maybe a local person that you pay a little bit more to, to just oversee the work if you don't have a technical team member. Legal issues. I'd get a nondisclosure agreement signed. If I meet somebody at a startup event or a cocktail party or whatever, I'm not going to sign an NDA if we're just kind of having a casual conversation. But if you're paying people to do work for you and you're worried about the idea, It doesn't guarantee a lot, but it just kind of sets somebody on record that they've signed something to that effect. I would use statement of work and milestones. So the SOW, statement of work, we provide it to clients depending on where they're at, but it's just they're going to do X by this day, this is what they're going to provide, and these are the deliverables. So the milestones are important to know really what you're getting. And then again, you own the IP. I mean, our agreements, that's part of the contract. We've got quite a bit of experience in HR and publishing in different areas, but we don't own the intellectual property. The clients have paid for that. It's their work. GitHub, Mitesh can talk about that, code repositories and some of the areas to follow through on that. And then they need to warrant the rights to the code. With open source projects, that's great, it's cheaper, you can get open source from different areas, but also you want to make sure that there is not going to be an issue in 2 years from now that they have used some code that they really didn't have the rights for. Thoughts on early-stage co-founders? Technical co-founder, I mean, if it's a technology play, obviously. Great leader, team member, collaborator, visionary. Sometimes the technical co-founder has control. I mean, they're the— they know everything if the other people don't. So the more people you have involved in that, if they leave the company, if there is conflict or whatever, then they hold the IP and you have to get that from them. The other thing with founders, something to consider too, is passwords, access, and security. So if you're a year or 2 years from now, And you say, well, Joe handled that. You should have one— more than one person that knows the source code or has passwords and so forth. So that's an important thing as a team to move— to consider. And then also look at product differences between the founders. As you build a startup, there's different directions, different focus and interest. Some people just lose interest if you go into a different direction. that doesn't match their interest. Or people change or they decide to go to grad school, they're not going to do a startup or whatever. So just working through those issues. And then this slide is from First Round Capital State of Startups Survey. So as you see, if you had at least one founder, how would you define your co-founder relationship? So collegial obviously is probably the best. You have a working relationship. Best friends is kind of a bonus, but best friends sometimes can lead to its own conflicts because you're too close. Don't have a relationship, 12%. Strained, 6%. That's not good. Or I fired them. That's even worse. So according to this survey, there's a 24% chance you're going to have some conflict or issue with a co-founder maybe in the next year or 2 or some— at some point in So as far as, kind of back to some of the passwords, the access, the intellectual property issues, and just work with people, kind of have the relationship evolve and just move forward with a couple of considerations. So my favorite sport is snow skiing. I love mogul skiing, downhill skiing. So for these kind of moguls, You can stand at the top of the hill and go, it's really steep, and kind of try to find it. If you try to go slow down the mountain, you're probably going to fall because these moguls were made for a certain line. They're made for people to go fast and it's a trough as you go down the hill. So the analogy, the point is that you're never going to know everything there is to know about a startup. There's always going to be research, there's going to be something you don't know, whatever. It's just really minimize your risk. Spend the least amount of money and then just evolve and seek advice and counsel from people you know. But I just saw something, the website Founder Dating yesterday or over the weekend, it was asked, people got, a couple of guys were asking, they don't have any tech background, should they start or do a startup? And it was kind of a mixed review. Of course the tech people said no. I think you just have to ask the right questions and again you move forward, but I definitely, You can figure it out not having a tech team. If you have the next Steve Jobs, great, but it shouldn't hold you back.