CEOs Are From Mars, CTOs Are From Venus: Bridging The Startup ...

This blog is written by a member of our expert blogging community and expresses that expert's views alone.

The faltering economy has given birth to a very healthy startup movement. Web applications are being built and deployed constantly, and everywhere there are founders with great ideas for solving common problems online.

Over the past three years I've had the pleasure of working with startup founders on some of their first web applications as CTO or interim CTO, and I've met dozens of others in the same position. Along the way, I've noticed a large communication chasm between developers and many startup founders. Many founders come to me because feel they have been "abandoned" by their developer, or have found them lacking and let them go.

Now, if a founder tells me something like "This is the 5th, 6th, 7th, 12th developer that has screwed me over," that is an automatic red flag, run for the hills, do not pass go sign. I don't even consider people in that position--those who don't even question if it is possible that they are the problem. However, if this is the first time they've been through something like this, I really like to dig in and help them tackle the issues. Even if I'm not going to be working with them, examining these issues enlightens my understanding of relationships with clients.

The communication between CTOs and startup founders is akin to communication in relationships between men and women: Each side has a different chemical makeup, motivations, and ways of defining success. (In my world, same-sex relationships are blissful). The following rules have helped me form healthy relationships with startup founders--I thought I'd share them in the hopes they would do the same for you.

1. Master the fine art of communication.?

Often it?s a complete lack of communication that breaks up these types of partnerships, and they usually don't start out that way. It's very easy for communication to start out great, then slowly dwindle down to nothing as people get busy with meetings, schedules, and commitments. To ensure that doesn?t happen:

• Initiate daily communication: If you are working remotely, or you don't share office space, getting a good feedback loop can be extremely difficult. Usually, relationships like these start out great, expectations are clear, and people get to work. However, this disintegrates as features are added, hurdles are hit, and deadlines are extended. I have seen countless situations where a founder says "I want this," hands over some specs, and walks away for a few months. When they come back, they are expecting a perfect product, and if it isn't ready, shit hits the fan. The only way to make sure things don't break down is if you take responsibility for making sure that they know exactly what you are working on, and when you expect it to be complete, and when you run into unforeseen issues. Regardless of whether they reply, they will appreciate you keeping them up to date.
• Founders are not stupid, they are just not technical (usually, that is--some are, and that's always a little easier). Explain everything to them. I mean everything. I break things down in the most understandable way possible, down to the function I am building--especially when I run into a hurdle that causes a delay. When you explain to them what is going on, you show that you respect them, their time, and their money.

2. Choose a stack.

A stack, as the term is applied to software development, refers to the languages and frameworks that make up an application. Languages like Ruby, Python, Lisp, JavaScript, and many more offer different advantages and disadvantages when building software. One big task new to most people in the CTO position is being the person in charge of coming up with a game plan, a timeline, and a stack for what a web application should support. This can be daunting, but it doesn't have to be. These are some things I have observed on my way:

• Be careful to balance budget and priorities.What you would like to build is a completely custom application in a framework?you've been wanting to play with for a while.?This isn't always the best thing for the client/founder, as they are working within a specific budget. What most of them would like is for you to augment existing tools to do exactly what they need for their app. There is a middle ground on this. Scalability is completely overrated when it comes to MVP. Sometimes, the priority is to get something together that works for now, and revisit the idea should the platform be successful. However, you don't want to make an unusable mess that no one else can work with. The only way to find this balance is to carry the process out a few times and learn from your experiences--this is okay.
• Always build as if at any moment you could pick up and move off the project, because you may need to--for budget reasons, chemistry reasons, or "hit by a bus" reasons. Try to keep things very readable and document if you can. You don't want to leave the founder completely stranded should they need to replace you.
• Don't do something "new" or "cool" unless you discuss it first. Recently, I had a full lifecycle application project come up. I let the founder know I was interested, but wanted to build the application in Node.js, a framework I hadn't yet worked with. I explained that I wanted to do something new and I thought Node.js would be a great platform for them. I went into the benefits of Node, and she was on board.
• Don't do more than one "new/cool" thing per stack. Building an application while learning a new technology is hard, building an application while learning many new technologies is impossible--you're setting yourself up to fail.

3. Enable others to work better.?

The biggest mistake I see in CTOs is when they make the codebase their fiefdom and then provide nothing but resistance to the people they manage. Your job is to enable better development, and ultimately, to only be in charge, but also make the lives of your developers easier. Many CTOs are emotionally attached to their application and believe only they can add value to it. You need to let others screw things up in the beginning and then train them on how things should best be done. After a while it will be as if they are extensions of you.

Also, guess what? Some people are better than you at things, and that's great! The idea is to hire people that are, and to learn from them. Let people do well at things they are good at, and thoroughly vet the ideas you don't agree with. The way to make people enjoy working for you is to respect them, not to constantly tell them they are wrong.

4. Say "no" early and often.?

I don't know about you, but I tend to like making people happy. Sometimes, I'm super tempted to say yes when I know it's not right in order to put smiles on faces. Everyone knows this makes no one happy in the end. The following are situations where you should definitely say "no":

• When a founder asks you to abandon best practices to save time/money. If you do this, you will resent them and make a subpar product. Don't bend on your convictions.
• When you get asked to bend on your pricing or do a particular feature for free. Often these founders are working out of their own pockets; however, asking you to skip meals so they don't have to isn't fair if they have ownership of your work product. You say yes now, you'll hate them and yourself later when it's 2 a.m. and you're still working for free.
• When you get asked to make an estimate shorter. Robert C. Martin wrote a great book called The Clean Coder that deals with this issue quite well. He claims it's our responsibility as developers to make the best estimates we can, and then not budge on them. When we do, we create unrealistic expectations, and then create a precedent that our estimates are flexible and our time is unimportant.

5. Suck a little less every day.?

Lastly, and most importantly, forgive your own faults. Jeff Atwood coined the mantra "Suck a little less every day." I take it to mean that I should try every day to work a bit harder and learn more about what I do. As developers, we often look at code that is only a few months old and say "This is crap!" We need to look at our relationships with clients/founders the same way. Communicate a little better today, work a little better today, and inspire people around you to be excited about your product.

[Image: Flickr user Keoni 101]

kelly clarkson national anthem halftime show super bowl halftime show 2012 ahmad bradshaw tom brady halftime super bowl 2012 super bowl score