Hiring a Business Developer
Oct 27, 2017 by nichol and matt lovanWe’ve both had the opportunity to encounter situations where non technical business owners needed to hire developers with development skills. Sometimes this comes in the form of looking for a co-founder or sometimes it is just in evaluating a developer or a dev shop to see if they can deliver what the business owner wants done.
Typically the technical skills that are targeted are the shinny new things that have a lot of buzz around them or were abstract requirements that someone told them they needed. In almost all circumstances, however, the technical skills they thought they needed were not the ones they actually needed. If the product you are building is a consumer focused business, and not a hard core technology company, chances are you probably want to hire a business focused developer, or a Business Developer.
We hope that if you are a business owner evaluating your options, this distinction will be helpful. And if you are a developer at a one or two person startup, or considering becoming one, we hope that this framework of thinking about things will allow you to increase your impact and help you move your startup forward!
Technical vs. Business Developers
Business Developer, like in Business Development? NO! Like a developer, a writer of code, a code writer, an app maker; someone who’s focused on giving you the code you need to take your fledging business to the next step while simultaneously balancing the impact of the decision making that leads to that code. Someone who can make smart decisions for very early stage startups and who can cover a lot of ground with your fledgling tech budget instead of burning it on a server rack in the closet with a 24 bay 16G fiber channel SAN RAID drive. (But seriously, those look pretty cool.)
Valve's Steam Store renders on the server, uses ancient jQuery 1.8, loads 12 unminified JavaScripts.
— Henning Koch (@triskweline) November 15, 2016
It moved 3.5 billion dollars in 2015. pic.twitter.com/YLGjJheQwf
Building a startup is very often not about the underlying tech you use to support it. Even more often, it turns out old tech is really good at doing things that you probably want to do. That’s how it got old! As the above tweet deftly illustrates, having the latest and greatest under the hood doesn’t matter if you have a great product that connects with people and generates revenue.
The risk and the trap is that you get bogged down into making tech choices that don’t serve your end needs. Debates around frameworks, infastructure, database scalability, and what have you inhibit the ability of your small but mighty team to evolve quickly enough to address the problems your users are or will be asking you to fix.
This is all very well and good, but how do you determine who is and who isn’t a Business Developer? Read on! Here’re some questions you can ask to help suss out your ideal business developer and otherwise determine the cut of their jib. We try to give you a sense of the possible different answers you might encounter and how those answers might point you towards a skill set and personality that will have maximum impact on your startup.
Six Questions
1. What is the best programming language? Why?
Hilarious! There is no such thing and this is a great and terribly tempting trap for someone to fall into. A technical developer may have very specific, venhemently held rationale. Or perhaps they will be reasonable and fall into the “right tool for the job” trope. (I mean, besides that, the obvious answer is that it’s Ruby.)
But a business developer should be somewhat agnostic on languages. What do we need to get the job done? What is the existing code base? What is the product going to be in three months and does a language decision affect those requirements? Additionally, a business developer will think carefully about language and technology choices based on how they might affect hiring. Choosing a popular language now makes hiring much easier down the line.
2. How much downtime is acceptable in a system you architecht?
BA! A technical developer will talk to you about three 9’s and failovers and backups and data integrety. And believe you me, there’s no limit to the ammount of money you can spend to keep your servers up and humming along.
A business developer will be focused on the cost of the downtime. Everyone hates the idea of the website going down but whether or not it’s a catastrophe depends on how much it costs your business. To put that in perspective, if you have a site that generates $20K/month, downtime only costs $28/hour. Are the decisions your tech team is going to be making in line with the impact behind them?
This isn’t to say you want someone who doesn’t care if the thing they’ve built is broken. But rather to suggest that is the developer you’re talking with thinking about the larger perspective of how to help the business?
I just saw this great t-shirt from Charity Majors and that pretty much sums it up!
3. Outsourced APIs or Custom Built?
Building unnessecary things in house has long been a sign of overly ambitious tech teams and can be a very tempting route to go when you are thinking about how much money you are spending. $399 per month for Analytics?! We can just build it in house! $1000/mo for hosting?! We’ll just buy some servers!! The long tail of maintenance is a doozy. And more than that - you get only an approximation of an analytics product. Not something that a whole team has been dedicated to building.
This can also be an especially attractive path as it gives a developer the sense of making an immediate impact for the company, in terms of saving money while also providing a beneficial feature.
Ultimately, however, a Business Developer should evaluate whether the in house development reflects a core competency of the business. Are you a search engine? No? Sign up for algolia! Are you building an up time monitoring SASS? No? Signup for Honeybadger. It takes 10 minutes and and helps the team to keep pushing on what you need to deliver to your customers that makes your busioness move forward.
This type of logic is also extesnisble to hardware. For a non-technical startup there is almost never a reason to even think about hardware. Outsource it, spin it up, and move on.
4. What’s the difference between junior and senior developers?
Anyone who you are talking to as a potential first hire or technical cofounder must have a high degree of empathy for junior developers. Incredibly proficient technical developers have previously been excused for having a dismissive opinion of juniors. Perhaps they’ve even been encouraged to be so. You’re looking for a developer who can help mentor others and has a generally positive inclination towards others who are smart and hungry rather than brilliant and tenured. As a new startup, the people you’re most likely going to be able to hire are going to be in the first pool.
5. When is a feature complete?
A technical developer may tell you it’s complete when it meets the feature spec, when it gets signed off on, or maybe when it gets QA’d. QA?! Wat! Your first developer IS your QA.
But the real answer is: “Never”. No feature is ever complete. Things are continually evolving and priorities are constantly changing based on users, investors, and competitors. It is far better to ship before a feature is complete and react quickly, than it is to hold back because there is some abstract check list that needs to be completed.
6. How do you avoid technical debt?
You don’t. Technical debt is scary to a technical developer. And also really sad. And something to run away from.
A business developer is also going to hate it but is going to accept it as the cost of being a single developer for a company with no users trying to build at lightspeed. There are things you can do to mitigate it, but it is the cost of early stage startups. If you’re building perfect code with no technical debt, the chances are you’re building the wrong thing or you didn’t need a developer in the first place.
The General Rule
You should be able to understand their answers. Their answers should be technical and can be quite in depth and the clearer they can make the technical concepts they’re discussing, the better. But if, at any point, they start talking crazy about recursion and kubernetes, and you don’t know what that is, then they should be really happy to stop and explain everything. If someone’s trying to impress you with fancy words and things you don’t understand, that person will not be a good fit for a non-technical founder.
We hope this has been useful and if you have any thoughts about it, we’d love to hear from you! Thanks.