NYC Start Up CTO

Here’s what not to do as a start up CTO: use a completely new set of technologies to build your product, stuff you’ve never used before or have little experience with.

Why?

You’re usually convinced that the idea you’re working on has a place in the market.  Therefore your number one goal should be to create value.  The more product you build that customers like and use, the more value you’re creating for the business.  Eventually you want to prove enough value that you attract investors.  But they need to be convinced that you have a product that cannot easily be copied and that, aside from just satisfying customers, has some intrinsic value that may lead to an acquisition.

From a software perspective, what is value?  It’s really good code that is high quality and well tested.  It’s used to create features that satisfy specific user needs while strengthening the overall product.  The more code I write, the more value I create.

There’s also value in creating a lot of product that doesn’t work out as expected because this allows the team to abandon features that would otherwise consume development cycles and not get used by customers.  But in both cases you need to move quickly, write a lot of code, try a lot of things out to figure out what works and what doesn’t.

As a developer, I’m far more capable of producing lots of top quality code using tools and systems that I’m familiar with and that I’ve built things with in the past.  There is an inherent level of bugginess that a programmer is going to introduce programming in a new language – things get done in a way that work but are not necessarily the correct or maintainable way.  A lot of time can be wasted figuring out how to best integrate the various pieces being brought together – what library is best to use to connect PHP to MongoDB?  Which gem should I use when incorporating payment processing into my Ruby project?

A start up CTO recently told me that he had decided to use Ruby, MongoDB and Node.js for his current project.  I asked him why and he remarked that he felt he needed to learn them and this was a great time to do it.  If you want to learn new languages or technologies, jump into the next hackathon and hang out with other experts that can quickly show you how to use the tools.  Or buy a few books and spend a weekend messing around generating tons of questions to post to message boards and mailing lists.

Two important points that I don’t want misconstrued: 1) the proper process for prioritizing features is absolutely essential.  I’m not advocating that you just build software until you stumble upon value.  Build value based on customer driven development.  2) You cannot build a web application on yesterday’s standards because you will have a hard time attracting the talent you need to lead.  It is very tricky to balance the need for practical technical solutions and bleeding edge implementations for the sake of experimentation.  So tread lightly here but don’t let your stuff get old.

1. You can try to be a concert pianist playing with only 2 fingers but it’s probably not going to happen.  If you want to code in the big leagues, learn to touch type.
2. Master your editor.  If you don’t get to choose what editor you use, master the one you’ve got.  Any amount of time spent figuring out keyboard short cuts or flipping between screens is killing you.  More importantly, know the minimum set of commands and functionality you need to get your editor out of the way and put the code front and center.
3. You suck at tabbed terminal windows.  Trust me.  If you spend more time finding the window you need to access versus the amount of time you spend in that window then it’s time for a new strategy for organizing your terms.
4. Email, instant message and text message alerts are seriously destroying your productivity.  Get in the game - turn them off while you’re coding (an activity during which you don’t want to be reached) and when you’ve put down the tight algorithms and are ready to celebrate turn them back on.
5. If you’re still trying to figure out your coding style, you’re wasting your time.  Should I put a space there or not?  Should I hit return once or twice?  What comment style do I want to use?  All of these questions are taking your focus away from putting code in with a clear head to ensure you get the logic right.
6. Consistency is the key to keeping your brain focused on the meaning of the code, not the layout and structure.  Do the same things the same way every time.  That way when you open your code you can start seeing the logic and not whether or not the semicolon is in the correct place.
7. Discovery (taking time to research a project in order to provide a realistic estimate) should never, ever, ever take more than 1 hour.  If you aren’t hot on the trail of your solution after 1 hour you aren’t the right person for the task and should find someone else to pick it up.  After 1 hour you may only be close but you should be able to give a low and reasonable estimate as to how much more time you need to get it over the line.
8. When my car GPS system tells me we’ll arrive at 3:10pm that’s not information, that’s a challenge (to quote the Doctors Finkielstein).  You don’t make estimates and set deadlines to please “business people”.  You do it to keep yourself honest, on point and to push yourself to out do yourself.
9. Unit testing does not add overhead.  Let me say that again more slowly - unit testing…does not…add overhead.  Lack of unit testing, does.  When you need to refactor and you don’t have tests you’ll be orders slower than someone who has solid test coverage.
10. The foundation of your skyscraper consists entirely of your datastore’s data structures.  If you get these wrong all you’re doing is constructing a system that is guaranteed to fail.  If you haven’t mastered your datastore take the time to do so or pair up with someone that has.
11. “It’s just a prototype” is the dumbest thing you’ve ever said.
12. Your lack of social skills and/or business acumen is not OK because it’s the stereotype for developers.  It’s a failure by you to transcend the #1 reason developers continue to perpetuate the myth that “we know everything” and business people are “lusers”.  Put on a nice shirt, comb your hair, study P&L and come to work to collaborate…not to be I.T.

These thoughts are written just as much for my team @CrowdTwist as everyone else.  They are relevant because of our current growth and the uncertainty around position, title, stature, etc. that comes with adding a lot of new people quickly.

We’re rapidly mixing in new ideas, ways of working, opinions, and attitudes into a system that has been running exceedingly well for over a year.  I want to make sure everyone on my team is active in nurturing and mentoring new hires into feeling welcome and giving them the freedom and comfort to take risks and contribute without fear of judgement.

How do we do that?  I have to ask everyone to change how they think about new hires.  In most organizations a new hire is only potentially a member of the team after they’ve completed a probation period and have gotten the team leadership to sign off on making them a permanent addition.  This approach is perfectly acceptable but largely puts at risk the new hire - no one wants a gap in their resume because they were removed during the probation period.

We hire someone with a commitment that they likely aren’t right for our team day 1 but we are going to put in the time to nurture, mentor, and show the ropes.  It’s a considerable effort for some on the team that already have multiple jobs and now have to help us get another team member in top shape to start producing.

My team has to trust me (as I have to trust the others hiring) that I’m bringing people that are worth placing a bet on.  If I’ve done my job the person is highly intelligent, motivated, in love with what we’re doing and eager to quickly get engaged and start contributing.  Sometimes it doesn’t always feel that everyone fits those characteristics.  When we are confronted with those circumstances we need to remember our commitment and work a bit harder to mold our new team member to fit exactly where we need them to be.

See who Team @CrowdTwist is at Our Story.