The Devver Blog

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.

Hiring
* 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.

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.

Corporate Culture
"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.

Problem Employees
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.

Employee Training
"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."

Evaluations
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.

Although I'm not actually the CTO of Devver, I had the pleasure of attending the Boulder CTO lunch this past Monday since Dan was out of town.

This week, the group had Todd Vernon from Lijit come lead the discussion. Although Todd is currently CEO of Lijit, he was CTO at his former company, Raindance.

The group that was assembled was small but awesome - I had the opportunity to learn not only from Todd, but also from the CTOs of a few of last years TechStars companies.

The discussion touched on a ton of topics, but two (related) themes that were heavily discussed were the role of the CTO and how a company grows from a technology perspective. I've organized my notes below. Keep in mind that these are the collected thoughts from a number of different participants and I may not have captured their ideas with 100% accuracy.

The Role of a CTO

What is the difference between a CTO and a VP of Engineering?

CTO is about leadership for technical issues, interfacing with the business side, guiding the product, get people excited about product from a technical point of view.

VPoE is almost one step above Chief Architect, more on a management side, getting product delivered.

1st time CTOs need to figure out their exact role. It's a very amorphous role, depending on the company.

CTO needs to be able to tell the whole business story, understand the good parts and bad.

Early on, CTO should insert themselves into the sales process as much as possible (especially right after you hire the sales person). You need to be able to hear what customers say they want, so you can translate that into what they really need.

The Technology Onion

There is a technology onion - make sure the core of the onion is owned by company (the outer layers, not as important). The CTO needs to figure out the relationship between the technologies and the company's partnerships. The closer a technology is to the core of the onion, the more important it is to own it and to make sure it scales.

For instance, if you're depending on Google for search, you're powerless to change features if things don't work as your customers want/expect. If search is core to your business (near the core of the onion), consider building it internally. It's the CTOs role to make that case, because business people will never understand the need to spend money to get "the same thing."

Having to re-architect a core component of a company can really hurt growth. Assume you're going to be successful, so plan for that.

Along the same lines, one concern about using EC2 is that you get tied to the platform and your business is dependent on an outside force you can't control. Hosting on EC2 can be quite different than hosting your own boxes.

Acceptable Failures

What is acceptable downtime? It depends on when - between midnight to 1-2 AM, it might be OK to be down for a few minutes. CTOs need to determine what acceptable downtime is and tell that the to the rest of management and have people agree.

CTOs need to make decisions (for instance, what is the acceptable down time, acceptable data loss, or acceptable time for page load) and then tell the entire organization. That way, when something bad happens, you can explain that everyone agreed on the specific numbers. It's unlikely your business will need to be (or can be) 100% perfect on all metrics, but people need to understand what the goal is and why it's realistic.

Growing/Scaling/Monitoring

If at least one person is using your service, you should have two web servers. It gives you ton of flexibility. Having two boxes forces you to work out most of the issues early (it's a lot different getting to 2 boxes than 3 or 4). It's not about load, it's about reliability.

No matter how useful you are, if you are not reliable, someone will blog, "it's cool, but it doesn't work reliably."

Downtime spreads very fast across Twitter. Consider tweeting about upcoming service interruptions ahead of time so customers are aware.

After more than 15 people, you need a dedicated operations person. Get some basic monitoring services early - after a server is under load, it's really hard to diagnose. Try to detect stuff early, it's easier to debug.

With startups, generally the problem tends to be slow requests rather than complete service downtime. Make sure your monitoring service will alert you with slow requests.

Get app specific stuff - a warning like "High CPU load," is harder to understand (it might be a problem, or maybe the machine is just handling a lot of requests successfully), but "Page X takes 80 sec to load" is more obvious.

As you grow, try to measure more and more. Things often degrade slowly, and one day you just notice its too slow and it's hard to go back and find the root of the problem.

Make two lists: a) the most catastrophic things that could happen and b) the most likely things that could happen. Where those lists overlap, you need to fix something. But there will be some risks that you decide are reasonable risks for the business (revisit these risks regularly as things change).

Regarding backup - always make sure you try to restore some data (before you really need it). You need to make sure it works and make sure its fast enough.

You should always be able to describe at a high level how the service will scale infinitely (it doesn't have to be technically perfect, but it has to be believable). When someone wants to purchase, that'll be a huge help - the business guy on the other side of the table will want to buy, but the technical guy doesn't want to buy (he wants to build it in-house).

---

I hope those notes make some sense and give you a good feel for the discussion we had. I'm looking forward to attending more of these lunches (I hope they'll continue to let a few CEOs sneak in...)

Behold my favorite picture of this awesome TechStars summer

Considering you can clearly see the Devver logo on Dan's shirt, I think this needs to be in all our future marketing material. Nothing says "developers love Devver" like a developer doing a backflip in excitement. Awesome stuff.

TechStars has been an amazing group to be a part of. We have frequently been asked about the program and "what is the best part of the TechStars program?" It is really hard to break it down to any single point, but all the benefits come back to being all about the people.

We have received a ton of help from everyone in the program. We want to thank all of the mentors and sponsors involved with the program. TechStars really brings an amazing group of people together. We of course want to thank the original founders of TechStars - you have helped to build a really unique and engaged tech community in Boulder.

We want to give mad props to all of the other TechStars 08 teams. Some of the best advice we got came from the other teams. So thanks goes out to Occipital, Gyminee, App-X, TravelFli, Ignighter, People's Software Company, Foodzie, BuyPlayWin, and of course The Highway Girl.

We also got some great advice and feedback from some of last year's teams. Thank you to Ari from Filtrbox, Rob and Josh from EventVue, and the entire team with Socialthing!.

Last, but not least, we wanted to give a final thanks to some of the mentors that we spent additional time with. We really appreciate the advice, feedback, and laughs... thanks to David Cohen, Tom Higley, and Seth Levine.

Congrats to everyone for making TechStars such an amazing ride. We know that even though the program is over we will still be getting advice from many of you and still be working with the kind of determination that TechStars helps foster.

Update: Changed Project to Product, I didn't realize the differences. Niel pointed out that they aren't the same in another thread.

Niel sent the actually Power Point which you can check out for yourself, product-management-v1.

We have met with Niel Robertson before, but this was the first time we got to see him present a topic. He gave a talk at TechStars informing groups why Product Management (PM) for startups is important. In fact, he went as far as saying the number one thing that goes wrong at startups might be PM. Niel described PM as a process for delivering the right features at the right time. He went on to discuss why PM can become stale, be ignored, and is often hated because it is associated with excessive documentation, which it shouldn't be. Mentioning more than once that the best feature requests, requirements, and specs are often just one sentence.

Niel presented PM as a general evolving process, and specifically avoided specific PM systems or methodologies. Niel said he is totally document agnostic and all systems have positives and negatives in terms of PM. It came across that it wasn't important what system was used, but that everyone at every stage of the project must write things down. He described that ideally every test case should be tied all the way back through spec, requirement, and finally feature. One thing that Niel specifically did say was worth doing was completing a feature review before QA. Have an engineer walk through the project and show each of the requirements being fulfilled, have the product manager and QA lead attend this feature review.

His basic points about why every product can benefit from PM are:

• It takes 30 secs to write a requirement
• 2 minutes to clarify in discussion
• 5 min to for an engineer to spec
• Hours or days to prototype, write code, integrate, or deploy it

Because of these points he doesn't want to hear a team is small and agile so following a PM process would slow them down. In the long run following a process will be faster. That point really hit home with a concrete example he gave, "If a project is UI intensive absolutely do not start coding, go to a white board." This resonated with me, because we made a huge mistake with my last startup, by getting into the prototype without spending enough time thinking about UI. He said, "Don't tell me that product management is something you do at a bigger company that has more complexity."

As my notes are often just a list of key points that caught my attention, I will do as I often do and share some favorites.

• How to write a good requirement... "The user should be able to..."
• How to respond with a good spec... "The user can do that by... doing X... List the exceptions"
• A spec is well written when QA can figure out how to test a feature based on the spec.
• Doesn't encourage people to shotgun tons of things to market. "When I make spaghetti, I try not to throw all of it against the wall."
• On gathering data, go out and talk to people getting more data points about the problem you are solving until you start hearing the same things and can't learn more from talking. Then go work on it, knowing all this data.
• Niel doesn't recommend a developer also taking on the role of PM, as there needs to be a tension between who represents the user and who implements the product.
• "The PM should be the most empowered employee in your company... Yes, even more than the CEO"

There were a ton of other good thoughts on what exactly a PM does, and how to select a good PM, but as always I can't really do a presentation justice. Thanks Niel for the great talk.

Update: great discussion going on at Hacker News
Niel sent his Power Point slides after a few people asked for them, product-management-v1.

Filtrbox launched publicly a couple days ago and I just wanted to say congrats. Filtrbox is a TechStars 07 company, that I really didn't hear or see much of last year. When I first heard what they were doing, I thought, "Yeah I already have Google alerts thanks." Now Filtrbox has become my favorite of all the TechStars 07 companies. I have canceled all of my Google alerts, Filterbox is simply better, no question. That is what is so surprising, Google has all the info it should need (search, indexing, news search, blog search) but it just doesn't filter the information as well. In fact my Google alerts sends me so many duplicates that the noise had caused me to ignore them most of the time. Each morning as part of my routine I now wake up and quickly look for my Filtrbox daily email report. It lets me easily see what is being talked about with my company, my industry, my partners. In fact I find new uses for Filtrbox often. When I was told I should keep my eyes out for news about a particular announcement coming in the next few weeks, the first thing I did was set up a new filter. I didn't have to worry about missing the big news or the opportunity to become part of the discussion about that news. I just simply outsourced worrying about it and monitoring the news, and Filtrbox caught it and brought it to my attention. I recently started inviting some of my friends to try out the service, which I thought they would find interesting, but now that it has gone public I invite all of you to try Filtrbox out.

Andrew Hyde recently interviewed Dan and I for the TechStars Community site. You can listen to the podcast here (and see a picture of Dan and I staring dramatically at a piece of paper).

This is the final day of my TechStars Days series of posts.

Yahoo Day

Greg Cohn (Yahoo Open Strategy)

Greg talked a little about Yahoo's current focus, Making Yahoo relevant to how users manage their digital life. Yahoo is working on becoming dominant in the advertising market by leveraging its 500 million plus users. Lastly it is focusing on opening Yahoo up to allow others to build on and with Yahoo. Greg spent most of his time talking about Yahoo's Open Strategy, which is one framework for developing applications with Yahoo. The open strategy will include single user accounts, profiles, user records, and authentication APIs. This would all be supported by a single standard for consuming web services and supported by code from YDN (Yahoo Developer Network). We got a peek at the Yahoo Social API which is built on top of Open Social, supporting all of the Open Social standard, but also additional APIs. It was interesting to see how Yahoo really wants to transform its image to show that it is a social network and has always had the social abilities, it just never presented them.

Eric Marcoullier (MyBlogLog)

I saw Eric speak at TechStars for a Day, and it was funny to hear his story a second time. Eric just showed up and winged it, he has no prepared talk, slides, or real agenda. He goes off on tangents to talk about whatever he feels like discussing. He likes to apologize for his lack of style and ramblings, but it always turns out to make for one of the most interesting and blunt talks. I will just list out some of the key points from the discussion the TS teams had with him. MyBlogLog was a part of Yahoo Day because Yahoo eventually acquired the company.

• MyBlogLog did one thing originally, track outgoing links, but did it well
• Keep a narrow focus, the first version only had 3 different pages for the app
• Engage the community. Eric emailed the top 150 (or so) bloggers. Sending each blogger a personal email about what MyBlogLog did and why they should care (He received a 10-15% response rate)
• MyBlogLog being stats had no viral component, it needed something users could see, this idea slowly led to the widget.
• 6-7% would pay for a pro version, which was the same except it gave real time stats
• Don't always add more features sometimes find the market that wants the features you already have.
• Launch quickly and get feedback, show people something even if it is half baked and rough
• To engage mentors, try to be responsive to any of their first even small comments, because if you react to them and show them changes they are more likely to discuss and become involved with your idea
• After selling a first company successfully, you have a platform / reputation to help build another company

Wrap-Up

I would like to thank everyone that came and talked with us at TechStars, trust me, it was a great learning experience. I am sure I will be reading through my notes time to time in hopes of keeping myself on track. I know my attempt at writing about the experience doesn’t really do it justice, but I figured I should try to share some of the experience gained.

This is part three of my TechStars Days series of posts.

Microsoft Day

Dave Drach (Emerging Business Team)

Dave is heavily involved in the Boulder / Denver Startup scene, working with Lijit, NewsGator, Search-To-Phone, Filtrbox and others. Dave basically told us MS loves developers and does everything they can to nurture developers working on their platform. I didn't know that from the MS startup zone, you can basically get anything from MS free to start your company. Free Hosting (2 machines for 3 years), 5 free MSDN licenses, free developer support, and consideration for their Startup Accelerator Program. Dave ran us through many of the various offerings where MS could help you out if you are developing on or for their stack.

Don Dodge (Emerging Business Team)

Don has an amazing history, perhaps most famous as the VP of Napster. This position led to this message to our teams, paraphrased, "You can and have the power to change the world." He is right that the simple music sharing app changed the digital landscape forever, and other startups will lead the way with other revolutions. Don told us that MS liked to acquire young startups when innovation is happening. He would rather get 50 small innovative companies than a billion-and-a-half dollar YouTube like deal. He did admit to us that most of what MS acquires is on the MS stack. Since we are working in the Ruby world, I guess that means we aren't a target (maybe IronRuby? Interested?). Don is really plugged into the whole start up community and is very vocal about it on his blog, which I highly recommend checking out.

Anand Iyer "AI" (Microsoft Evangelist)

AI shared various demos and code with us, showing off some of the newest stuff in the MS stack. He spent a good amount of time showing off Silverlight, which can do some cool things. Silverlight is particularly interesting because we saw offerings all in related spaces from MS, Google, and Yahoo. Every company wants to be the plug-in that lets you develop richer applications in the browser. I think anyone that has seen some of the deep zoom / Photosyth stuff has to admit it is pretty impressive. We also got to see some demos of IronPython which is cool because I am interested in having powerful dynamic languages (IronRuby) play nicely in a VM.

Greg Reinacker (NewsGator)

Greg had a small consulting company and had an idea for a RSS reader that didn't suck. He thought it would be great to be able to read his feeds in Outlook. He mocked up some screenshots of reading feeds in Outlook and got 50 comments, "please build this." So he built it and sold 25 copies the day he released it. This project started outgrowing his consulting company, which he shut that down and raised some money to grow NewsGator. One of the problems promoting NewsGator was no one really knew what RSS feeds were at the time, so NewsGator had to become a really big advocate for RSS adoption, and explain RSS as part of their pitch. This is something we think about with Devver, because we feel like we will have to partially push agile programming and better programming practices to promote our tools. The stories shared by all the rising and finally acquired companies helps TS early teams try to really evaluate if we are focusing on the right things. NewsGator started as a single founder company and eventually was acquired by Microsoft.