Working with Developers

There was a lot of passion in the room last week when I presented Working with Developers at the Stubbs Precellerator. I guess it should not be a surprise that Founders have lots of challenges working with developers. So I promised that I would provide a follow-up after the session. This is that follow-up and hopefully it’s useful to people outside of the session as well.

Challenges

I started by asking the founders in the room to tell me some of the challenges they have working with developers. Here are some of the issues that were mentioned:

I just want the cost, timeline and impact. But my developers want to go into way too much detail.
I’m a long way into development and I’m 90% done and we are having issues getting it completed
Developers like to over engineer. They often don’t take into account the actual business need. In fact, they often don’t really understand the business.
Developers (and Founders) are challenged to know how much is okay in terms of bugs.
I’m challenged getting developers to work with me when I can’t pay them market wages.
Developers like to do things their way even when it doesn’t meet the needs of the business.
Developers don’t communicate well

We likely could have gone on from there, but I had thought this would be more fun, instead it seemed to be poking a sore spot and I could see the pitch forks coming out.

Let me come back to these at the end of this post.

Developer Motivators and Demotivators

If you’ve not watched the Big Bang Theory, then let me give you some homework. Go watch a few episodes. Being a geek myself, the writers of this show hit pretty close to home. It may give non-technical founders a bit more insight into working styles when it comes to developers. In particular, pay attention to Sheldon Cooper (pictured). And keep in mind that developers consider you as weird as you may consider them:

“I'm sorry penny. But in this room you're the one who's peculiar.” – Sheldon Cooper

Developers want:

To solve something interesting, i.e., it’s an interesting technical problem
To have what they build get used and have impact
Learn from building it, ideally learning new skills and technologies
Praise for delivery, solving a technical issue
Have fun – but that’s often things like getting pizza delivered, time out for video games, celebrating a new release

Developers do not like:

Salespeople / Being Sold – talk to them without hyperbole. Just to the facts.
Time Wasters - Don't talk too much. Stay on point. Only go social when they go social.
Pretending to know more than you know and not knowing enough. Please do your homework so you at least know the basics. But don’t pretend you know anything more than you do. If you’ve ever seen an athlete use a big word in a slightly wrong way, that’s how you sound when you use technical language and you don’t quite know what it means.
Changing Your Mind. If something changes in the business and it requires change, then you will need to cushion the developer as much as you can. I’d first ask if you REALLY need to make the change. It is hugely demotivating to be putting your heart-and-soul into one set of functionality only to have it change and basically throw away a bunch of work.
Estimating Cost – it takes a lot of work to do a reasonable estimate of cost. The developer should be breaking out each individual piece of functionality and then coming up with a range of effort for the elements of that functionality. It’s generally a good idea to go through each of these line items to try to better understand what’s involved, especially for the ones that are bigger or that don’t seem to line up with your understanding of complexity. Do keep in mind that this is hard work for a developer. And since they then get locked into whatever they come up with as an estimate, it’s also scary. Have they considered everything? If there’s some issue they didn’t think about are they going to be beat up about it?
Re-estimating – if estimating is something they don’t like, then having to re-estimate costs based on a constantly changing target is brutal. Don’t do this to a developer or they will hate you.
Setting the Deadline or using the works “Just,” “Easy,” or “Everyone does this.” - It’s tough on a developer to explain why it takes work to get something to be built. Adding pressure to this conversation makes it tougher. It is better for them to come up with estimates on their own and have you go through to understand those estimates in a neutral way. Do not ever say, “Here’s what we need and we need it by X date.” You either need to be willing to take stuff out to get it down to something to hit the deadline, or you need to live with the date that arises from the estimate. You also should never say something like, “We just need to add X.” It implies that it’s something really easy to do. “I just need you for a few hours to help me move this weekend.”
Poor machine, screen, connection, chair. If your developers have a better machine, screen, internet connection, or chair at home than they do in the office, then there’s a problem. As compared to the cost of a developer, these are relatively inexpensive items.

Founder Developer Gap

The challenge for many non-technical founders is that they primarily need a lot of development to happen. I.e., they need a developer more than they need a CTO. What happens when you have a really good developer is that a gap exists where you may not ask the right questions to specify the right system, consider appropriate 3rd party technologies, etc.

This is something I’ve explored several times already in my blog:

Bottom line - for most startups, what they really need is a technical advisor or part-time CTO along with some development resources.

Challenges Revisited

Let’s look back at the challenges the Founders listed at the start of the session.

I just want the cost, timeline and impact. But my developers want to go into way too much detail.

Developers rightly need a lot of detail to get at cost, timeline and impact. Read Document Your MVP for a Developer for all of the detail that you really need to provide. Of course, you probably are going to provide more of a feature list. They should ask you for lots of details on those features and then give you some general estimates of size. Maybe even something like small, medium, large, Xlarge.

There is a balance here of how much granularity you want in your estimates and timeline vs. how much detail they want/need. Have an open discussion with them about what you are trying to achieve through the questions.

I’m a long way into development and I’m 90% done and we are having issues getting it completed

See Symptoms of a Weak Development Team and Poor Software Developers - Pull the Plug Early. This is a classic sign and you need to do something about it. Ideally, you would have had a technical advisor, had better up-front definition, had more iteration, then you would not be in this situation. Once you are here, it’s a tough spot.

Developers like to over engineer. They often don’t take into account the actual business need. In fact, they often don’t really understand the business.
Developers like to do things their way even when it doesn’t meet the needs of the business.

As a founder, you do need to be telling the developers what the business and product goals are. Provide the metrics you are trying to achieve. However, yes, there are a lot of developers who will take a myopic via of how to solve particular problems. Many are not interested in 3rd party technologies that can streamline development.

I just had a fellow CTO ask me about a particular technical design problem and several directions they could go and ask for my thoughts on the tradeoffs for those different choices. For a younger technical person, this showed incredible maturity. He was not afraid to show that he might not know the answer and ask for thoughts. Plus he knew there were significant business trade-offs.

If your developers are not providing trade-offs to you around the range of choices that they see in their solutions, that means they lack real understanding of their role. This is where a technical advisor can be hugely beneficial. They can force a more open-ended conversation about what the possibilities are. And what the trade-offs will be.

Developers (and Founders) are challenged to know how much is okay in terms of bugs.

Great question. Generally I say that developers should be doing significant developer level testing, but in early-stage startups, testing falls back on the founders. If too much is getting through developer level, i.e., they hand you stuff that’s obviously broken and tell you its “done” – that’s a bad sign. But then it becomes your job to find every last edge case bug. Collect them all into a single big list – I really mean an issue tracker. Prioritize. And then point the developers to them. Good developers will see thorough testing as a blessing. They don’t want to put out poor quality work.

I’m challenged getting developers to work with me when I can’t pay them market wages.

That’s correct. The market is great for developers. You need to inspire them with the product and market, and the learning opportunity. Ideally you can pay them a livable number. Take a look back at the motivators and demotivators. It’s tough though. You have to work really hard finding developers who are going to jump on board.

One other aspect is to make the development effort as small as possible. The less you pay the faster your developers will leave. If you have someone work for 3 months on something that will take 6 months to build, you will get very little from the effort. The next developer will likely tell you they have to redo a lot of it. Defining much shorter iterations on the way to a very small initial MVP.

Developers don’t communicate well

This one is going to take up it’s own blog post. Communicating with Developers … coming soon.

SoCal CTO

Monday, April 28, 2014