What do founders want to "Ask a CTO"?

Will Koffel Co-Founder at Outlearn

January 4th, 2014

I've been a founder or CTO more than a half-dozen times, and always find myself working with talented non-technical co-founders or CEOs (well, mostly talented...can't win 'em all, right?) I love the collaborative process of helping non-technical founders understand the product development process, tech team building, and the fast-moving and mind-numbingly large world of technology itself.

My premise is that every founder these days has to deal with elements of a technical product build, whether it be a simple blog, or a complex API-powered multi-platform enterprise mobile application. And especially for entrepreneurs who didn't grow up in the latest in-vogue "everyone learns to code" society, they will make a lot fewer mis-steps in dealing with their development team if they are armed with knowledge and best-practices.

While I'm taking some time off after my last startup exit (won't be able to stay away for long, I'm sure...), I'm writing more about these topics at http://www.clearlytech.com/

My questions to this awesome group are:

If you a non-technical entrepreneur, what are your top 3 issues you wish you had a better handle on? What are the things you'd "Ask A CTO" if you had a trusted one sitting around over beers. Anything from "Why does everyone seem to hate PHP?" to "How can I keep my developers from always shooting down my product ideas?"
If you are a technical entrepreneur, what are your top things you WISH your non-technical partners understood better? What's the stuff that would make your life easier if they understood better?

Finally, where do you find good tips and tricks if you are looking to better understand modern tech and development practices? Lectures? Books? Podcasts? Google Searching? Entrepreneur Blogs? Let's share some resources so my post isn't quite so self-serving!

Looking forward to your insights.

Michael Barnathan Adaptable, efficient, and motivated

January 4th, 2014

Simply, I wish nontechnical people understood more about how technical people work. The importance of uninterrupted time, consistent priorities, and a predictable release schedule. I view these things as prerequisite knowledge to managing a technology company.

Abigail Watson Clinical Applications Architect, Bioinformaticist

January 4th, 2014

As a developer, I wish the non-technical teams I work with would have a better handle on organic discovery-based development, rather than thinking of things as engineering tasks where they simply make a list of requirements and expect us to develop to spec. (e.g Think the aeronautical shape of airplane wings and automobile windshields were engineered? No way. They were discovered through the study of bird anatomy and using genetic algorithm searches.) Many of the most complex engineering tasks nowdays involve searching through astronomically large problem domains to find the right solutions. Development is far more often a process of organically growing and discovering how technologies can best fit together than it is 'engineering' a product.

Dave Angelow Board Member at HAND Austin

January 6th, 2014

Will

From what I've seen and experienced, decoding the technical jargon into the fundamental issues to be solved and the available alternatives is something non-technical founders/team-members would benefit in understanding.

If you focused a blog on the factors to consider in making technical choices, I think it would be a huge benefit in pulling the business/IT divide together.

For example, the post from Mr Crooke was great info, but likely not understood by non-technical team. Without background or understanding on why points of view are developed, the non-tech feel left to either fully trust the input, or be subject to conflicting input from others. How many on the non-tech side would understand the factors that need to be considered to come to conclusions like - "a large, complex application that has to deliver at scale, and IMHO a strongly typed language with multi-threading is where it's at. And true, you can make a mess of any technology, or write really clean code in something simple - the X11R4 server code is an object oriented work of art in plain C. I think MySQL is great for simple load-store stuff, but that is arguably better done in something like MongoDB, and its complete face plant on any semi-complex query drives me to distraction; also, there are now licensing issues I'd prefer not to mess with.

A blog or book on the decision factors to consider in deciding the "stack" for initial development would be a huge benefit. Once that is covered, the next core topic would be around collaboration on requirements definition via epics/stories, and managing the release roadmap.

Great stuff you're doing !

David Crooke Serial entrepreneur and CTO

January 4th, 2014

Count me in as an experienced CTO who's willing to advise too.

Alison Lewis CEO/Creative Director

January 4th, 2014

That response is great. As a designer and CEO, I wish my technology team was more flexible about deadlines and changes, and better at managing their schedules. I went and hired a product manager to help with our communication issues.

Both my designers and technologists have a challenge of giving to many specifics. I would like them to understand CEOs and founders deal with various complex issues from many different areas at once, getting too detailed into one for very long can hurt the company and their ability to lead with perspectives from many angles.

Otherwise, I love my technical team. I've learned to set objectives with their input, then make some dates and walk away and put a manager between us to sponge up all the details and pass the critical path info to me. A seasoned team working technical can do this as well.

The only question I have is why do technicals come off as so pushy about money? I've encountered many times asking for raises and asking for shares before they're even finished with the current contract. I find the methods of approach and the demands very off putting, makes me see them as having a risk adverse. It's a start up, demanding more financial compensation in the middle of a project, needs to be done with consideration and tact.

Tom Maiaroto Full Stack Consultant

January 4th, 2014

I think there's often too great a divide between "tech" and "non-tech" and somehow we continue to drive an even bigger wedge between the two "sides." I think that's wrong. There is no "side." If we're talking about a technology startup, guess what? It's technical...And the business co-founder better be on board with that and the sales people better understand what they're selling.

No one expects the "non-tech" co-founder to code...But like Michael said here, insight to just a little bit of the tech process is important. Understanding how the tech works is also important.

I've seen a lot of non-tech people go out and sells clients on something that simply wasn't possible, didn't exist, or was just described all wrong. Did they lose the sale? No! Funny enough...They were good sales people, the client bought the damn thing and then the tech team had to deliver. This is a very common problem. Another common problem is then failing to deliver what was promised. Both preventable.

Likewise though, the technical stakeholders don't typically understand business goals that well. They may want 10 years to build the best program in the most 1337 language and hibernate in some cave. Unfortunately that's dangerous.

This is where we kinda get into your question about "Why does everyone seem to hate PHP?" ... That's a terrible circumstance that's going around the web. Not just PHP, all language "wars" and "haters."

The internet is the wild west. There's really not many rules and if you ever come across a "CTO" who tells you that they only need one language/tool and all others are terrible - then ditch them. IMMEDIATELY. I can't express has fast and how far you must run away from them. A CTO should not "hate" on any language (or database). Dislike? Not be familiar with? Sure...But you MUST be open to using whatever is at your disposal in order to meet your business and product goals. The job must get done and if you use the wrong tool for the job, it could cost you your business. Again, preventable.

The decision on your technology stack, of course, may not come from a CTO either. Want to be a Billy Bad Ass and use some "enterprise" solution because some company sold you on the license and told you there's a 99.99% SLA and it's the jam? Some investor with a ton of money told you "this is how we do things partner" ? Well, you may need to be prepared to budget for the development and time costs. Often using those "enterprise" solutions means you're working at a speed disadvantage. There's far too many startups and noise on the internet to be slow here.

Some other quick food for thought. IF you can safely build a product faster by using a different language, driving down your development costs -- how much more of your company to you get to retain? If you need less funding to build? Just food for thought.

However, we often see people vying for these kind of solutions because we might have someone who's background has always been from a slow corporate machine perspective. Or you have an investor or business co-founder who has bought into the false sense of security that some languages or "enterprise" tools like to push off onto people. Your technical tools should never be sold on you. They must be the right tool for the job and sometimes that requires some research and digging.

Just remember, it's the wild west. It would behoove all parties to understand how shoot a gun, ride a horse, and cook food. Otherwise you're eventually gonna starve out there. Metaphorically speaking of course =)

Will Koffel Co-Founder at Outlearn

January 4th, 2014

Michael and Alison, your point about the different working styles and different processing of priorities, urgency, and deadlines is totally a classic one I see all the time, thanks for bringing it up.

I posted one of my favorite reminder graphs on the topic recently:

http://www.clearlytech.com/2013/12/15/working-makers/

Alison, developers asking for more in the middle isn't too common, I don't think. Sometimes, it's just the market conditions right now, correctly or hype-fully telling developers they are worth more than they are getting. But often it's a side-effect of them losing confidence in what's being built, so they get nervous and want to make a grab for a bigger piece of what they perceive as a smaller-pie. Have a discussion with them about why they don't think their current stake is going to have a huge impact for them. Ask them if they wouldn't rather hire more great people with that extra equity, so everyone's stake gets larger. Might help tease out why they are nervous and getting greedy.

Tom Maiaroto Full Stack Consultant

January 4th, 2014

Well, I don't know. PHP has plenty of meaningful errors. Xdebug is your friend...And you can even step through things, trace, etc. (some assembly required). If you use a framework, then you'll even have some super meaningful exceptions being thrown with messages. I've always found PHP to be the easiest and fastest language to debug. Though I definitely agree, you've got a much nicer debugging system in compiled languages and while you can debug PHP - it's not setup out of the box for you to easily do that. Also, it's on you to find a really good IDE whereas with Java it's just known to use Eclipse and doing so gives you everything you need without hunting. Can't say that for PHP or Node.js, etc.

As far as "serious enterprise" ... there's that word again "enterprise" ... I'd like to know what that means to people (maybe another thread would be good there). Because I think that word itself leads to a lot of this confusion between tech and non-tech.

I've deployed many large scale applications with PHP and to be frank, RollingStone.com crashed daily under Java until we re-built it in PHP. Granted you'll find horror stories with all languages, but I wouldn't say PHP is incapable of living in the "enterprise" and being used for "heavy duty" things. Though, yea it's not going to build your next instant messaging app. In fact, when it comes to PHP web apps, it's more likely that your database is your bottleneck (given that MySQL is the most common DB you see paired with PHP). ...And what about Zend? That's an "enterprise" framework. So again, back on the subject at hand, is this "enterprise" word creating a problem between tech and non-tech? I think people interpret that word to mean many different things and that's unhealthy.

David Crooke Serial entrepreneur and CTO

January 4th, 2014

Fair comment on "enterprise" ... my take is a large, complex application that has to deliver at scale, and IMHO a strongly typed language with multi-threading is where it's at. And true, you can make a mess of any technology, or write really clean code in something simple - the X11R4 server code is an object oriented work of art in plain C. I think MySQL is great for simple load-store stuff, but that is arguably better done in something like MongoDB, and its complete face plant on any semi-complex query drives me to distraction; also, there are now licensing issues I'd prefer not to mess with. I switched to PostgreSQL as a MySQL replacement a few years ago and while there is a bit of a learning curve with the admin tools, it is very solid. Putting the CTO hat back on ... as someone mentioned earlier, technology choices need to be based on pragmatism, not religion. I've used over 30 programming langauges professionally over the years. Even if the tech is not state of the art, a compelling argument for LAMP is that it's easy to hire junior to mid level people to work in it. My current "consulting client on the side while putting startup together" is a web shop with a 4 person dev team, LAMP is a no-brainer for them. Cheers Dave

Alexis Nguyen

January 4th, 2014

Will-

From a non-tech standpoint, it seems that the chasm is often a result of unclear and nonconcrete expectations set by both parties. Which usually leads to a lack of understanding of the expectations and overall mis-communication. Understanding each other’s modus operandi is also important, like Michael mentioned in his post above, which was very helpful “Simply, I wish nontechnical people understood more about how technical people work. The importance of uninterrupted time, consistent priorities, and a predictable release schedule.”

I want to improve my communication skills with those who have a tech background, if you guys (CTOs) could help me by explaining your thought processes when you approach developing a product vision brought forth by the other founder/CEO.

Question stats