Archive for February 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 Jud Valeski, who is currently the CTO at Gnip. Prior to Gnip, Jud started his professional career in technology at IBM as a software developer. In the past ten years he has spent about five of them coding (primarily C/C++), and about five of them in technical team management/director capacities. The bulk of his experience comes from Netscape Communications (acquired by AOL), with varying durations at IBM, Microsoft, and onebox.com (acquired by OpenWave).
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. Some of the notes also come from participants in the conversation and are not necessarily held by the discussion leader.
A question we ask each visitor, every month, What is a CTO? we do this because every CTO has a different answer.
“The title is pretty much irrelevant to me.” At a small company it doesn’t matter. It means something, it means a lot, at larger companies.
CEO is pure fantasy
Dev is pure reality
CTO is the bridge
Jud is a developer turned CTO, he explains this can be hard for some because a CTO brings some management responsibilities, which doesn’t always come naturally to all developers.
If you come from only management experience you can have a hard time with the CTO role because they don’t have the technical depth to make these decisions.
Important qualities of a CTO
* Technical Management
* Technical Direction (choose the tech to use, the approach, the design)
CTO role embodies the sense of leadership.
As CTO, you need a complete understanding of the business.
If the CTO is scattered that can be fatal. Be clear with prioritization and direction. If a person in the leadership position is confused it leads to a lack of confidence.
CTOs need to always be able to draw the system architecture. If you can’t, you are too detached.
To show those around you that you know what you are doing, you have to get down in the trenches and make some low level decisions with them. Backing up the decisions by explaining the technical merit of those choices.
Defining his role at Gnip
Push technical discussions along. Don’t let a topic be discussed too long when a decision needs to be made. Also, don’t cut off the discussion before exploring enough opportunities or you can make the wrong decisions.
At Gnip, defining the technical direction involved setting expectations that Gnip is an agile shop, uses pair programming, and uses lots of testing
One thing Jud measures the most is how well the team is going. If it isn’t going well, it is his fault.
A personal metric of Jud’s: if Gnip disbands tomorrow, every employee should be better and more knowledgeable than they were before they worked at Gnip.
* Only hire people that are smarter than you.
* If you think you are the smartest in the room, there is an ego problem and it is hurting the business.
* The downside to this is it takes a long time to hire.
* Gnip might hire 1 out of every 120 resumes it takes the time to seriously consider.
* It is important to sit down and write code with someone, plenty of people can talk a good talk
* Hire generalist because they can learn and do anything
* Don’t just hire for the tech need, the team personality and fit are just as important.
* Everyone on the team has to be great people, not just in the office, but out of the office.
The Gnip hiring process:
Resume Screen -> 30 minute call -> group tech conversation -> half/full day pair programming
Jud was once a part of a team that went from 15-50 in 4 months, which was too fast of growth and it was a mistake.
As a CTO do you have to manage your CEO?
“Yeah, all the time, absolutely.”
Like any job you need to be careful about what you escalate to the boss. The CEO doesn’t want to hear about every little thing.
What can a CTO do to foster engineering growth?
* Let employees buy as many books as they want on the companies dime.
* If you can afford it do the same for training
* Encourage participation in users groups
* Churn what people are working on
* Force developers out of their comfort zones.
What do you do about slipping schedules?
“Anyone suggesting software stays on schedule is in fantasy land”
If you pin motivation, success, or failure to a schedule you are doomed.
Wins have to come from someplace, if you set a schedule and meet it celebrate.
Reconciling schedules with business realities is probably one of the toughest CTO jobs.
If you have shrink wrapped software schedules has a whole different meaning.
Don’t inflate dates just to make the schedule, any dishonesty anywhere in the chain is bad.
You need to be able to release internally all the time. Internally always try to release early and release often.
When falling behind schedule, you have to evaluate the severity of each bug and feature. If there is a known workaround, that changes everything. If there is a workaround then it doesn’t have to block a release. If there isn’t a workaround, then you have to decide if it makes sense to have a release missing that feature.
Thanks a bunch to Jud for sharing his thoughts with our CTO group. I also want to thank Tom Chikoore from Filtrbox for organizing the meetings, and Jon Fox and David Cohen who originally started our CTO lunches.
Today we released the beta version of Devver.net to our initial set of users. This release is a major milestone: while our alpha release showed that the concept could work, it didn’t have the security or scalability for real-world use. This beta is a solid foundation for us to build on in the months ahead.
We’re happy to have this release out, but it was certainly a difficult experience – we spent over two months on this release, which is more than a month longer than we expected. We’ve learned a lot from this – most importantly, that it’s very difficult to predict the time to complete large releases. We felt it was necessary to make the big changes now, but going forward we’ll be moving to much shorter release cycles (every 1-2 weeks).
In the coming months, we’ll be looking for people to try out our beta. If you have a slow Ruby Test::Unit test suite that you’d like to speed up, contact us and we’ll put you on our list.