Tuesday, July 19, 2016

TechEmpower Benchmarks and the Microsoft ASP.NET Core 1.0 Performance Story

I’ve had lots of conversations with fellow CTOs about the TechEmpower Web Framework Benchmarks.  Some really appreciate the value that they bring to help them understand performance characteristics of different frameworks.  Depending on the Technical Performance Requirements for your system, this could be really valuable information that is part of your framework selection process.  However, I’ve also had fellow CTOs tell me that they don’t find the test credible or that they don’t understand how their favorite framework doesn’t perform better.   Frankly, those two statements are often correlated. But when Microsoft is talking about “huddling around the benchmark” and “only making a pull request when it’s an order of magnitude of Node.js” – I would say that the benchmarks are providing real value to the development community.

Let me step back and tell a bit more of the story here.

You may or may not be aware that Microsoft just announced the release of ASP.NET Core 1.0: 
Today we are excited to announce the release of ASP.NET Core 1.0! This new release is one of the most significant architectural updates we’ve done to ASP.NET.  As part of this release we are making ASP.NET leaner, more modular, cross-platform, and cloud optimized.  ASP.NET Core is now available, and you can start using it today by downloading it here.
There’s a lot to like about ASP.NET Core 1.0.  It is a viable contender for all sorts of development efforts.  One of the things that makes us even more excited is that Microsoft has focused on is Performance as a core attribute:
With a significant rewrite of the web framework, we addressed some performance issues and have set aggressive goals for the future.  We’re introducing the new Kestrel web server that runs within your IIS host or behind another host process.  Kestrel has been designed from the start to be the fastest .NET server available, and our engineers have recorded some benchmarks to prove it.  With the backdrop of the standard TechEmpower Benchmarks, the team used these same tests to validate the speed of Kestrel and have some impressive numbers to report.
Another announcement also touts the benchmarks:
We used industry benchmarks for web platforms on Linux as part of the release, including the TechEmpower Benchmarks. We’ve been sharing our findings as demonstrated in our own labs, starting several months ago.
How did Microsoft get to this kind of performance.  Scott Hunter, Director of Program Management on the App Plat team at Microsoft, tells a bit of the story on the DotNet Rocks Podcast (starting around 19:00). 
I got a rash of customers who said to me, “Hey, we went to this TechEmpower Benchmark site.  And we saw where .Net was and where other technologies are, why should we be using your stack?”

Damian said – “I’m going to build perf lab and take a look at this thing.”

In the team room, the team would be huddled around the benchmark saying, “We got another 10,000 or 50,000 or 70,000.”

would only make a pull request when it was an order of magnitude of Node.js.  If I can get 2 Nodes, then I’ll do a PR. 

It became this thing in the team room where people kept piling in, and it became important.  Then as we started putting the numbers out there, the response was crazy.  The pinnacle of the responses was … Satya [Microsoft’s CEO] got an e-mail from somebody in the Valley, which we ended up seeing at some point. The person was basically saying, “Hey, I just want to let you know that non-Microsoft and non-DotNet people down here are actually looking at the numbers that one of your teams is doing and we find them super-exciting. He said there’s chatter on Slack channels and stuff from people who not be even thinking or talking about us.”
The Damian mentions is Damian Edwards.  You can see a talk he does on Vimeo also telling a bit of this story.

I have to mention that early in the video Damian asks:
Who’s heard of TechEmpower – okay most people. 
Wow, really - who's that audience?

Damian takes us through how they looked at the Benchmarks and what led them to achieving some remarkable results posted on their intro page:

This is exactly the kind of thing that we were hoping at TechEmpower when we came up with the benchmarks.  The fact that Microsoft made it a focus and applied resource to produce such exceptional performance is commendable, and the result is a solution that is provides tremendous value to ourselves and the developer community more broadly. 

Great job Microsoft! 

At TechEmpower, we are very happy to have been part of your journey. 

Wednesday, February 10, 2016

What are the Technical Performance Requirements for your Startup?

By far the most popular post on this blog is 32 Questions Developers May Have Forgot to Ask a Startup Founder.  It was originally written in 2011 and has had amazing staying power.  While I’ve updated it a few times, it continues to get at important questions that startup founders need to be asking.  I find myself sending it to startup founders all the time – maybe just slightly less than Free Startup CTO Consulting.

One notable gap in the 32 Questions post is Performance.  Luckily, some of the folks at TechEmpower just posted Think about Performance Before Building a Web Application.  It does a good job of laying out different aspects of performance that should be thought about prior to creating a system.

I want to take a slightly different cut at the topic of performance.  While it’s a messy topic, I’m going to try to lay out some of the additional questions that developers should be asking a Startup Founder around the performance requirements of the application.

To get us started and to grossly oversimplify performance, conceptually we can think about the system as consisting of the following elements that I’ll refer to throughout the post.
  • Requests.  We get a set of requests for our system to do something – generally from users or external systems.
  • Compute.  Our system must access our data, possibly 3rd party services, do some calculation and then get back to the user or the other system with our response.
  • Response. The pages or API response we provide back.

Application Characteristics

Any discussion of performance starts by understanding what the software does, how it is used, and what it interacts with.  A developer should find out:
  • What are the different types of users?  What do they do?
  • Is SEO important? – this is really another type of user – a crawler
  • Are we providing an API to other systems?  What are the characteristics of how these are used?  - again, this is like a user type.
  • Are there any time-based operations?  Overnight calculations?
  • Are 3rd party services used?  What are the characteristics of how they are used?  What are their performance characteristics?
  • How many of each type of user are there?  How many might be using the application at the same time (concurrent users)?  Will there be spikes of concurrent usage?
  • What data is used in the application?  How big is the data set?  Are there complex aspects to the data?
  • What computations / algorithms are part of the application?  Are any of the calculations done often?  Are any of the calculations complex?
  • Are there any aspects that have specific performance needs?  For example, are you providing a stats service that needs frequent, fast updates?

Response Time

Once we understand the overall characteristics of the application, then we want to drill down on some specific performance characteristics.  We generally start with response time needs because, in many ways, this is ultimately the measure of performance.  If you think about our system picture above, response time is roughly the time it takes to get our page or API call back from the system. 

It’s well documented that response time has significant business impact:
The impact is quite real.  But as with most things in tech, the picture is far more complicated than that.  Consider two different types of systems:
  • eCommerce or Content web site.  These will have many individual web pages, with specific URLs, optimized for SEO.  Each page needs fast response time (both time to first byte and total load time).  Pages may not have much dynamic content on the page. There may be lots of pages.
  • Web Application such as Web Mail or a gated Social network.  The content is not used for SEO so response time characteristics may be quite different.  If the initial load time of the web application was 10 seconds but bringing up an individual email took less than 1s that’s likely an okay characteristic.  Technically, this may open the door to a single-page application (SPA).  These often often have a relatively longer time to load and then has really good performance once you are “in the application.”
Of course, response time is quite a bit more complex than this.  You will be looking at aspects like:
  • Time to first byte (TTFB) vs. Load time
  • API calls
  • Global delivery?
  • Mobile delivery possibly with slow connections?
As a startup founder, you need to think about the characteristics of your solution and what you need from a response time standpoint.

Request Volume

Assuming we know what our system needs to produce (the right side of the picture) and how fast (response time), then the next big question is really how much?  We want to find out what requests the application gets (left side of picture) and how often these come in.  This is generally turned into a Requests per Second number.

Most of the time we will start by asking about Concurrent Users – and this is generally the number that startup founders are thinking about when they talk about scalability.  Concurrent users are the number that are on your web site or web application at the same time.   Of course we need to combine number of concurrent users with what the users are doing in order to have more of a picture of what this means. 

For example, let’s assume this is a content site.  For human users, they request a page with content, likely the content page is relatively simple, the user reads/scans the page for a little bit, they decide to click something else which requests a new page.  This may take 10 seconds.  So some quick math:
  • Each user generates 0.1 requests per second
  • 1,000 concurrent users generate 100 requests per second
Those are really interesting numbers for a technical person.  Of course, this gets much more complicated.  A developer will want to drill down on:
  • Different types of users?
  • Different use cases?
  • Traffic spikes?  TV Coverage?  Real-time events?
  • API Usage?
  • Growth rates?
This will give us a clearer picture of Request Volume for different kinds of requests that our system needs to process.


Now we know the volume we need to satisfy coming in on the left and the response time required on the right.  The middle is what the system needs to do in order to respond to that volume of requests within that timeframe. 

Developers will want to explore with a startup founder where there may be complexity in the system.  We want to do this for two reasons: (1) how complex is the software we need to build – complexity generally means more time/cost to build, and (2) how long will it take for the system to calculate responses.  I’m only going to focus on the second aspect – understanding complexity as it relates to performance.  And really I’m only going to scratch the surface here as complexity is something that a startup founder and a Technical Advisor would need to explore together.
  • Computation Complexity – What do we need to compute?  What are some of the more complex aspects of system calculation?  Natural language processing?  Matching algorithms?  Complex reports?  Are there widely varied use cases with different performance characteristics?  Any blocking operations?
  • Data Complexity – What data are we dealing with? How big is the data set?  What are the largest number of a single type of entity?  Are there aspects that need to be pre-computed?  Any time series data?  Any logging/auditing data?
  • 3rd Party System Complexity – What are the characteristics of the 3rd party systems?  What will happen when they are slow or non-responsive?  What happens when they return poor quality results? 

Last Thoughts

Yikes, that turned into a lot more than I was originally thinking as I started this post.  Hopefully the core model makes sense.  As a startup founder you need to think about the characteristics of your application and then think about the Volume, Complexity and Response Time requirements.  For some applications, it will be relatively straight forward to think about the technical performance requirements for your startup.  However, in many cases, this is a place where you really should be talking with a technical advisor or reaching out to get Free Startup CTO Consulting in order to understand what you need.

Monday, March 2, 2015

Los Angeles CTO / VP Engineering Job Searches

As the organizer of the LA CTO Forum, I get lots of inquiries by job seekers and people looking for CTO / VP Engineering talent. 

I’ve written quite a bit about aspects of this topic, especially from the perspective of startup founders looking for talent – you can find these in: Startup CTO.  This includes links to CTO Salary and Equity Trends, Technology Roles in Startups, Initial Conversation with a CTO or Technical Advisor, Finding a Technical Cofounder for Your Startup, Hiring a CTO for Your Startup and many others.

What I’ve not written as much about is what to do if you are a CTO looking for your next opportunity – especially in Los Angeles.  I have quite a few conversations like this and am having one via email right now, so it inspired me to put it in a post instead.

Targeting Your Job Search

The best starting place is to visit my post on: One Page Job Networking Tool.  It suggests that you start by creating a one pager that contains:

  • Background - two sentences
  • Job Sought - two sentences Company
  • Characteristics - geography, size, industry, etc.
  • Companies - a list of 25 companies that fit the bill.

This tool forces you to focus on the specifics of who you are really targeting.  When I get into a conversation with a CTO looking for their next role, they really need to know the stage of the company (pre-seed, seed, A, B, growth, pre-exit, public/on-going), size of the company – especially numbers of technical resources, geography, etc.  Ideally, they’ve thought through all of these characteristics.  It’s a good idea to start with a fairly narrow definition.

formdsIf you are going after venture-backed startups, then certainly look at socaltech.com and formds.  This will give you a pretty good initial list of companies that have raised capital in the geography.  Yes, this is going to take a while, but you need to spend the time to figure out who you are really targeting.  You should spend time looking at the bios and titles of the people in the company.  That is likely the best indicator of whether they might need a new senior technical leader.  Of course, just because a CTO or VPE is listed doesn’t mean it’s working well.

Armed with your networking tool, now it’s time to get it out to all the people you know.  You are looking both for introductions to the targets you know about, but even more importantly finding out who might have needs that you don’t know about.

What you should be gathering from this is that looking for a job is more of a sales process than anything else and there are no easy answers.  You need to start by figuring out who your suspects are.  How could you search and identify the companies that would hire you?  And then how do you move them through your pipeline?

Executive Recruiters

CTO job seekers often ask me for introductions to executive recruiters.  There are some really good executive recruiters here in Los Angeles that cover most of the CTO job searches especially for venture-backed startups.  Top of mind and in no particular order:

Note: if I’m missing someone, please let me know.

My experience has been that executive recruiters would really like to know you if you fit the profile of a current search.  Otherwise, they are not going to spend time with you.  If you think about it, that makes sense.  They are going to search out candidates when the time comes.

So, the bottom line these days is that I’m not doing these introductions.  If you have other thoughts on this topic, please comment.


VCs / Investors

Another common inquiry is, “Should I get introduced to VCs or other Investors who might need help in their portfolio companies?”  My general answer is “no.”  Much for the same reason as with executive recruiters.  The chance that you fit a specific need is relatively small.  Since they don’t know you already, it’s probably not worth their time or yours.

That said, if you already have a relationship with a VC, letting them know you are on the market is a good idea.  Actually, you should use your one-page networking document with them so they can likely help even outside their portfolio.

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.

Monday, September 30, 2013

Initial Conversation with a CTO or Technical Advisor

Are you a non-technical startup founder who’s about to go have a conversation with a Chief Technical Officer (CTO) or Technical advisory type person?   Maybe you are going for a reality check on your current situation - wondering if you have a Weak Development Team or a Startup Founder Developer Gap.  Maybe you are trying to determine what technologies might apply that you should be evaluating.  Maybe you have questions about the types of developers you need and even whether you need a Startup CTO or Developer or both.  Or you want to know about whether you have the right Web Development Company.  Or what else you might need in Document Your MVP for a Developer.

You definitely should be having these conversations in order to find out what things you might not be considering (Questions Developers Should Ask a Startup Founder) that are going to be important to your startup that as a non-technical founder you just don’t know to ask.  And this last one is why I tell every startup founder: Every Web/Mobile Startup Must Have a Technical Advisor.

Of course, when you go to have this conversation be prepared.  I recently had a phone call with an early stage entrepreneur that was incredibly frustrating.  I’d prefer that you don’t make the same mistakes.

Let me lay out at a high level the normal conversation you will have with a strategic technical person:

  • 1 min – small talk
  • 0.25 min (that’s 15 seconds) – why you are meeting
  • 10 minutes – overview of the business and key challenges
  • 30 minutes – questions and thoughts from the technical person

Let me run through these items.

The classic first mistake is to extend the small talk period.  If you’ve not already read How to Hunt Programmers for Your Startup - A Field Guide, go read what motivates and turns off a developer – CTOs and Technical Advisors are quite similar.  Small talk is not a motivator.  It’s not warming us up.  Don’t worry about going straight from “Hi, thanks for meeting with me” to “Well I want to respect your time, so let me dive in.”  Most technical people will appreciate you getting into things quickly.  Small talk is tough work for techies – so much so that people post to help techies with small talk.  Helping you with your challenges is fun.  Oh, and if you read that post, then you know that you will have earned bonus points by buying coffee, beer, whatever for the person as thanks for meeting/helping.  Yes, sadly, that still works on us techies.


The second item is important to make sure we are on the same page on why we are getting together.  “I have some immediate questions.  I’m hoping to get input on X, Y and Z, but I also want thoughts on what I might not know to ask about.  Depending on where the conversation goes, we may want to talk about how you might be involved in an on-going way.” 

The third item is REALLY important.  You need to be prepared to take the technical person through the standard stuff about the business that you would present up to an investor.  Actually, here are two posts with a pretty good list of background items you should plan to cover: Startup Software Development Homework and Free Startup CTO Consulting Sessions.  I personally like when founders have provided me this information prior to meeting for the first time.  It makes sure I know what the business really is, what’s the current state, and gives my analytic brain some time to process things.

A common, but really frustrating, situation is when a startup founder wants to hold back details about the business and product to protect themselves.  As a technical person, I’m sitting there trying to solve a problem.  But the founder is trying to hide the problem.  Argh!  I’m frustrated just thinking about it.  I personally believe the best answer is to provide what you would to an investor.  You don’t ask for an NDA from an investor before presenting.  Don’t ask it from a technical person.  If there’s some really secret sauce, let’s say a special Matching Algorithm, you maybe can hide some of the details of it.

Finally, we get to the fun part.  The technical person will begin to pelt you with questions about the business, product and technical challenges.

We are not trying to be annoying with our questions.  What’s happening is that we’ve translated what you said into initial thoughts around:

  • Business and technical risks  and mitigation strategies
  • Technical challenges and possible solutions
  • Possible third-party technologies that could be used
  • What needs to get researched, architected, built

You know how women complain that men just want to jump right to problem solving.  At the risk of offending lots of people …


Us techies are just trying to solve all of your problems as quickly as we can.  We love interesting challenges.  We want to narrow it down and try to solve it.  It would be great if you just have a big nail in your head.  Normally, it’s not clear.

Really, all the founder needs to do once we get into the back and forth is answer questions the best you can.  Sometimes you will need to give a technical person a couple of days to process things.  That’s another reason to maybe send background information ahead of meeting.

Okay, let me recap the mistakes:

  1. Not sending information ahead of time
  2. Extending small talk
  3. Not describing why you want to talk
  4. Trying to hide most of the business/product (i.e., the problem)

That’s about it.  And I feel much better now that I got it off my chest.  And I hope this will not dissuade startup founders from talking to me.  I REALLY do enjoy the problem solving.

Thursday, August 29, 2013

USC's Silicon Beach Awards and Presentations (Discount Code)

I was just down at Demo Day for the USC Incubator.  They had some pretty high quality companies presenting.  I just found out about a great award opportunity for people connected to USC (or who can figure out a connection in time).  I also have a discount code below for the event.

USC’s Marshall School of Business will host the second annual Silicon Beach Awards (SBAs), a $50,000 venture competition focused on innovation in technology & entertainment. The SBAs are a key part of the http://siliconbeachusc.com/ event which is co-sponsored by USC’s Marshall School of Business, School of Cinematic Arts, and Viterbi School of Engineering. Startups that consist of at least one USC student or alum (less than 10 years from graduation) are encouraged to enter – and have a chance of winning up to $25,000!

Silicon Beach Awards deadline is September 2!!

Apply here: http://bit.ly/1bqAGbf


Significant cash prizes will be awarded to the top 3 teams: First place: $25,000, Second place: $15,000, Third place: $10,000. In addition, the top three finishers will also receive legal services from Edwards Wildman Palmer LLP, a premier law firm located in in the US, UK and Asia who are working with Fortune 500, FTSE 250 clients and start-up companies throughout a range of industries.

Presentations Silicon Beach @ USC – September 18, USC Campus

USC will be hosting its 2nd annual Silicon Beach event on September 18 on the USC campus. Silicon Beach @ USC will feature game-changers and thought leaders from Hollywood studios, technology startups, and academia.

Presenters for the September 18 conference include:

  • Albert Cheng, EVP & Chief Product Officer, Digital Media for Disney/ABC TV
  • Hamet Watt, Co-founder &Chairman of MoviePass
  • Ric Whitney, Head of VOD/EST for Intel Media
  • Karen North, Director, Annenberg Program on Online Communities
  • David Watson, Director of Product Innovation, Kids at Netflix
  • Jason Corsello, CMO, Cornerstone OnDemand
  • Dan Brian, EVP of Media at DemandMedia.
  • Ashish Soni, Founding Director, Viterbi Students Institute for Innovation(VSi2), Executive Director of Digital Innovation, and faculty member, USC Viterbi School of Engineering
  • Jimmy Liu, CEO, Gymflow
  • Rajiv Maheswaran, CEO,  SecondSpectrum
  • Jens Windau, CEO, AIO Robotics
  • Kevin Winston, founder, Digital LA

…and others!

We will also recognize the next generation of innovators as we award over $50,000 to participants in the USC Silicon Beach Awards venture competition. 

To join us, register at https://siliconbeachusc-2013.eventbrite.com/  Use the promo code FriendOfCTM for half-price admission through Sept 11!

More info on the conference and the venture competition at http://www.marshall.usc.edu/news/events/2013/silicon-beach-usc

To register at the discounted price use the promo code: FriendOfCTM

1. Go to https://siliconbeachusc-2013.eventbrite.com/

2. Click on the “Enter Promotional Code” link at the bottom of the “Ticket Information” window

3. Add this promotion code: FriendOfCTM and click APPLY

4. Choose the Industry Guest - Early Bird ticket. Your fee will be reduced to $75 as long as you register by Sept 11. (Afterwards admission goes to $150.)

5. Choose the number of tickets (up to 4) and complete the form.