Monday, December 3, 2018

Top CTO Challenges for 2019

Southern California Tech Central Best ArticleThe LA CTO Forum recently conducted a survey to find out what our Chief Technology Officer (CTO) members saw as their biggest challenges heading into 2019.
We received over 250 responses that provides a pretty good insight into the top CTO challenges.

The rating scale was 1-5 with:
  1. Not a challenge
  2. A small challenge
  3. Somewhat a challenge
  4. Definitely a challenge
  5. Keeps me up at night

We provide both an Average and a Scaled Rating that gives much higher weight to 4s and 5s and discounts 1s and 2s.

Here are the Top CTO Challenges for 2019 sorted based on scaled rating - biggest challenges first.

Recruiting, Hiring, Sourcing and Onboarding3.530.48
Appropriate Security for my Organization3.490.47
As a tech leader, where do I spend my time3.450.46
Personal Career Planning3.150.40
Business Metrics for CTOs / engineering3.200.39
Motivation of engineering team3.210.39
Tech Vision and Tech Roadmaps3.190.38
Talent Management, Career Development of team3.240.38
Organization and Structure of engineering team3.150.37
Managing Technical Debt3.180.36
Executive Presence3.060.36
Architecture Decision Making / Reviews when you are not the architect3.110.35
How to find, explore and choose new technologies 3.030.34
Capacity Planning and Resource Forecasting3.060.34
Testing / Test Automation3.050.33
Technical Metrics3.040.33
Relationship with CEO2.880.33
Relationship with CxO Peers (Marketing, Sales, Service, Operations)2.880.31
Management of DevOps, Site Reliability Engineering2.950.31
Collaborative Decision Making2.950.31
Integrating Offshore, Remote and In-House Engineering2.810.30
Effective Agile Management, e.g., Flow Efficiency, Sprint Boundaries2.900.30
Working with Product Management2.850.30
Delegation & Prioritization2.870.29
Sourcing and Managing Remote engineers2.770.29
Engineering Management Team (Direct Reports)2.820.28
Sourcing and Managing Offshore engineering2.620.26
Complex Technology Partnerships & Vendor Negotiation2.680.25
CapEx/OpEx optimization2.650.25

It's not surprising that Recruiting and Security are at the top.  I was a little more surprised by topics such as "Where do I spend my time" and Personal Career Planning near the top.

Similarly, I was surprised that "Working with Product Management" and "Effective Agile Management" were not bigger challenges for most members.  These have perennially been a much bigger challenge.  Maybe we CTOs are improving.  

We are looking forward to interesting sessions in 2019 on this topic.  I would expect that we'll see some of these discussed on CTO Universe as well.

Anything surprise you?  Or something that we missed?

Tuesday, April 25, 2017

Finding Startup Developers - First Email Contact

Here is the most recent version of an all too common email inquiry from a startup founder.  I've removed the two words that described the market - otherwise this is verbatim.
I'm working on a start up idea in the XXX market with my partner and we are currently looking for full stack developer to join us as a technical co-founder. We have been reading about the LA CTO Forum and we thought it would be a great place to find him/her.
Please let me know if you can share this information with your members. 
Paris Tuileries Garden Facepalm statueI've written before about having an Initial Conversation with a Potential CTO.  That post and How to Find Programmers for You Startup - a Field Guide both lay out a lot of the tactics that will prepare a founder for important early conversations.

The above email is SO BAD that I feel compelled to treat this email as a special case so maybe I can help other founders before they send this email.  Or at least send them a link to this post if they have already sent something like the above and let them know what I would have wanted instead.


I don't think that this founder has looked at my blog or my background.  If they had read either of the above articles or the 10 other on my blog, then they would have sent me something else.  So, why should I spend time if they've not spent time?

Startup and Founder Backgrounds

This is a cold email. I don't know the individual or his partner.  And I don't know anything about the business.  If you want me to take you seriously, then get me interested.  What background do you have?  Why is this a great startup?  What have you done so far?  This should be your elevator pitch. Get me interested.  And please include LinkedIn URLs so that I can easily find your background.

Of course, this needs to be "elevator size" - 3 to 4 sentences.  Otherwise, I won't get to your ask.

Think About Your Ask

Likely many startup founders, they want help getting their startup concept built.  The way they expressed it "technical co-founder" is code for find someone who will work as an Equity Only Developer.  It's really hard to find and super competitive to find developers who are going to jump on a concept and build it.  That's not going to be a successful outreach.

Go read the above posts and you'll hopefully reframe the question and do it much better the second time.

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