My name is Charlie. I help companies develop great products through staff augmentation and by providing dedicated software teams. You can connect with me on LinkedIn.
A lot of people have asked me for advice over the past few years about how to hire a software development team for their startup.
In many of these cases people are asking specifically about offshore or remote teams, so I’ve broken this article into two parts. First are high-level principles describing how to think about the process and second are specific methods for managing a remote team.
Part 1: Key Questions
I have seen a lot of companies get caught up in hiring a large team before achieving product-market fit or even before validating a prototype of their idea.
The allure of one’s own ideas can be powerful, so it’s important to keep that impulse in check and go through the necessary product/idea validation steps before scaling your team.
So my first piece of advice is to start with one engineer. Not a team. This will keep you focused on the core questions you are trying to answer with your product or service (ie do people care about this problem? Is my solution something people cannot live without? will people pay for this? Is the way I plan to make money seemingly sustainable?). There are a lot of great step by step guides for this type of process if you google “design thinking”.
For most ideas in today’s technology ecosystem, marketers and designers (and potentially salespeople) are equally important to engineers in validating the viability of a startup idea.
A very successful entrepreneur once told me “the road is littered with great products that no one has figured out how to sell”.
Now the questions you need to ask:
- What is my first goal with this team? Is it to build a specific version of the product? To make a prototype and raise money? To add features or support to an already successful product?
- What is my own background in product & engineering management? How involved am I going to be in managing the team or providing guidance on what should be built and how its success is being measured?
- Once you have answered #1 and #2, you should be able to define more specific attributes around what you are looking for (ie how senior, do they need product management experience, what engineering skills, etc).
- What is your opinion on distributed teams? It can be far more cost effective to hire teams offshore or use a hybrid model (onshore/offshore). This route can be exceptionally effective if done correctly and with a well-selected team but requires a very hands-on approach (ie daily scrum meetings, very explicit task management, user stories and most importantly QA).
- Do I personally want to work with these people? This seems obvious. But it’s not. A lot of startups are desperate for a “great” engineer and will look past a lot of personal shortcomings to find one. This is a recipe for anger, frustration, and failure.
If you have answered these five questions, you should have a pretty clear sense of what you are looking for.
My experience suggests that you won’t have a terribly hard time finding candidates and then it’s your job to get them excited about your startup (one of the most important skills a founder can have).
Part II: Managing an Offshore Team
The world is connected like never before. You have access to an entire globe of engineering talent and if managed properly, you can get great ROI from a dedicated offshore team. This can be a little tricky, but I have developed a framework that delivers success if followed closely.
I always used to wonder why so many outsourced software projects end in disaster? Or why you hear so many horror stories from friends who were excited to start something new only to spend a ton of money and time ending up completely demoralized. I hope my notes below can serve as a helpful guide in order to avoid a similar fate.
I have had the privilege of working with a range of different teams (from fully in-house teams to fully outsourced teams) and along the way have developed a few best practices when working with outsourced teams. Even more specifically, when using this strategy to launch the first version of your product.
This tends to be the phase of a company when it is most vulnerable and has the least resources, both financial and human, so any wrong choices tend to be magnified and can be the difference between progressing and dying.
You need to be Scrum Master AND Product Owner.
You need to be Scrum Master AND Product Owner.
(This may violate the rules for Scrum purists out there so I apologize in advance.)
I’d be willing to bet that when most people are taking the brave steps of converting their idea into an actual working product, they haven’t ever spent time as a Product Manager or Product Designer. In order to fully appreciate the power of the Scrum process, I would highly recommend first becoming familiar with a few popular frameworks for startups and product development. Two approaches that I often incorporate are Lean Start Up, first articulated by Eric Reis and Design Thinking, popularized by IDEO.
I won’t go into too much detail about these approaches (since that’s your job), but they both emphasize a customer-centric and iterative approach to problem-solving which aligns very well with the Scrum methodology. In my opinion, this is pre-requisite knowledge to being effective. I learned this the hard way, but you don’t need to (if you are willing to take my word for it).
In spite of the fact that this has proven to be a highly effective set of development principles for many of the world’s most successful technology companies, I often see early-stage founders and outsourced engineering firms engaging in a far more transactional and less collaborative way. The typical process often involves the founders generally describing what they want, some proxy product manager documenting that information into a workflow tool and then a few weeks later when the “sprint” is complete, reviewing the output…and inevitably everyone is angry.
No successful companies operate this way and neither should you. You need to insist that you are both the Scrum Master and Product Owner at this stage and be committed to writing user stories, daily stand up meetings and a far more involved and iterative process. If you or the firm you are considering working with are not willing to do this, I would highly consider rethinking the project.
Negotiate a Full-Time Monthly Price Per Engineer.
This is another element of outsourced engineering projects that often leaves me shaking my head. It is all too common that founders get lulled into either price-per-project or hourly pricing models because they think they will save money. Conversely, these structures allow outsourcing companies to more effectively (I mean deceptively) win business. Next time you post a project on UpWork, ask yourself how anyone can make such a concrete estimate on cost within a few hours and without a detailed understanding of requirements. This is an obvious case of incentive misalignment. I have never EVER seen this work nor have I ever seen a project completed to satisfaction within the projected budget or timeline.
The most effective way for both sides to structure pricing is on a full time per month basis. For the founders, this has the essential benefits of being able to implement the Scrum process, often communicate with your team, have far more visibility into progress and feel confident that your incentives are aligned with the development company. On the flip side, this allows the development company more clarity into their own resource allocation and also ensures them some satisfactory level of profit over a defined time horizon. Keep in mind that profit margin is not necessarily the key driver for an outsourcing company, but rather stable long term projects (as this reduces churn, lowers the number of new customers required to meet revenue goals and generally creates higher client satisfaction which is also a key new business driver in the form of referrals).
Don’t outsource UX.
Put simply, different cultures have different expectations on what type of user experience is deemed acceptable. They may also use different products which may not employ the same design conventions as you are used to. This suggestion is strongly related to getting customer feedback and embracing a scrum type approach but its important enough that it’s worth calling out on its own. If you are going to pay a premium at this stage, invest in a designer that you believe in or do this yourself.
Don’t Be Shy. Get Customer Feedback Immediately.
There is a lot that could be theorized about why people are so apprehensive to launch products that they don’t think are “ready”. Regardless of their reasoning, they are wrong. This is one of the most common mistakes of inexperienced founders…and can also cost you dearly in terms of time and money. In my opinion, a founder should be getting feedback on their product even before the MVP is launched. This can be done in the form of wireframes, splash pages to get data on marketing metrics, pre-selling, discussions with potential customers on how they might want to pay for a product, etc. This type of research is one of the major roles of a Product Manager. Through talking to customers, distilling and analyzing data, a Product Manager can gather the insights needed to continuously improve (a “Kaizen” approach as the folks at Toyota would say). A more structured way of describing this cycle is hypothesize, brainstorm, measure, assess and this should be done from day one.
Taking leaps of faith on your own judgment that go untested over long time horizons or entire projects is a recipe for disaster.
Treat outsourced team members as people, not resources.
Morale is important in any team. That includes people you are working with across oceans or on the other side of the world. While they may not necessarily share your passion for a particular project, they certainly will be a lot more excited about it if they like working with you and have a clear understanding of what is expected of them. This may sound obvious, but I’d say this is the exception, not the rule.
In case you have questions after reading the post just message me on LinkedIn directly.