Last updated November 11, 2019
Roughly one year ago, I started looking into hiring software developers to build KyLeads and plot world domination.
It proved to be more of a challenge than I’d anticipated. I went in thinking it couldn’t be more difficult than hiring a virtual assistant.
I was wrong.
Before I started KyLeads, my only experience hiring tech talent was the one-off customization or plugin for WordPress.
What you need to understand for that pales in comparison to building a product form the ground up.
Over the course of a year, I made a lot of mistakes and learned invaluable lessons.
Now, I’m better equipped for hiring software developers.
This post details the wins and losses we experienced on the road to MVP and KyLeads v1.
1.If it sounds too good to be true then it probably is
When I decided to build KyLeads it was all about the quick and dirty MVP (minimum viable product). I wanted to show it to potential customers ASAP.
Once they got their hands on it, they’d tell me what they loved, what they hated, and we’d know where to improve.
To start, I looked at Upwork and a few other platforms to find talent. I set up my job listing and got a lot of applications who seemed competent.
When I asked them if they needed any clarification they would tell me no, they understood.
I’ve worked with clients in a consulting capacity. There’s always more they need to explain before you understand their vision.
The software developers I was getting made me uneasy because of their lack of preparation. I abandoned the freelancing websites and started looking for an Agency or a low-cost service to get it done.
That’s when I found Pebbled.io.
They billed themselves as a one-stop-shop for development and design work. I jumped on board with their lowest tier to test the service.
I was happy with their design work even though it was slow so I upgraded to the highest tier of the service.
We settled on the deliverables for the project and they worked on it for a month before telling me they couldn’t do it.
I was pissed but they gave me that month free to compensate for the time wasted.
I was still pissed.
It was too good to be true.
This was the first time I thought about quitting – it wouldn’t be the last.
2. It’s never a good idea to outsource your core product
Around this time, I mentioned my project to a friend, Eco, in an offhanded way. He didn’t say much about it but suggested I outsource to a small firm that’s just getting off the ground.
They’d be more likely to throw me a deal to pad out their portfolio. I took his advice and went back to Upwork to find organizations represented there.
I settled on a development shop out of India and we started work. They quoted me $2,500 to get an MVP done.
From the beginning, there were red flags. The person they set me up with seemed to be different than the person I interviewed. I think I was stuck with a junior member of their team.
He took forever to set up, had horrible communication, and was generally sloppy. After a few weeks, I paid them five hundred dollars, requested my work, and ended the contract.
People have seen good results from outsourcing the initial development of their product but for us, it was a bad move.
We were left with barely usable code and I was depressed about our progress. This was the second time I thought about giving up.
3. Hire for what you need now – not what people can grow into
After my experience with outsourcing, I was determined that I’d hire software developers directly to my team.
I knew I couldn’t afford a full-time developer in the U.S. so I looked at different platforms that aggregate talent outside the country.
After doing a bit of research, I discovered The Philippines was a growing destination for tech talent. I signed up for Onlinejobs.ph and set up a detailed job description.
I got a lot of applicants and performed interviews to the best of my ability.
After about a week, I got an application that piqued my interest.
A senior developer, let’s call him John, was grooming a group of students to work with companies. He’d serve as the project manager while guiding them and making sure they’d deliver on time.
He assured me they were talented and could get the work done.
I bit and hired two of them. Within a week, they were writing code and shipping.
My new hires weren’t experienced. They were learning as they went and we ran into issue after issue. They needed to learn new technology midway through the project and slowed us down for weeks at a time.
I knew what I was getting into so I tried to be patient but the weeks dragged into months and I needed results. In a bootstrapped startup, you don’t have the time or resources to train talent in the beginning.
I made the mistake of underestimating the learning curve of my new hires. That’s when we decided to bring on another senior developer to help out.
4. Have clear responsibilities for your teammates
I went back to Upwork but this time I was more confident because I had John there to help me vet the applicants.
I set up a job post and the applicants flooded in. John vetted their technical abilities for me. I’d conduct the final interview.
We found someone after a week of searching and integrated him into the team. I didn’t have a clear understanding of what needed to be done on the technical side and my earlier hires seemed had trouble communicating with their new teammate.
We gave him assignments but he didn’t deliver the way we needed him to. From my perspective, he was also being a dick about the milestones.
I worked with him as best I could but he kept complaining about what his job was.
One of my teammates said he explained everything to him. He, on the other hand, said no one told him anything.
I called an all hands meeting.
We jumped on a conference call – all five of us – and ironed out any issues we had. This helped us for about a week before everything deteriorated again.
I was fed up with our Upwork hire and asked him to deliver what he’d done and cancel the job. He took exception to that and decided to open a dispute.
We resolved it amicably.
Looking back, I realize the fault was with me. I tried to pass off setting his tasks to another teammate. The problem was I didn’t clearly define what I needed from him in the first place.
I felt they would be in the best position to tell him because they’re the ones that needed the extra help.
Lesson learned. Unless you have a manager that’s tasked with setting the responsibilities of your teammates, it’s your job.
5. Lean on your network to help you vet people for technical expertise
We let our Upwork hire go and soon after that and the dev team I hired quit on me.
I was pissed because I went into the relationship with the assurance that they’d deliver.
Another lesson learned.
John, who was the one in charge of bringing them on, assured me that he’d find new talent. This was the end of February and we’d blown our projections by roughly three months.
We created another job post on Onlinejobs.ph and I gave him access to my account. Over the course of a month, we interviewed dozens of software developers. John rejected all of them because he felt their skills weren’t up to par.
I wish he’d done that with the two people he brought on board originally.
This lasted for about a month and I eventually closed my account with OnlineJobs and called my friend Eco. After talking for a few minutes, I told him about the challenges I was going through.
He laughed at me for a while then promised he’d help with hiring software developers. In a few days, he brought someone for me to vet after vouching for his skills.
We had a conversation where he grilled me about the project. I can’t tell you how happy I was because, in my past experience, people who don’t ask questions won’t deliver what you’re looking for.
I shared the code I had, he picked it apart, and we threw out over half of it. We agreed to work towards an MVP within sixty days.
I added him to slack and started the next phase of our journey.
6. When hiring software developers make sure they can communicate well
The developer my friend brought on was worth his weight in gold. He was fast, efficient, and knowledgeable. Eco and I started calling him our super developer.
We were building two apps in one. We knocked out the opt-in forms first then moved on to the quizzes.
There were two problems.
- There was no UI design for him to work with so we spent a lot of time going back and forth clarifying things.
- The second was that he didn’t have domain expertise. Things I felt were obvious were alien to him.
We lost a lot of time hammering out what we needed in a quiz. He thought it was educational and started building quizzes with tons of features that wouldn’t matter to our users.
At the time, he was shipping updates once a week. That was every Friday. We’d discuss them then plot the most important things to be done the next week.
I noticed that we’d have to roll back a bunch of the changes because they weren’t needed.
We moved to shorter shipping times and started talking in Slack every single day. We missed our sixty-day deadline by a week and hammered the scope of the project but I was still happy.
We’d finally gotten an MVP.
7. You need some type of project management tool.
After shipping the MVP, I stepped up my promotion game and got a few hundred beta users. They were sending us invaluable feedback, complaints, and bug reports.
We needed a way to continuously develop KyLeads while addressing their needs. At first, we just used Slack to keep track of bugs and features. That quickly deteriorated because Slack isn’t really project management software. It’s more of a team collaboration tool and there are many Slack competitors that focus more on the project management side of things.
With Slack, there was no real way to prioritize what we were doing. Conversations would get buried and since we were using the free version at the time, we had a limit on what we could search.
I started looking for a way to prioritize tasks for myself and my teammate. I tried Craft for a while – it’s a robust tool – but the free plan only allowed for one user.
That was useless.
After that, I read an article about Trello for project management. It was just what we were looking for.
We set up a development board and I added all the features we needed, wanted, and were working on. Now, everything concerning development is placed there and it’s easy to see what’s being worked on and what’s coming up.
Once the team expands a bit more, we may switch to Asana – then Craft.
8. Make sure deadlines matter
We didn’t handle deadlines well. They basically didn’t matter.
I’d set a hard date, we’d miss it, then we’d recalibrate. This bred a type of complacency within me and all the contractors we worked with.
It started from my experience with Pebbled. The smallest tasks took forever.
The consensus was that deadlines were a rough guideline made out of clay. If they don’t work then we’d be able to reshape them.
It was hurting us because we had actual users at this point and we were making promises that we weren’t meeting up with. With such a young brand, there was no way we’d survive if we created a reputation for breaking promises.
I faced the situation head-on. My approach was simple.
- I asked you how long it would take to do xyz.
- They’d tell me how long it would take and I’d add another few days.
- I would get back to them with a hard date for completion.
- When that day rolled around and I didn’t have what I needed, I’d give them a hard time until it was done.
It was effective because I’d remind them that I didn’t impose the timeframe on them. They said they could do it by that time and I even added extra time.
I fired two contractors because they were chronically late. The rest of the team (Note that when I say team, I mean the software developers, marketing team, and contractors that worked together on KyLeads) got the message and started estimating their time better.
Now, we’re pretty good with deadlines. We’re not perfect, but we’re getting better.
9. Develop processes from day one
This is the last challenge we faced and we’re still trying to wrap our heads around it. We’ve gotten better but there’s a long way to go.
In the beginning, we just gave ourselves tasks and did it to the best of our abilities.
The issue was that if anyone came in behind us, it would take a lot of work to get up and running. This kept happening when hiring software developers.
I’ve started experimenting with creating processes for the marketing side of things and I’ve also tasked our super developer to do the same on the programming side.
It’s slow going and requires a lot of testing but it’s worth it.
Our content production as well as development process has gotten faster. Within the next few months, we’ll have our major processes documented and ready for new hires.
Hiring software developers is easier said than done. As a non-technical founder, it can be downright daunting.
Over the course of a year, I experienced a lot of the bad that comes with it. Some people took advantage of my inexperience and part of it was me not doing the preliminary work.
I eventually learned my lesson and hooked up with great teammates. They’ve seen me through dozens of ups and downs and we’re just getting started.
Common sense will see you through a lot but when you’re in the trenches; you don’t always make your best decisions. Hiring software developers right can save you a lot of time, money, and energy.
Let me know the lessons you’ve learned from hiring software developers or any of my lessons you can relate to.