Posts from engineering

I've been reading The Corrections this long weekend. This book came out over ten years ago, but I'd never read it so I pulled it out of our bookshelf and cracked it open after we got off the mountain on Saturday. I hope to finish it on the plane ride home today.

The father figure in the book is Alfred. He's a railroad engineer who also dabbles in metalurgy experiments in his basement. He's a familiar character to me. My dad is an engineer and I have an engineer's brain as well. Apparently so does my friend Brad Feld.

The Gotham Gal tires of this mindset at times. She will say in exasperation "you can't solve every problem Fred." But that's how my mind works. Find problem, solve it, move one to the next one.

My engineer tendencies are reinforced by the work I do. Most entrepreneurs we back are also engineers. They find a problem and they set out to solve it. That journey is often a startup and we are along for the ride. Solving problems creates value in our business. Value creation is success. So the feedback loop is reinforcing and problem solving is the name of my game.

But the Gotham Gal is right. I can't solve every problem as much as I want to. The person or organization that has the problem has to want to solve it too. And when the will is not there, as clear as the solution is, its best to leave it alone.

I've been trying to decide what to do on the subject of online piracy. I think there are good solutions to the problem that involve technical approaches that leverage the work the technology industry has done with domain name registration and spam/virus/malware filtering. I laid them out in a discussion I participated in last week at the Paley Center. But the entertainment industry must want to solve the core problems, not just the symptoms. And it is not clear to me that the entertainment industry wants to solve the problem. So maybe I should move on.

The same is true of the companies we work with. They often have problems that can be solved, and have been solved in many other companies. But if they do not have the will to solve them, then all of our effort to address the issue is wasted. Our desire to solve the problem will simply come across as interference, meddling, or worse.

So as I move from youthful enthusiasm to elderly wisdom, one of my development goals is to supress the desire to solve every problem and focus on the ones where I can make a difference. I'm not there yet, but I'm working on it and making progress.

Last week on MBA Mondays I posted about the difference between CFO and VP Finance. In the comments to that post, I was asked about VP Eng vs CTO and I figured that had the makings of a good post too. So here we go.

Like VP Finance & CFO, the differences in the two positions are not just about seniority. In fact, in the case of CTO and VP Eng, seniority is often a non-factor. They are often peers. A VP Eng can report to a CTO. And a CTO can report to a VP Eng (although this last one is less frequent).

A VP Engineering is ideally a great manager and a great team builder. He or she will be an excellent recruiter, a great communicator, and a great issue resolver. The VP Eng's job is to make everyone in the engineering organization successful and he or she needs to fix the issues that are getting in the way of success.

A CTO is ideally the strongest technologist in the organization. He or she will be an architect, a thinker, a researcher, a tester and a tinkerer. The CTO is often the technical co-founder if there is one (and you know I think there must be one).

When a company has a strong CTO and a strong VP Engineering that trust, respect, and like each other, you have a winning formula. The CTO makes sure the technical approach is correct and the VP Engineering makes sure the team is correct. They are yin and yang.

Startup companies in their earliest stages will have neither position. The ideal web/mobile startup will have a CEO/founder who will also wear the VP Product hat. It will have a technical co-founder who will wear both the CTO and VP Eng hats. And it will have a few more engineers. And maybe a community manager.

But as the startup grows and the engineering team needs a layer of management, these two roles come into play. If the technical co-founder is a great manager/leader, they will naturally migrate into the VP Engineering role and eventually seek to hire a CTO or promote a CTO from within. But it is more common for the technical co-founder to migrate into the CTO position and seek to hire a VP Engineering to run the engineering team on a day to day basis. Either model works. It just depends on the skills and personality of the team that is in place.

It is very rare to find a person who can do both the VP Eng and CTO jobs at the same time. They require very different skills and very different time allocations. I've seen it work a few times, but it is the exception that proves the rule in my mind.

I told this story to an entrepreneur last weekend and she loved it. So I figured I should tell it to everyone here at AVC.

I was a mechanical engineering major (course 2) at MIT. One of the best classes in the mechanical engineering curriculum at MIT is 2.70, Introduction To Design. And the highlight of 2.70 is the contest in which everyone is given a bag of stuff from which they need to design and build a product that will compete in a contest.

My year, the contest went like this. There was a huge water tank with diving boards on both ends and a rope swing in the middle. Two contestants would put their designed product on each diving board, jump into the water, and start moving toward the rope swing. The one whose product got to the rope swing first would move on.

The "bag of stuff" was a brown paper shopping bag with an empty large soda bottle, the spring mechanism for a music box, a bunch of rubber bands, and so on and so forth.

I did what you might imagine, with the help of my friend Jim. We cut the soda bottle in half to create a boat, used the spring mechanism to power a paddle boat style propulsion system, and used the rubber bands to launch the boat from the diving board. It worked and I made it past the first race.

In the second race, I came up against a student who had a different idea. His product simply launched, like a rocket, from the diving board, flew through the air, and grabbed the rope swing in about a nanosecond. He destroyed me and everyone else and won the contest.

The lesson is, of course, is to skip the water.