,

Decreasing Bias in Hiring Technical Roles

Many tech companies are not terribly diverse. There are a lot of reasons for this, but today, I’d like to talk about some of the ways bias creeps into hiring, and what to do about it.

Coding Challenge Format

The standard whiteboarding technical interview is completely broken. It tests for skills that are practically orthogonal to modern software engineering – when a company I work with requires me to evaluate candidates based on a whiteboarding interview, I routinely walk out of them having no idea whether the person I just spoke to will be good at the job I need them to do. Few companies need programmers who can write code in high pressure environments, by hand, on a whiteboard, in front of an audience of other developers whose job is to pass judgement.

However, many companies do need developers who can translate business requirements into code, use the best tool for the job, and integrate it into existing codebases. Luckily, testing for such skills is pretty straightforward. I ask candidates to add a feature to a dummy product that is related to the business of the company hiring them. In this way, you can test how the candidate would write code in an environment that’s similar to the one they’re entering.

Now, whiteboarding is supposed to test for ‘problem solving,’ and many programmers would complain that this format takes away that part. So, I usually try to add some sort of twist to give the candidate a challenge or two so that we can evaluate problem solving as well as platform knowledge.

Evaluation

Another issue with whiteboarding is that it’s often biased in favor of white males. People have implicit expectations of who will be right and who will be wrong, and what a good programmer looks and sounds like. All of which has nothing to do with actually writing code!

There are plenty of examples where even submitted code gets analyzed in a more or less harsh manner depending on whether the name/screenname appears masculine or feminine.

To mitigate this aspect of the process, it’s important to anonymize the candidate’s submitted code before evaluating it. I like to have the team review it with no names or other gender/ethnicity signifiers and then either have a conversation about, or numerically score it on various agreed upon criteria. Forming a ‘blind’ opinion helps inform the decision once the person comes to meet the team.

Culture

Having concluded the technical evaluation, it’s just a matter of determining cultural fit, which varies by company. In addition to the standard reference checking, I find it important to get to know the candidate outside of a work setting and ask them some questions on something they’re opinionated about. The key here is to see how they respond to that probing, and how well they can take into account someone else’s point of view – empathetic employees can almost always be reasoned with. If possible, I try to get people with several different backgrounds to meet with them, to see if they treat different groups differently. In this way you can not only hire diverse folk, but develop a culture that welcomes people from diverse backgrounds.

 

,

Mobile App Startups: Where to begin?

So, you have an awesome app idea. What do you need to make it a success? What are your first steps? What are the components you need to build for it to grow?

Generally, you need to decide on a strategy on three fronts: capital, marketing, and tech. We’ll be doing more in depth articles on each of these, but first, let’s talk about what they are and why you need to think about them.

Your capital strategy basically relates to how you’re going to pay for things, or perhaps more accurately, who is going to pay for things. There are two main categories for this: either you pay for things yourself, or you get someone else to. There are advantages and disadvantages to both, and huge challenges as well. This is one of your biggest decisions, because it may entirely determine your strategy in the other two areas.

You need a marketing strategy because you need to build buzz long before your app comes out. Being able to show interest in your product can also help with raising capital and attracting a tech team. Finally, it can help you find early testers who will give you feedback before you go primetime – which is invaluable.

Lastly, your tech strategy. What technologies will you use to build your app? Who do you know that builds with those technologies? What do you need to think about as your app grows? How much will it cost at the beginning? How will that cost grow with your app’s popularity? Realistically, how much use will your app get? These are all important questions that will shape your tech strategy.

Thryv has helped many startups develop their strategy in all of these areas. We’ve seen it all, and are intimately familiar with the pluses and minuses of each approach in each category. Do you have a question? Get in touch with us and we’d be delighted to talk to you about what you need to do to get your idea out there!

,

Mobile App Startups: Raising Capital

This topic is one of the most opaque for many entrepreneurs, and is different in every case. Some general paths can be described, though. There are two main options: using your own money, or using someone else’s.

Using your own money

Using your own money is generally referred to as ‘bootstrapping.’ Often, because it’s their own money, entrepreneurs spend less overall when bootstrapping than when running the business with investors’ money. This can express itself in many ways: keeping your day job and building your business after hours, paying people in equity, not having an office, and doing as much as you can yourself.

The advantage of bootstrapping is that you don’t owe anyone a return on their money, so if things drag on and on, you don’t have a bunch of investors breathing down your neck. You can take your time, build slowly, and make unhurried decisions about your business. It’s hard to run out of money when you’re not spending any (or spending very little).

The disadvantage is that often, quality is expensive. Paying people in equity is not always an option, and indeed, it usually isn’t for people who know what they’re doing. You either have to take a risk on someone inexperienced, pay a lot of money out of pocket, or do whatever it is yourself. None of those are necessarily bad things for your business; they’re just either risky or unpleasant.

Finally, for many entrepreneurs, a problem with bootstrapping is that it isn’t glamorous. Don’t fall into this trap! Just because your friends won’t be impressed by your after hours project doesn’t mean you should try to raise money from venture capitalists. Be aware that your ego could try to convince you to do things that are Bad For Your Company, and try to look at your situation dispassionately.

Using someone else’s money

 

There is a standard path that startups go down when looking to raise institutional capital.

Usually, it starts with what’s descriptively called a ‘friends and family’ round. Predictably, it involves asking your friends and your family for money in order to make your idea a reality. Parents, rich uncles, that lawyer friend of yours are all fair game. You’ll probably want to prepare some designs of what your app will be, since it’s always easier to support something you can see. This round will most likely involve getting money in convertible note form – basically a loan that turns into equity if things go well. This way, you can give your investors some piece of mind that they’ll get their money back if things go poorly, but also get a piece of the company if it takes off.

After using up the money your family and friends gave you on building a prototype of your app (we have lots of blog posts about how to do that correctly), you will hopefully have some sort of success. You’ll then start wanting to talk to Angel Investors. Angels are high net worth individuals who will give you something in the five to six figure range to get your app ready for prime time, add more features, or simply scale up your operations. They’ll take equity, and depending on the Angel, want some sort of input into how the company is run.

Finally, you may get to a point where you want to talk to the heavy hitters: Venture Capitalists (VCs for short). VCs really don’t care about you unless you have 10 million users or $1 million in annual revenue. They’re wanting to make big investments for a huge return – usually they’re looking exclusively for potential billion dollar businesses. If you can’t convince them that your market is large enough to support a billion dollar business, and that YOU are that business, they won’t be returning your calls.

VCs typically make investments in the seven to eight figure range and expect a lot of equity. They also want a lot of control over the company, so that if they think you’re doing a bad job, they can take it away from you. VCs can be like dealing with the devil, but they can also be amazing resources. They know tons of people who can help you, and are heavily invested in your success.

Conclusion

This is a deep topic, and there are a multitude of books written about it. And to be clear, these paths aren’t terribly clear cut, so you can mix and match as necessary. Regardless, Thryv is here to help every step of the way; we’ve seen it all, so take advantage of our experience and get in touch!

Getting Your App Built: Hiring vs Contracting

 

In our last post, we walked through some pros and cons of using an individual contractor vs. an app development shop. What if you think you want to hire somebody longer term? When should you think about hiring a programmer to work for your company instead of hiring a contractor?

Hiring a programmer in-house

Pros of programming in-house:

  1. Familiarity – If you employ a programmer, they will become familiar with your product and codebase, which can streamline development. Additionally, they will become familiar with your company culture and you will become familiar with their working style, which can improve communication if you are a good fit.
  2. Long-term solutions – An in-house programmer will be more likely to think longer term because they know they will anticipate with you a year from now. (Note, however, turn-over in tech positions is much faster than most other industries, so maybe don’t expect them to be there 3 years from now.)

Cons of app programming in-house:

  1. Time – Hiring will typically take months and months to execute. Most people who are unfamiliar with the process dramatically underestimate how long it takes to find a programmer to hire full-time. Industry wisdom says that there are 5 job openings for app development for every one programmer. Consider how you’ll compete with other companies if you want to attract top talent. Not only do you need to offer a generous compensation package, but programmers also like to choose companies they find interesting because they have the luxury of choice.
  2. Expense – Competing to attract a quality programmer will require a lot of money. If you want to hire a senior developer who you are sure can see the big picture, solve complex problems, and build a strong foundation, you’re going to need to dig deep into your pockets. If you take a gamble on a more junior developer, you risk that person getting way out of their depth when they run into bigger problems. If a junior developer doesn’t write clean code, you’re going to end up paying a lot more for somebody to go back and fix or redo what you already built, if you have to add more functionality later.
  3. Uncertainty of Quality – It’s difficult for most people to tell if a programmer is any good. You can look at past work and past employers, but there is only so much certainty that can give you.  A computer science degree from 5 years ago can approach irrelevance in today’s fast-moving, constantly changing landscape.

Contracting with an app development shop

Pros of a development shop:

  1. Dynamic scaling – If you need a lot of horse-power now while you build a prototype, you can get exactly that. If later on, you just want maintenance and some small new features, you can get exactly that. Working with a app development shop means you can scale up and scale down at will.
  2. Accurate pricing – With the right shop, you’ll pay a lower rate for basic code and a higher rate for app architecture and big-picture problem solving. Different development tasks require different levels of expertise. With an app development shop, you only need to pay for expertise where it is really required.

Cons of an app development shop:

  1. You get what you pay for – If you choose to work with a very inexpensive development company, you risk ending up with poor-quality work that nobody can build from in the future. An overbooked company may build something that minimally meets your requirements, but will fall apart if you try to add anything or make any changes later on. You should also watch out for companies that don’t make you a priority. You need your development team to take your deadline as seriously as you do.
  2. Uncertainty of future relationship – If you alienate your development team, they can choose to stop working with you. If you are constantly adding features not in the original contract or if you are late on your payments, a development shop does not have to put up with you beyond fulfilling the current contract. 

An in-house developer can feel like a terrific luxury, but you have to be prepared to spend time and money finding the right person. Contracting out to a development shop allows you to get exactly the level of work you need, for an accurate price. That means you can get your prototype out quickly and then fine-tune as needed down the road. Considering the resources you would like to devote at this time will help you make the right decision for your company. 

Thryv is here to help.

Choosing App Development Services: Individual Contractor vs. Development Shop

Your business needs an app. You’ll need specialized help to build this app, but before that, you need to know what kind of help you need. Hiring the right person or company to build an app can be daunting. It’s also something that is best done right the first time.

Let’s begin with a very basic question: Do I need to find the right person or do I need to find the right company

You have a lot of options. Matching your business needs to the right development choice will get you the right work for the right price, so let’s examine the pros and cons of an individual contractor vs a development shop. 

Individual Contractor:

One person, who can take your app from architecture to visual design to programming to setting up a server and then making it all work together.

Pros:

  1. You will probably under-pay for some aspect of development. A single contractor will be doing many types of tasks, but an hour of app architectural design would normally cost more than an hour of bug-testing. Since the contractor probably gives you one average rate, some of their work will be a bargain.
  2. It’s easier to get on the same page if you’re only working with one person. If you already know exactly what you need, then you only need to make one person understand. An app development company may give you a project manager to translate your vision into different tasks and explain those to others, but that might be overkill if you already know exactly what needs to be done and just need somebody to execute.

Cons:

  1. You will probably over-pay for some aspect of development. If you are paying an average rate for all development tasks, you’re probably paying too much for some of the more basic tasks.
  2. It’s hard to find one person qualified to do everything you need. Everybody has strengths and weaknesses. When you hire a lone contractor, you are paying for them to use both their strongest and weakest skills. Finding somebody whose weakest skills are still good enough for your project will take time and discernment.

App Development Shop:

A team of people who work together to build your app, each acting within the area(s) of their own expertise to deliver an expertly-crafted product to fulfill your needs.

Pros:

  1. You will have the right people working on the right parts of your project. You can have a project manager to understand what you’re doing, an architect to structure it, and junior developers to write clean code that you can build from in the future.
  2. You have a whole team of experts to make sure you have a strong foundation. A team has more internal accountability and may be less likely to do slap-shod work that nobody else can build from or understand. If you think you will ever want to add to or improve your app, you need to make sure that there is more than one person in the world who could possibly understand the structure of the code.
  3. You can get projects done more quickly. This is common sense, but is worth stating. If more people are working on your app, they can finish it more quickly. If your deadline needs to be moved up, a development shop is more likely to be able to apply additional resources and get it done.

Cons:

  1. You have to trust the company you are working with. If you don’t have enough experience building apps to feel comfortable with just a single contractor, you need to find a company that is capable of taking your project from idea to reality with less input from you in between. That’s a big responsibility and you should find a company you feel good about. 
  2. Big development shops only want big clients. Smaller development shops are definitely an option for almost any size app, but the big development shops mostly work with large corporations. Keep an eye out for our upcoming article on how to know what size development shop is right for you!

An Important Choice

What type of development provider you go with is an important decision to make, but also very dependent on your situation. Review your options, and keep these factors in mind to make the best choice.

Requesting new features for your app

Asking for new or different features in your app can be easier in some cases more than others. If you took our advice in Fixed Price vs. Time and Materials this just comes down to normal courtesy, politeness, and thinking things through. If you didn’t take our advice and signed a SoW with a strict, fixed scope, then this can be a huge issue which needs to be navigated carefully. Regardless, the process starts out the same, and it starts out with you.

Step one: Customer discovery

Do you really need this change? Have you validated it with your customers? How important is it to make this change? Making changes in the middle of a project can be dangerous, so doing at least some light research into how much you need to make the change is critical.

Step two: Business discovery

How hard is it to make this change? How much time will it take? How much will it cost? Businesses can often be surprised by how much work and money it takes to make what may seem to them to be a relatively simple change. Make sure you discuss such things with your development provider to determine what kind of complexity you’re dealing with, as this often affects whether you want to commit to it.

Step three: Timing the work

You’ve decided that you definitely need to make this change, and you’re comfortable with the difficulty level. Now the question is, when do you do it? Sometimes changes make more sense to do later, and occasionally even after launch of the product. It may also be easier to make the change after some other work is completed, which could save you time and money in the long run. As before, communicate with your development provider to fit the change into your development schedule.

Step four: Contract considerations (optional)

If you have a fixed price project, you’ll want to amend your SOW or, potentially, get a new SOW altogether if the change is large enough. This is one of the downsides to fixed price projects, since a) lawyers are expensive, and you may need one to review the new scope, and b) if the change needs to happen immediately, this process can really slow down development.

Every project will involve changes in scope and features, so keep this in mind when you’re considering signing a contract with a fixed scope, as it won’t truly reflect the reality of development. Regardless, if you follow these steps, requesting new features and changes to existing features will go much more smoothly for everyone involved.

,

Google Play Indie Success Story Interview

In AppMaster’s podcast Google Play Indie Success Story with Elliot Schrock, host and marketing consultant Steve P. Young digs in to find out how some app developers are getting more success using Google Android revenue, and the hard lessons learned about choosing an icon for your app.

Founder and Mobile Architect Elliot Schrock is interviewed this week on the Appmaster.co podcast about his approach to market research, and user analytics… but on the way, he reveals his philosophy of taking care of users, applying the Golden Rule to app design, and his love of open source code.

And there’s a plug for one of the go-to apps on his phone you probably haven’t heard of. Hint: it makes you a better, more successful person.

Don’t miss his insights on:

  • App store SEO
  • User behavior
  • Selling apps
  • Prototyping and minimum viable products
  • Competitive research
  • Efficient coding

It’s just 36 minutes (which flies by), including the intro and outro.

,

The Hidden Costs of Low Quote Dev Shops: Overbooking

Sometimes, selecting an app development shop is like buying a plane ticket. At first, a lower price can be appealing, until you realize the airline has to make its money somewhere, and it’ll probably be a nasty surprise. Much of the time that comes from opaque baggage fees, convenience fees, upgrades, overbooking, and simply cutting corners on quality.

Many of those issues also appear in working with low quote dev shops. Let’s consider ‘overbooking.’

Many low-bid dev shops will hire developers (often overseas) and pay them a flat salary. Unfortunately, this incentivizes taking on more projects than is reasonable to pressure employees into working long hours so they can pay salaries and make a profit at the same time. Let’s look at an example.

The nasty surprises

Suppose a dev shop pays a developer $50,000 a year—less than half what you would normally pay for a domestic US developer. If they charge clients $25/hour for that developer, then 40 hours a week will allow them to break even for that developer. It follows that the way to profit off that developer is to get them to work more than 40 hours a week. The incentive, then, is to put that developer on as many projects as possible, so they’re working as many hours as possible. In this example, for every 10 hours a week over 40, the dev shop will make an additional ~$12,000 a year.

We at Thryv see this a lot when we’re rescuing projects that have gone off the rails. It’s not that overseas developers are worse than domestic ones, it’s that anyone who’s working 100 hours a week is going to make mistakes. The code will be ugly, poorly organized, and fragile just because whoever was working on it had ten other projects to get to. It’s unreasonable to expect that sort of code to be usable long term, and for startups lured in by the low price, this kind of mistake can have devastating consequences when it’s used as a foundation for the company.

,

Fixed Price vs. Time and Materials

When shopping around for an app, many entrepreneurs balk at trying to do things under a Time and Materials (T&M) agreement. After all, how can you make sure your app stays within budget?

Unfortunately, fixed price projects often end up costing more money than T&M. This often comes from one root cause: fixed price projects rarely end up being fixed scope. Whether it’s because something important was entirely forgotten or simply needs to be changed, projects of any kind are almost never perfectly planned from the beginning. This has a couple of consequences.

Consequences of Changing “Fixed Prices”

First, when something needs to change, you may need to recalculate the quote, sign a new SoW, or renegotiate the contract entirely. As we all know, lawyers aren’t cheap, and even if you don’t need legal help to adjust the contract, you’ll still be wasting valuable time.

Second, any contractor who’s done more than one project knows that uncertainty is a part of the job. This is often built into the fixed price quote given, so even if the project does go perfectly to plan or even just under budget, the client never sees that benefit. The best companies I know always try to under-promise and over-deliver, but a fixed price means that even if they’re weeks ahead of schedule, the client sees no change in the cost.

T&M projects avoid both these pitfalls. Change is easy to manage when you’re simply paying for an expert’s time, and if the project is done early, the client will reap the rewards.

But what about when the project drags on and on? Often, the whole reason clients look for fixed price quotes in the first place is to try to cap costs incurred due to the contracting company making mistakes. So what happens when a project goes off the rails?

Unfortunately, in most cases, fixing the price won’t protect against going over budget. Let’s look at an example.

Suppose a client engages a company for a fixed price app outside its regular expertise, and, for simplicity’s sake, it’s 50% up front and 50% when it’s delivered, with weekly product demos over 12 weeks. Week one comes and goes, and the company has nothing to show for their work due to ‘unexpected difficulties.’ The following week, they’re able to show a very rudimentary prototype of week one’s tasks. In the third week demo not much has changed in the prototype, but they assure the client that they’re ‘making progress.’ At the end of the fourth week, they tell the client that it’ll probably take 24 weeks rather than 12.

What can the client do? They’ve paid for 6 weeks of a 12 week project, but now the quote has doubled. It’s clear the company is in over their heads, but they probably aren’t willing to stick to the original price, and obviously not the original timeline. The choices are grim: pay double what was expected—for what may very well prove to be a shoddy product— or, start fresh with a different company and a loss of 50%, or sue.

If, on the other hand, the project were T&M paid bi-weekly, at the end of the fourth week when the client gets hit with the updated timeline, they’d only be down a sixth of the cost. With T&M, you’re able to minimize your losses should something go wrong.

Why Thryv

This is why we at Thryv rarely recommend a fixed price contract. T&M allows us (or any provider) to give you maximum flexibility while keeping costs low and, ultimately, minimizing risk. The next time you go looking for a quote, by all means ask for a cost estimate, but do yourself a favor and make sure you make the contract T&M.

,

Should your app development be with an independent contractor?

Getting a app written, tested and released is a challenging process. Your options are many. Let’s consider whether you should hire an independent contractor to write your app.

Reasons to hire an independent contractor:

  1. Low cost… you’re paying just one person, at whatever lowest rate you can negotiate.
  2. One person to deal with… communication is direct and efficient.

Reasons not to hire an independent contractor:

  1. You need an expert… but not for every line of code. The trouble is, you either hire high, or low. When you have easy, repetitive code, you just need a lower cost coder. But for knotty problems, experience breaks out of the box. With an independent contractor, you’re either paying too much for some parts of your code, or your programmer’s out of depth.
  2. Speed. If you need a fast release, or a fast update, you need a group of programmers to share the load.
  3. The back end, and the design. Finding one person who can provide an API to a server, and an artful UX-optimized interface, to say nothing of a solid app released for both iOS and Android—is a rare thing. If you don’t find that, then you’re no longer dealing with just one person anymore, regardless.

Solution

Consider a company like Thryv, where you’ll be assigned a project manager. Communication is direct and efficient.

Thryv has access to a range of talents. These will work on your project as variety of tasks demands. And you’ll be billed by a sliding scale that fits the skill and efforts of the contributors.