Hiring devs as a non-techie? It doesn't have to turn into chaos

When hiring developers as a non-techie, chaos often ensues if you're not careful. I have had my fair share of painful memories, even as a techie. But it doesn't have to be this way. Follow these steps to make the process less distressing and set you up for future success.

Preparation

Scope the project

Clearly define your project and break it into multiple iterations if it is more extensive.

Proper designs

Hiring a designer and having professional mockups before the developer is brought in will save you much development time. Make sure you think things through.
It will cost you if you've developed a specific feature to figure out afterward that the user flow is out of whack and you need to redo everything.

Parallel hiring

Since hiring is difficult, one way to ensure you don't lose pace in case a hire turns out to be a bad fit is to hire 2 to 3 from the start. Then, letting go of a bad hire will not significantly impact the project. This will, of course, depend on how big your budget is.

Source code access

Make sure you are the admin of the source code repo. So, the developer can not cut you off at any point during a conflict. Set up a repository on GitHub or a similar service and give the developers enough permission to start working.

Build Pipeline

Have the developer set up an automated CI/CD build pipeline to deploy the project on day 1 for you to test. This will shorten the feedback loop significantly between you and the developer, and you can give proper feedback. It will also benefit from making it easy to onboard new developers and ensuring it works not only on the developer's machine.

Senior tech advisor

Hire a senior tech person who can advise you on code health. Usually, this is the job for a CTO, but if the budget is scarce, you might not be able to hire. Instead, try and hire a senior dev for a few hours of advice now and then to make sure the project is on track.

Communication is critical

When building a product and solving problems, communication is crucial. Make sure that your hire has excellent communication skills.

Budget for increased cost

Be prepared to shell out more money than you initially anticipated. In the end, The cost to build tends to be greater than the estimated amount for various reasons (increased scope, bad hire, wrong assumptions, the solution is more complex, etc.). Ensure you do not run out of money by always having an extra pile of cash if that happens.

Set early expectations

Have an initial onboarding meeting with the dev where you set your expectations for them and the project. How you'd prefer to communicate, etc. This will come in handy later.

Working

Regular check-ins

Have regular check-ins to monitor progress. Never start the project and let the dev hide in a cave for months, building the project without regular meetings and feedback. Regular check-ins will prevent the hire from heading in the wrong direction, costing you more money.

Fire fast

Fire fast if it doesn't work out. Not every hire is going to be a good fit. When that happens, be transparent about it and bring it up early. Depending on the severity of the issue, I usually give the hire one chance to improve. Otherwise, I will let them go. Communicate the reasoning clearly and gently. But if you've set clear expectations from the start when onboarding. This shouldn't be too much of an issue. But sometimes, the skill, execution, or chemistry aren't there.

Trust

As you continue to work with the same devs, they prove their worth, and confidence in your team builds up. Consider loosening some of the restrictions to make them move faster.

Avoid scope changes

By continuously adding new features during development for the developer to work on or repeatedly interrupting them, you will slow down the project significantly and increase your costs. Don't interrupt them unnecessarily.

Post-mortem

Project retrospective

Most likely, there will be more projects in the future, so it'll be vital for you to review the project and learn from any mistakes made. Identify what went wrong and what you did well, and improve your guidelines for the next project. Gather feedback from your team as well.

Self-reflection

Take the time after a project to also reflect on your actions and reactions throughout the project. Consider what you can improve and fine-tune for the next project.

Building a product is complex, even if following a good set of guidelines. But if you do your homework, it can save you from many costly grievances.

What are some of your hard-learned lessons?