Archive for the ‘Boulder’ Category
We announced about two weeks ago that Devver and Caliper would be shutting down. The Caliper service will be shut down on April 30th, and Devver will be ceasing operations. We shared some of our thoughts about lessons learned while working on Devver.
Now people have been asking what Ben and I will be doing next. Honestly, at the moment it remains a mystery as much to us as to anyone. Both Ben and I have been working on startups together for over 3 years, something we had talked about doing together since high school. After our experience we both plan to take a bit of time off, to work on open source, personal projects, learn new things, and maybe catch up on some hobbies that have been neglected. Since Devver and the structure around it will be disappearing, we wanted to share our personal contact info in case anyone wants to get in touch with us. We will be looking at new work to get involved with sometime in May. Feel free to contact either of us if there is an opportunity one of us might be interested in.
We have learned an amazing amount over the last couple of years. We both feel like this has been an amazing opportunity and one last time want to thank everyone for their support. Thanks to the Ruby community, all the awesome Techstars teams, the startup community, our friends, families, and investors. We never would have made it this far and lasted this long in the startup world without all of you.
Next? Life is a journey, and we are excited to see whatever the future brings us. Thanks for all the good times, knowledge learned, and all the amazing people we met along the way.
Dan usually goes to the Boulder CTO lunches, but he was out of town this month, which meant I had the pleasure of hanging out with some of Boulder’s best and brightest.
This month’s guest was Matt McAdams of TrackVia. TrackVia is an online database that is powerful yet simple enough to be used by people who are used to keeping data in spreadsheets (primarily business people). Matt gave a candid and often hilarious talk that touched on both both technical topics, and, luckily for me, a discussion of pricing and metrics, which are two topics that I’m currently very interested in.
On technology decisions:
Matt wasn’t a database guy originally, but used his practical knowledge he gained working on a previous startup
Went with the simplest design that could work and it’s continued to scale well
Smart technology decisions have allowed TrackVia to compete with a small, lean development team
On product development:
TrackVia started as a contract project for a single customer, but they saw the broader appeal
One of the earliest databases in TrackVia is the bug database (still around). In other words, they’ve been dogfooding since day one.
They don’t worry about the competition. Instead, they focus on building the features that get people to sign up and pay.
You’ve got try stuff and iterate. TrackVia has changed their pricing several times.
Customers on the old pricing models have always been grandfathered in.
Sometimes raising your price can actually gain customers because some people assume that a cheap product or service must be low-quality (even if it’s actually very high quality).
If big customers really want feature X, it’s OK to ask them to pay extra to accelerate the development of that feature (or to customize their experience).
Good metrics allow you to try different strategies and measure their effect.
You must measure, tweak, and iterate.
If you can iterate on a weekly basis and your competition can iterate on a quarterly basis, you’ll win.
Metrics must continually be improved. TrackVia spends a lot of time tracking useful metrics, but even they know they need to add additional metrics in some key areas.
As usual, the CTO lunch was a great place to hear from other Boulder companies and I learned a lot. Thanks for everyone who attended and special thanks to Matt for leading our discussion.
We’re very happy to announce that we’ve had a great developer accept our offer to join our team. We’ll have more details on our newest team member soon.
This was our first attempt at hiring and we certainly learned a lot. While our process has improved since we started, it’s still a work in progress.
The first lesson we learned is that hiring can take a long, long time – in fact, much longer than we expected. I looked back through my emails and we officially started looking for someone more than four months ago. One thing we have heard time and time again was the importance of hiring only the best people – and, just as importantly, people that fit well within your company culture.
As a result, we were extremely picky when it came to candidates. As the process goes on and on, it’s easy to get frustrated and want to lower your bar. Avoid this temptation! If at all possible, go the other route: raise your compensation, improve your pitch, and raise your profile so you can attract candidates that meet or exceed your bar.
When we started, we severely underestimated how long it would take and we overestimated how many applications we’d get. Because of these bad assumptions, we made our first mistake – we chose to slowly “roll out” the announcement that we were hiring. First, we just told friends and mentors. A week or so later, we tweeted and put up a blog post. Later on, we posted on some news sites and newsgroups. And after that, we finally created a job posting at Startuply. Waiting between each step was a waste of time – we should have just broadcast as loudly as we could the first day.
We ended up getting a good number of applications, the vast majority of which were from great programmers. We assumed that going through them would waste a bunch of time. We were wrong. In reality, it was really easy to turn down many applications just from their resume (usually the applicant was good, but didn’t have the skill set we were looking for). Phone calls were a bit more time-consuming, but were never a waste of time. We always enjoyed talking to candidates, always found a way to improve our process, and usually learned something new about the Ruby ecosystem.
One thing that we improved on was learning to say “no” quickly. Even with the manageable number of candidates we talked to, it was important say “no” as soon as we discovered something that wouldn’t fit. Early on, we were a bit hesitant to do so and ended up continuing our process for too long. That wasn’t fair to either ourselves or the candidates. It became easier to shut things down quickly once we had interviewed a few people and started to gain confidence that new applications would show up, even if the queue was currently empty.
We also learned that it’s important to have a fairly short process. Of course, the biggest priority is to have a process that lets you learn enough about a candidate to be confident in your decision. That said, as you improve, you’ll find that you can shorten your process while maintaining your confidence. Shortening the process is better for you (less time spent) and better for your candidates.
The initial version of our process went something like this:
- Check resume, blog, Github account
- Introductory phone call to learn about candidate and convince them Devver is cool
- Second phone call to ask some high-level technical questions
- Ask for and call references
- Remotely pair on a project for a few hours with the candidate
- Fly candidate out to Boulder to meet and discuss technical and business issues
The final version was a bit more compressed:
- Check resume, blog, Github account
- Phone call to learn about them, introduce ourselves, and cover high-level technical questions
- Ask for and call references
- (In parallel with #3) Ask candidate to write small Ruby application and review their code
- Fly candidate out to do some pair programming and discuss technical and business issues
All in all, it was a good (if sometimes painful) learning experience. We deeply appreciate the time and effort spent by every single applicant (and their patience with us as we learned by trial and error).
If you’ve got your own lessons you’ve learned while hiring, please let us know. We know we’ve still got a lot to learn…
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.
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.
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 Tim Wolters from Collective Intellect come lead the discussion. Tim is a serial entrepreneur currently working on using artificial intelligence and semantic analysis to extract knowledge from unstructured text found in social media. Collective Intellect’s customers use this analysis to inform and measure the effectiveness of their PR and marketing strategy.
Tim is considering working on a book, a startup survival guide for CTOs. Some of his ideas for the book helped lead our discussion during our meeting. I will try to present my notes under topic headings that Tim mentioned, 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.
People should keep a journal of ideas. Tim keeps a journal which he updates, tags, and adds ideas. On any idea, keep track of what is near term, what resources are needed, what is the cost, and what does the related market look like. (I highly recommend this! Ben and I keep a wiki, which has grown to be an incredibly useful resource and was the initial starting point for our last two companies)
Ideas should have an “Aha!” factor that makes you wonder why someone else isn’t already doing it (or some emotional appeal that makes lives better).
During the first few years of a startup you can’t work on all the ideas that come to mind, that is why it is best to keep a journal, just add little notes to the idea to keep them in the back burner.
Talk to others about ideas and perhaps have a group move on an idea and lay the groundwork while leading as an adviser.
Don’t be worried about people taking ideas. After starting a few companies you know how hard it is to really bring something to market.
What about brainstorming for ideas with a group?
Brainstorming groups have never worked for Tim, it just hasn’t worked out. If you have the right people around the table (people that can make things happen), it could work, but Tim hasn’t seen it.
Ideas depend a lot on timing in the marketplace. If the market is moving slow you can slowly look at an idea. If the market it really moving fast you need to spin it up quick and get a lot of people working on it to really make a move on the idea.
Look over your ideas once in awhile and see what still really interest you.
As a CTO, you paint a landscape of the product and market.
There are two kinds of CTOs: tactical and visionary. Tactical CTOs are internally focused, manages the team, makes the day-to-day tactics so the product gets out there. The visionary CTO sees where the product could go in the market place, signs early deals and customers, looks for features that lead towards or away from markets/competitors/partnerships. The visionary isn’t working on architecture but the market landscape, what partners will benefit the product or get it out sooner.
CTO should be thinking about things such as the three hardest problems that the company faces, so they know what will also be affecting their competitors.
People who liked architectural purity but learned it isn’t as import at winning at the business end up making great CTOs.
CTOs need to stay involved with customers to make decisions about the project innovation and development. Stay active on sales calls, talk with sales people, read all the RFPs.
Becoming the CTO vs VP of engineering?
Are you good at managing or not? VP of engineering is a managing role. If not, divide off the management as soon as possible (in his case that wasn’t possible until the company was about 20 people).
Good sales people leverage a CTO as a company evangelist. If you are a CTO you have to be comfortable with presenting and publicity. You will be at conferences, sales calls, giving presentations, and fund raising. If you aren’t comfortable with these things, get comfortable with it.
- 10% guiding research
- 30% Sales
- 30% Partnerships
- 30% Biz Dev Dealings
After some startups, successes, and expanding your network things like getting a team, funding, and getting a startup off the ground are much easier the next time.
It will take 3 to 5 times longer than you think to get a project going if you are an unknown entrepreneur with no reputation.
Don’t solve the big unsolvable problems first, the first time start with smaller problems and develop a reputation while solving them. Angels and VCs aren’t funding research efforts, don’t just chase after big impossible goals.
After a company is bought, it makes sense to make the purchaser successful. It builds on your reputation.
Become a big fish in a small pond and then move to a bigger pond.
Putting together the team
The ideal size for an engineering team is 6-8 people, bigger teams have difficulties maintaining the right amount of communication.
For hiring, Tim personally sits down with the key hires, and if it is research he does interviews with applicants as well.
The Traps and Pitfalls of Startup Companies
3 things that companies get stuck on that can kill the company.
- Problem with getting over enamored with their original idea, startups must be able to adapt
- Getting enamored with the research technology, for technology’s sake
- Getting emotionally tied to architecturally purity. Working on layers of abstraction on abstraction to avoid some possible future problem.
Other things that kill companies (which are kind of like a marriage)
- Not the right chemistry
- Bad culture or losing company culture
- Employees need some sense of allegiance. If they don’t have it cut them immediately
- Lacks a culture of adaptability
- Not thinking about how to quickly get to the market and solve problems
Continual code death march. Sometimes companies go on code marches to get something to the marketplace. This can’t be done many nights or it will start taking a toll on other aspects of your life. Strive for balance.
During a startup, you continually are hitting false summits, you think that if you could just get that contact, solve that roadblock, pass this milestone, or make this key hire then everything will fall into place. While these are important as milestones and you should celebrate them you are not done. Or rather, it typically doesn’t get any easier. What it does is takes more risk out allowing you to go solve bigger/other problems.
When founders or others in a company argue, which they need to do sometimes, don’t do it in front of everyone. Discuss disputes offline, reach agreement and present a unified front to the company.
Thanks so much to Tim for sharing some of his thoughts with our group. I will leave you with a final question and quote. Someone once asked why Tim likes to start companies?
“I like to pick where I work and who I work with.”