SoCal CTO

Tuesday, April 25, 2017

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.

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.

Homework

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

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.

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.

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.

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.

Complexity

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.

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.

If 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:

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.

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.

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.

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

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

Challenges

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

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

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

Developers like to over engineer. They often don’t take into account the actual business need. In fact, they often don’t really understand the business.

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

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

Developers like to do things their way even when it doesn’t meet the needs of the business.

Developers don’t communicate well

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

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

Developer Motivators and Demotivators

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

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

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.

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

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

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.

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:

Not sending information ahead of time

Extending small talk

Not describing why you want to talk

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.

About Me

Dr. Tony Karrer works as a part-time CTO for startups and midsize software companies - helping them get product out the door and turn around technology issues. He is considered one of the top technologists in eLearning and is known for working with numerous startups including being the original CTO for eHarmony for its first four years. Dr. Karrer taught Computer Science for eleven years. He has also worked on projects for many Fortune 500 companies including Credit
Suisse, Royal Bank of Canada, Citibank, Lexus, Microsoft, Nissan,
Universal, IBM, Hewlett-Packard, Sun Microsystems, Fidelity
Investments, Symbol Technologies and SHL Systemhouse. Dr. Karrer was
valedictorian at Loyola Marymount University, attended the University
of Southern California as a Tau Beta Pi fellow, one of the top 30
engineers in the nation, and received a M.S. and Ph.D. in Computer
Science. He is a frequent speaker at industry and academic events.