How to Work with Developers at Your Startup: A Guide for Non-Techies
Got developers at your startup? Freaking out because you have no idea how to manage them… judge the quality of their work… coach them through the forever changing product that marks the life of a startup…?
Here’s what you need to do.
Not just one of these.
All of them.
I know. It’s a long list. But they all go hand in hand. Stick with me and I think you’ll see…
Frequent (at least once/week) demos
Get your developers on weekly sprints. Every week have them demo the tasks they created for you and give them feedback to guide them in the right direction.
Be OK with the fact that they’ll sometimes interpret things differently then you what you meant – that’s typical because software is complex. That’s also why you can’t afford to lose more than a week to a dev going in the wrong direction. I know startups are crazy busy but prioritize the demos. Have a standard day/time each week and Stick To It.
If you’ve got a brand new developer or contractor, get demos even more frequently until you’re comfortable with their work.
Make sure every task is demonstrable through the user interface
Non-technical managers tend to get understandably nervous because they don’t understand the behind the scenes technical tasks and feel like they’re at the mercy of the developers.
But you shouldn’t be – this is your startup! Come up with a set of tasks for developers to work on, where every task is something you understand that can be demonstrated in the user interface (e.g., through using the app). This way you understand and control the tasks and can evaluate the quality of work being done through your weekly demos.
FOCUS! On immediate priorities
What happens a LOT at startups is that you’ve got a founder (typically CEO) who is, understandably excited about their startup and so has a never ending list of the wonderful things their products will do.
And it changes every week.
This is super unhelpful to developers who need to understand what to focus on TODAY, and who need to be able to bring one task to completion before shifting to the next or else nothing will ever get done and everyone will get frustrated and hate each other.
Work with the developers to get a feel on how long things take (don’t go crazy and get it down to the minute, just ballpark it) and then figure out which of those tasks you want them focusing over the next week or two. No more than that!!
Then have them work down the list in priority order – demoing what they did at the end of each week.
Small tasks, one (and only) one a time
To make this work, each task will have to be small enough to fit into weekly sprints (that means that features will be broken down into multiple tasks). So work with developers to break them down. Put each task on your Kanban board:
And then make SURE that that once a developer starts a task, they are able to COMPLETE it before you give them something new! Otherwise you’ll have 100 tasks outstanding, none of which are compete, and a TON of time is lost in returning to an older task, trying to remember what you were doing. And everyone will hate each other.
Yes, it’s sometimes annoying to wait, but since all tasks are one week or less, you never have to wait more than a week.
If things change so much that you no longer want that task, kill it completely – including having them revert their code! and then they can start on the next one.
Just in Time Code & Refactor
In order to move as fast as you need to, developers should only be coding out the bare minimum they need to make each task work. That’s good because it lets you be:
- super agile (they don’t have any extra code that they’ll have to change when, inevitably, priorities change), and
- super fast (they only code the bare minimum needed)
BUT – to make this work, you need to make sure that they (have!) take the time to refactor the code before adding each new feature. That means part of the work of each new task involves refactoring the code they’re about to touch before they implement the feature. Bonus if they have some automated tests to help make sure nothing breaks when they refactor.
If you don’t let them do this – always instead saying “we needed this yesterday! there’s no time to refactor! go faster!” then the code will get to be such a mess that it will be harder (and slower and more error prone) to add new features. And it will eventually get to a point where it’s pretty much impossible to change the code so you’ll have to throw it away and start again.
And everyone will hate each other.
The RIGHT level of quality for your current stage
THAT SAID.. sometimes it’s totally fine to have awful code that you’re just banging out as fast as you can.
A super early stage startup is likely throwing away their first version or three – where (even if they don’t want to admit it) the main purpose of those first versions is to figure out what works with the customer and/or from a technical perspective. And THEN you can build the right thing. And so it’s a waste of time to make the code great. Just figure out what works and then build THAT.
You just have to realize that this has serious limits and be ok with that!
Premature Optimization & Scaling – just say no
A lot of developers understandably take pride in their work and want to build out this perfect architecture that’s optimized and scalable and will handle any new features that you want to throw at it.
Thing is – if you only have two customers – please don’t waste time making your product scalable enough to handle thousands! When you get to the point where it doesn’t scale enough for your number of customers, that’s a great problem to have and you should be able to get money (revenue or funding) to let you now build it out to the level you need.
(help developers take pride in their work instead by showing off the awesome features they’ve built at the weekly demos – and showing them how much they’re helping the startup evolve)
Importance of Startup/Agile mindset in developers
You need to hire/outsource devs that are comfortable in startups or super agile environments and are willing to be fast and scrappy. But, in a smart way (not just banging out crappy code! because that code is just going to break again and again and you’ll never get anywhere).
More senior developers are going to have the technical skills to be better at this. BUT… a lot of times more senior developers are used to working in non-startup environments and so may not be willing to move so quickly. They’ll prioritize having that perfectly optimized, scalable architecture over features you need today and you won’t be able to move fast enough.
And you’ll end up with a perfectly built product that nobody uses.