5 ms·

CEOs Are From Mars, CTOs Are From Venus: Bridging The Startup Communication Gap

21 points by iknowl 15y ago

j_baker 15y ago
I like this article. It strikes a great balance between "just make it work" and "new stuff for me to play with!". Plus, it encourages CTOs to stand up to CEOs, something I wish more of them did.
Ixiaus 15y ago
Good article, terrible title - I instantly said to myself, "WTF? Is this an article about the 'masculine' CEO and the spineless techie? Fuck that." but I read it anyway because I didn't want to be "that guy".
- Symbol 15y ago
  I agree that the title evokes a weird battle-of-the-sexes vibe. I also found the content to be pretty good. From personal experience, I can't stress enough that CEOs, self-professed "business guys/gals", need some grounding in technology if you are doing a tech startup. It seems so obvious, and yet I'm sure everyone has a story about the guy who said "we'll get to market 3x faster because we can build it on rails"
zmitri 15y ago
Pretty good article. I'm a technical founder who is working with a "not-so-technical but getting more and more comfortable" founder and I've found a couple things to be useful: 0 - Speak in dead simple terms at first. Once they understand what you're talking about, feel free to get more detailed. This is key when you're pitching your product to other companies too! 1 - White board everything. Drawing diagrams and visualizing flow makes things much easier for me to explain to him, and for him to understand. When he comes up with an idea, and I break it out step by step it definitely makes him appreciate what's going on. We just released an api https://github.com/goodkarma/gk-api https://github.com/goodkarma/gk-api and because I had drawn out all the steps, he already understood the whole process and was able to pitch the technical details to developers the day I finished. I thought that was very impressive. 2 - Explain the different components of the system to them. Not too in depth, but talk about how web proxies work, the underlying web app, the notion of templating engines, the code structure and organization, queues and workers, apis you use, and cron processes. They don't need to see all the implementation but it gives them a huge appreciation for the complexity of the underlying system and when they come to you with ideas, they will have some sense of how it can be accomplished. They may be off at first but they get much better when you provide them with what they need. 3 - When you run into a problem, accomplish something interesting, or do something that you believed to be outside of your core competencies, let them know, and explain what you did. Even if it's something simple, they will generally appreciate it. 4 - Don't get wrapped up or annoyed with them getting too far ahead of themselves. A lot of the time you will be working on solving a current problem, and they will be thinking of other things to do in the future (Not that you aren't doing that too). Either hear them out, or ask them to table it until you finish what you're doing. For me it's not ideal if they do it in the middle of a super productive hacking session, so I often have to tell him, "not now, this needs to get done first". 5 - When you aren't in hacking mode you should hang out and talk. Little bursts of banter often turn into disruptive ideas. The number of cool tweaks and iterations that have come out of seemingly random conversations is surprising. 6 - Bond over things that aren't directly related to your company. Right now, our thing is "Drake and/or Lil' Wayne lyrics" because they are about hustling all the time. Communication.
- iknowl 15y ago
  Interesting, I completely agree with your views. I believe your way of handling should be followed by every CTO.
  - zmitri 15y ago
    I think it depends on the team dynamic. If he were technical it would likely be different. Don't think there's a "list of things to do" but communication, mutual respect, and being absolutely driven animals does help.
ktizo 15y ago
Am in my third week of trying to organise one day of sober work with the person who is supposed to be a co-founder of a business I am trying to get started. The problem I seem to have with trying to do technical businesses with non-technical people is trying to get them to do any work at all unless there is a bar involved.
- iknowl 15y ago
  Well, if a non-technical co-founder is adding value to the business it's worth it. Every business either technical or non-technical requires certain non-technical founders who can thrive sales and manage business aspects. Each founder should divide work and focus on their own part in the business.
prplhaz4 15y ago
The relationship this article describes is not limited to the startup world - it is quite prevalent in big tech as well. The key to unlocking the dynamic is communication - a piece that a lot of techies think they do well, but don't. One of the biggest hurdles I've encountered is explaining to a business customer what the impact of something is in their terms - it's not shitty code, it's an approach that will prevent us from scaling in the future.

21 points by iknowl 15y ago

I like this article. It strikes a great balance between "just make it work" and "new stuff for me to play with!". Plus, it encourages CTOs to stand up to CEOs, something I wish more of them did.

Ixiaus 15y ago

Good article, terrible title - I instantly said to myself, "WTF? Is this an article about the 'masculine' CEO and the spineless techie? Fuck that." but I read it anyway because I didn't want to be "that guy".

Symbol 15y ago
I agree that the title evokes a weird battle-of-the-sexes vibe. I also found the content to be pretty good. From personal experience, I can't stress enough that CEOs, self-professed "business guys/gals", need some grounding in technology if you are doing a tech startup. It seems so obvious, and yet I'm sure everyone has a story about the guy who said "we'll get to market 3x faster because we can build it on rails"

zmitri 15y ago

Pretty good article. I'm a technical founder who is working with a "not-so-technical but getting more and more comfortable" founder and I've found a couple things to be useful: 0 - Speak in dead simple terms at first. Once they understand what you're talking about, feel free to get more detailed. This is key when you're pitching your product to other companies too! 1 - White board everything. Drawing diagrams and visualizing flow makes things much easier for me to explain to him, and for him to understand. When he comes up with an idea, and I break it out step by step it definitely makes him appreciate what's going on. We just released an api https://github.com/goodkarma/gk-api https://github.com/goodkarma/gk-api and because I had drawn out all the steps, he already understood the whole process and was able to pitch the technical details to developers the day I finished. I thought that was very impressive. 2 - Explain the different components of the system to them. Not too in depth, but talk about how web proxies work, the underlying web app, the notion of templating engines, the code structure and organization, queues and workers, apis you use, and cron processes. They don't need to see all the implementation but it gives them a huge appreciation for the complexity of the underlying system and when they come to you with ideas, they will have some sense of how it can be accomplished. They may be off at first but they get much better when you provide them with what they need. 3 - When you run into a problem, accomplish something interesting, or do something that you believed to be outside of your core competencies, let them know, and explain what you did. Even if it's something simple, they will generally appreciate it. 4 - Don't get wrapped up or annoyed with them getting too far ahead of themselves. A lot of the time you will be working on solving a current problem, and they will be thinking of other things to do in the future (Not that you aren't doing that too). Either hear them out, or ask them to table it until you finish what you're doing. For me it's not ideal if they do it in the middle of a super productive hacking session, so I often have to tell him, "not now, this needs to get done first". 5 - When you aren't in hacking mode you should hang out and talk. Little bursts of banter often turn into disruptive ideas. The number of cool tweaks and iterations that have come out of seemingly random conversations is surprising. 6 - Bond over things that aren't directly related to your company. Right now, our thing is "Drake and/or Lil' Wayne lyrics" because they are about hustling all the time. Communication.

iknowl 15y ago
Interesting, I completely agree with your views. I believe your way of handling should be followed by every CTO.
- zmitri 15y ago
  I think it depends on the team dynamic. If he were technical it would likely be different. Don't think there's a "list of things to do" but communication, mutual respect, and being absolutely driven animals does help.

ktizo 15y ago

Am in my third week of trying to organise one day of sober work with the person who is supposed to be a co-founder of a business I am trying to get started. The problem I seem to have with trying to do technical businesses with non-technical people is trying to get them to do any work at all unless there is a bar involved.

iknowl 15y ago
Well, if a non-technical co-founder is adding value to the business it's worth it. Every business either technical or non-technical requires certain non-technical founders who can thrive sales and manage business aspects. Each founder should divide work and focus on their own part in the business.

prplhaz4 15y ago

The relationship this article describes is not limited to the startup world - it is quite prevalent in big tech as well. The key to unlocking the dynamic is communication - a piece that a lot of techies think they do well, but don't. One of the biggest hurdles I've encountered is explaining to a business customer what the impact of something is in their terms - it's not shitty code, it's an approach that will prevent us from scaling in the future.