Tuesday, May 13, 2014

What Startup Advisors Do I Need?

Bob Dorf just published a post Where are the Hackers?  Solving the Founder-Tech Gap that came out of some fun conversations that Bob and I have been having.  A large part of this conversation is what kinds of advisors startups should be looking for.

A little while ago, I suggested that Every Web/Mobile Startup Should Have a Technical Advisor.  The conversation with Bob was about what the composition of advisors should look like.  We both felt that most startups are not taking a very systematic approach to defining with they need in terms of advisors.

Here’s the other aspect that both Tony and I preach: get help. You can’t afford and don’t want to hire a full-time CTO or architect. But, advisors, coaches, and mentors can often fill the bill. Getting someone who’s fully employed somewhere else to work with you on a limited basis to help close the gap is hugely important for the non-technical founder.

While Bob’s post focuses on Technology Advisors and the Startup Founder Developer Gap, we also discussed advisors more broadly.  I wanted to capture some of the broader conversation.

Formal vs. Informal Advisors

In many cases, you can get a couple coffee or beer meetings with advisors without ever formally engaging them as an advisor.  For me, if I can help you within a couple hours Free Startup CTO Consulting Sessions, I’m happy to do that and I don’t expect compensation or equity for that.  It’s not until it gets beyond the initial conversation or two that a formal relationship would be discussed.

There are a lot of people in the startup ecosystem that are happy to do this.  In creating Mentor Night, I’ve been happy to hear how giving most people are.  If you present a mentor with an interesting startup challenge in a space where they have experience or expertise, the mentors are quite willing to spend a few hours to help the founder.  And it’s way more fun when you have other interesting people in the room trying to also help.

Formal relationships make sense once you get beyond the informal stage, and it’s clear that there’s on-going need.  I recommend looking at the Founder’s Institute Founder Advisor Standard Template (FAST) Agreement as a template for this relationship.  Of course, you will want to work out the specifics of how you plan to work together with the advisor once it becomes more formal and adjust accordingly.

In some cases, Founders are building an Advisory Board with the purpose of padding their investor deck.  Investors discount this.  And it can hurt you if it’s purely cosmetic.  They may know some of your advisors and make a call after you meet with the investor.  

Connected Advisors?

I talk to many startup founders who select advisors in order to tap into their connections.  I’m not the biggest fan of this personally.  I side more with Mark Suster who says:

“advisory boards are an expensive equity proposition for merely introductions.”

Yes, you want connected individuals, but you often find that there are a few introductions that come easily and once those are exhausted, the value drops rather fast.

Domain Experts and Functional Advisors

Domain Experts have deep knowledge of your particular domain or aspect of the domain.  Maybe it’s knowledge of the players and dynamics of the mobile ad ecosystem. 

Functional Advisors come in with expertise in a particular area where you may need a second set of eyes.  This might be technology, marketing, sales, operations, international expansion, etc. 

Shafqat Islam looks at how he defined his Board of Advisors for NewsCred:

We spent a lot of time thinking about the exact roles and responsibilities for our advisory board. In that time I realized that we sought out very specific functions and had clear expectations.

Through this he defined aspects like “deep dives into our marketing strategy” and “product feedback and product strategy.”

This is a great way to go through and look at where you might have gaps and figure out what kinds of advisors you might want to approach for informal advice and then possibly formal advisory relationships.

In Bob’s post, he tells startup founders to get smart on product design, software architecture and development process.  That’s great advice.  But if the founder is just learning about these things, then those are gaps where getting advisors likely make sense.

Additional Thoughts on Advisors

Some additional random thoughts on Advisors and links to more information:

Monday, April 28, 2014

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.


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

Jim_Parsons_Comic_ConIf 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.

Other Topics Covered

I also covered topics that are covered more thoroughly in the following posts:

Some additional posts that may be of value:

As always, if you would like additional help please take a look at the following:

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.