How to manage developers when you’re a non-tech founder

A great tech-driven idea can strike anyone at any time, but it can be intimidating to bring your idea into the world if you can’t code. Managing developers when you don’t have a technical background is difficult at first.

As a result, a lot of non-technical founders feel there’s a barrier between them and success. The goal of this blog is to help you break down that barrier so you can effectively manage developers without learning to code yourself.

How Are Developers Similar To Your Other Employees?

As different as developers can be to other employees it’s important to recognize areas where they share commonalities with other employees.

First, they respond well to trust. When you give a developer a task, leave them alone to do it. Checking in on them constantly can be seen as a sign that you lack faith in their abilities. This can damage their confidence and result in them losing their enthusiasm for the work.

Second, listen to and engage with their feedback. We’ve all worked with people who wouldn’t listen to the opinions of anyone else. This creates tension and damages morale. Over time this becomes disengagement and attrition.

It’s fine to decide against a developer’s suggestion if you don’t think it’s right. Just make sure you show that you’ve considered their position and they understand why you’ve made the decision you have.

How Are Developers Different To Your Other Employees?

They know more about their subject than you do

If you’re hiring the best (and you absolutely should be) then you’re not going to get on their level after a few months of coding class. While it’s useful to pick up a bit of the lingo, don’t waste your time trying to learn to code if it’s not your core competence.

This may be the first time you’re managing someone whose job you couldn’t do personally but if your company grows then it won’t be the last.

Tim Chen, co-founder of NerdWallet, was a financial analyst who didn’t know how to code. He was interested in finding the best credit card for him, and focused on collecting the key data that would help him and others make the most of their money.

It was this focus that made him valuable to the business, and has seen it grow to over 150 employees.

They respond poorly to vagueness

Be exact. For example say “20% larger”, not “bigger”. Be as specific as possible when you’re talking to your development team.

There’s nothing wrong with broad language if you’re giving a developer an overview of your vision; that kind of context can be important and helpful. But if you’re giving direct feedback about a feature or design, fluffy phrases and requests will frustrate them.

A fluffy request would be “can we make the signup flow smoother and with less friction?”. Instead you should make requests like this “the signup flow has 4 steps, let’s cut this down to two maximum and remove half of the fields, specifically the address, company name and phone number fields.”

They speak a different language

You’ll pick it up over time, at least in parts, but not overnight. Use your ears more than your mouth in the initial meetings. Don’t be afraid stop your developers during these meetings and have them explain something again.

It’s much less frustrating to answer questions as you’re explaining a topic than to have to repeat everything at the next meeting.

Alex Turnbull from Groove places a big emphasis on arranging your thoughts in a way that is accessible to both yourself and developers. Wireframes, simple videos, even pen and paper sketches can make a real difference to a developers understanding.

These are valuable communication tools and you should leverage them.

Money isn’t their primary motivation

Most developers only want money so they don’t have to waste time thinking about it anymore. Developers want to have enough money so that life’s necessities are covered with disposable income left over to live comfortably.

Beyond that money isn’t much of a priority. The high demand for developers means they get so many job offers that they know they can always take well paying work to top up the bank account if needed.

Developers tend to be motivated by solving hard and interesting problems. They’re also notorious for under-charging for their services. Contrast this with bankers and lawyers who charge by the minute and it’s a clear signal that developers tend to think differently.

That’s why top developers will work for free on open source projects — something that’s difficult to imagine happening in other professions like banking or sales.

This is not an excuse for not paying well and fairly for good work but don’t expect that just throwing money at the problem will lead to the best people working on it. You’ll have to do more than that to find smart people who are personally invested in helping you with your tech challenges.

How To Manage Developers

Get them personally invested in the technical challenge

Tim Westergren gave a great talk at HustleCon about the origins of Pandora. In it, he spoke about convincing his developers to work for free while they sought more funding.

That’s no mean feat! Especially considering how his developers would have had options to work elsewhere on similarly challenging problems.

The reason Tim was able to get his developers to do this was because they believed in what they were making. Top developers have so many choices when it comes to where they want to work.

That means that, beyond making enough money to live, what they really want are interesting and challenging problems to solve. That’s why it’s so important to make sure that your developers are engaged and interested in their work.

The Pandora example is extreme but it also shows that developers will work for free if they believe strongly enough in the challenge and the vision.

Of course, they likely had equity in the business so it wasn’t pure altruism but at the same time it’s difficult to imagine there are too many other professions who would stick around for too long under those circumstances.

When your developers are true believers they’ll be some of your best employees. Even if they have to do grunt work like debugging, or QA-ing code, they can still feel that they’re a part of something it’s believing.

So how do you get developers invested in your company? There are all sorts of ways, but the best three are:

  • Demonstrate how the problems they’ll be working on day-to-day align with their core values and beliefs.
  • Get them excited about the vision of your company and show them why the work you’re doing is important.
  • Incentivize them with equity. (Side-note: When hiring a new developer offer them a choice between more equity and less salary versus more salary and less equity. If they bias towards salary that may be a sign they may not fully believe in your company. Update: 25th April: as commenter nateritter rightly notes there are a lot of factors that can influence what compensation developers favor including personal debt, the needs of dependents, etc)

Find ways to add value and make their lives easier

Developers don’t work in a vacuum, they need resources from outside their department, and this is where you can add value. Maybe they need a dataset from elsewhere before they can move forward, or are waiting on a design.

Hustle for them and get them what they need as quick as possible. Show that you’re invested in their success and will work to remove friction wherever you can to make their job easier.

Startups are messy so they need to be comfortable working in that environment but the more you can show you care about their success the more loyal they’re likely to be. Remember, they’re almost always being courted by other companies — don’t give them reasons to be tempted.

Don’t call unscheduled meetings, unblock and touch base often

Your developers should be able to call a meeting with you at short notice. That doesn’t mean you should always drop everything to speak to them right away but you should try and make sure you do what you can to make sure you’re not a blocker.

On the other hand you should avoid requesting last minute developer meetings wherever possible. This includes so-called ‘quick chats’ or walking by their desk to ‘check in’. These can be devastating to a developer’s productivity.

These small touches may seem small and innocuous but they prevent your developers from getting in the zone where they can do their best work. Do interrupt or call meetings if something is genuinely urgent and important otherwise it can wait.

That’s because good development work needs long, uninterrupted periods of time.

Give your developers the air cover they need to focus on task and keep scheduled meetings to a minimum. Be sure to host a daily stand-up where developers can talk about what’s going well and what’s holding them back.

You should also do a weekly 1-1 where the developer is free to discuss issues that matter to them — work related or otherwise.

Ben Horowitz’s guide 1-1 goes into more detail on this but this is a meeting you should have with all employees, not just developers. You’ll learn more about the issues that matter to them so you can nip any emerging problems in the bud.

Be exact with your requirements and feedback

There’s a great quote from Ron Lichty and Mickey Mantle, authors of Managing the Unmanageable, on the importance of good requirements: “Without requirements or design, programming is the art of adding bugs to an empty text file.”

Good requirements are measurable, defined, and agile. Bad requirements are infinite, vague, and will frustrate your developers to no end. For example: “Make the page load faster” is a poorly defined request. Instead this should be “The page currently takes 3.5 seconds to load, we need it to take less than 1 second.”

Develop some core knowledge

You may not have the time to learn to code fully, but there’s value in learning the fundamentals. It speeds up meetings, helps when writing about requirements, and gives you an insight into the process.

Not sure how to find the time? Check out this interview with Brian Chesky, where he talks about how he focused on studying key texts to accelerate his learning.

By focusing on one excellent resource (he gives the example of ‘High Output Management’ to learn management skills), he can cut out many hours of learning to get the knowledge he needs to do this job.

He does caution that it’s important to make sure you pick the right source, however: “if you pick the wrong source, you learn the wrong thing”.

Accept the feeling of having less control

It can be intimidating as a non-technical founder to feel that you have less control and insight into one of the key aspects of your business. It’s a feeling you’ll have to learn to live with. As the company grows you won’t be able to do everyone’s job, no matter how talented you are.

The same is true for famous founders like Mark Zuckerberg, Bill Gates and Elon Musk. They are all brilliant CEOs but that doesn’t mean they’re able to do the work of each employee in the company or even of each executive who reports to them.

The key is to focus getting the hiring process right and then managing results and culture — not processes. For a detailed perspective on this you should read Ben Horowitz’s Hiring Executives: If You’ve Never Done the Job, How Do You Hire Somebody Good?

It’s a fact of founder life that every CEO has to accept, and getting used to it early with your developers will be the first of many instances where you’ll be managing people whose job you couldn’t do yourself.

Hire well, give clear instructions, and keep your developers invested in the vision for your business. These are the best ways to ensure success as a non-technical founder managing a development team.

On the hunt for great developers to work on your next project? Gigster can help you organize top freelancing talent from around the world.

Alex Blott

Alex is based in Glasgow, Scotland, and regularly takes advantage of the highlands at his doorstep. He loves interviewing Gigsters clients because they're diverse and he always learns something new. His favourite writer is John Jeremiah Sullivan.