Archive for January 2009
The Boulder CTO Lunch meets once a month with a guest speaker and covers topics and questions that startup CTOs should find interesting. This month, the group had Sanjiv Bhargava from StillSecure come talk with our group. Before becoming VP of product development at StillSecure, Sanjiv was VP of Technology at Symantec Corporation. Sanjiv was also involved in some startups that failed and others that succeeded (selling a consulting company he founded). I will share highlights of the discussion, but since this was a open, free-formed discussion, I am sure I couldn’t capture everything and not all my notes are completely accurate.
Remote vs. Local employees
Sanjiv has worked with geographically dispersed teams in the past, but recommends working with everyone under the same roof if possible. He said that for small teams it is very helpful, as you build teams you need to build relationships.
“One of the best parts of starting a company is you get to create the company culture”
A team is a reflection of the leader, or you can switch it around, a leader is a reflection of a team because the leader builds that team.
The first hire to a small team has a huge impact on corporate culture, which can be good, but be aware of it.
What makes a good team?
* getting the right team chemistry
* sometimes make a compromise on technical knowledge but not on culture and team chemistry.
As a small startup, you don’t have time for team building exercises, if you need those at this level you have the wrong people in the company
The corporate culture is set by who you are. For example, if your office has a ping pong table and you never play ping pong that sets a culture to never play – focus on work. To play or never play: either is OK, but your actions as a leader set it.
Have an open dialog with a problem employee to figure out what is going on. Maybe things can be turned around.
In small startups you need to cut your losses on employees fast and early.
There is never an easy or easier time to get rid of someone.
Think of the other employees you have. Good startup employees know the bad hire isn’t working out, and they don’t like having to carry their dead weight.
“Sometimes it would take you 2 hours to do something, or it take 1 hour of training and 4 hours for the new employee the first time. You have to take the trade off.”
Everyone chimed in on evaluations from the group, some of the thoughts are below.
* Every 6 weeks have a quick meeting. “Here is what you did awesome, here is what you could improve”
* Discuss as part of a team. What can I change? What can we improve on as a team? Have them evaluate you as a leader as well.
* A quick weekly meeting. What is not going right? What is going well? Go over what goals were met from the previous week. Have a meeting to set goals for the week and the year.
* It isn’t about management recognition, it is about team recognition. Group support and group recognition.
* Don’t have meetings. Do it on the fly, why wait to tell someone something is awesome or something wasn’t up to par?
The CTOs Role
* Ask ten different people what is the role of a CTO and you will get ten different answers.
* The CTO role is decided by what fits the company.
* It is a role that is a combination of business and technology.
* Two types of visionary CTOs, “How do I grow the business?”, or “How do I scale the technology or broaden the feature set?”
* One of the biggest mistakes we make is we try to pigeon hole people into boxes and defined roles.
Thanks everyone for attending our January CTO lunch. Thanks to Sanjiv for helping lead a great discussion. Also, thanks as always for TechStars for hosting our group. If you are interested in joining our CTO lunch shoot me an email dan devver.net, and I can get you on the email list.
At Devver.net, we send out weekly email updates to an awesome set of mentors. We do this for a number of reasons. First and foremost, we get valuable feedback and advice from our mentors on a variety of issues. But it’s also an easy and effective way to keep us on track and even maximize our chances of success. As Paul Graham says in How Not To Die (he was talking directly to YC teams, but you’ll get the idea):
“For us the main indication of impending doom is when we don’t hear from you. When we haven’t heard from, or about, a startup for a couple months, that’s a bad sign.
Maybe if you can arrange that we keep hearing from you, you won’t die.
That may not be so naive as it sounds. … [The] mere constraint of staying in regular contact with us will push you to make things happen, because otherwise you’ll be embarrassed to tell us that you haven’t done anything new since the last time we talked.”
Foodzie started emailing their mentors early in the summer. We actually borrowed (stole) their email format and best practices.
One thing we’ve tried to not do is send out a completely generic email to all our mentors. Depending on the content and the interaction we’ve had with a specific mentor, we’ll adjust his email accordingly. We begin each email with their name and send it directly to them (in other words, we don’t put a huge list of addresses in the To, CC, or BCC fields). We do this because we can tailor it and it helps elicit individual responses from each mentor (it’s easier to ignore a question if it’s sent to a group).
But, of course, sometimes the emails to a few mentors can be identical. In this case, my not-so-well-kept secret is that I just use a simple Ruby script to send out a duplicate email that appears to be hand-crafted (or at least copied and pasted).
I’ve been told that Outlook can perform this functionality easily, but I don’t know of any way to do this within Gmail. If there is, let me know so I can feel a little silly (in any case, the Ruby code was fun to write).
To run this code, you’ll need to install the highline gem. You’ll also need to add your Gmail account, recipients, subject message, etc. Finally, you’ll want to put your message inside a separate file within project directory. That way, you can easily modify, spellcheck, and format to your heart’s content before sending.
You can get the entire gmailr source code (all two files!) at Github. Please use this script for good, not evil – no one likes a spammer. Enjoy!
The Ruby community is always quickly moving, changing, and adopting new things. It is good to keep your ear to the ground so you can learn and adopt things that the community is finding really useful. There are a number of ways to do this, like watching the most popular Ruby projects on GitHub, most active projects on RubyForge, Ruby Reddit, or listening to the Rails podcast. The way I have found most effective is following a good collection of the Ruby community on Twitter, many of the most active Ruby community members and companies are on Twitter. It is where I have first heard of many things going on in Ruby like the recent Merb/Rails merge.
jamis / Jamis Buck
obie / Obie Fernandez
chadfowler / Chad Fowler
engineyard / Engine Yard
d2h / DHH
rjs / Ryan Singer
jasonfried / Jason Fried
_why / why the lucky stiff
gilesgoatboy / Giles Bowkett
dlsspy / Dustin Sallings
julien51 / julien
rbates / Ryan Bates
defunkt / Chris Wanstrath
chrismatthieu / Chris Matthieu
littleidea / Andrew Clay Shafer
headius / Charles Nutter
bascule / Tony Arcieri
atmos / Corey Donohoe
ubermajestix / Tyler Montgomery
raganwald / Reg Braithwaite
of course I have to give a special shout to ourselves:
If we should be following you also send us an email at firstname.lastname@example.org, and we can hook up on Twitter as well.