Cogblog

The Official Blog of Cogmap, the Org Chart Wiki

 

Archive for the ‘Building A Start-up’ Category

 

New Economies and New Consultancies

Tuesday, February 7th, 2012

Lots of people have talked about how the economics of start-ups have changed. As costs have come down thanks to tools like MySQL, Amazon AWS, and free frameworks like Rails, where it used to require millions of dollars to build an early stage product, now a product can be built for virtually nothing.

The bottleneck now appears to be access to engineering talent.

There are no hardware constraints. The only thing that stands between an entrepreneur’s idea and the realization of that idea is convincing technical talent to devote their time to it.

One could write a whole host of blog posts around this, but I want to talk about a few interesting side effects I have seen.

There are more tiny consulting companies than ever. I am talking about free agents (1 person) and small shops (2-10 people). I have noticed that many of these are managed poorly. I would say a common thread in many of these is that the people that start them either never worked at a large consulting shop or they were a person that hated all the process and machinations at their prior employer, did not value them, and quit to go their own way. These companies are easy to start – you can simply hang around on oDesk or something worst case and build relationships from there – because demand for technical talent is so high.

But an interesting side effect of this is that as the technical talent gets distributed to these tiny companies, the process and project overhead diminishes significantly. That sounds great to engineers, but do not doubt that there is some value in process – particularly as regards to the creation of visibility in the process (which usually is completely unvalued by the people doing the work). The result is that the burden is placed on the client to “manage” the project and make sure that they are getting bang for their buck. I have also seen a sharp transition away from the trend toward fixed pricing of projects and de-risking the project for the customer to a time and materials model and “scrum-ey” project methodologies. This is great for the developer and CAN BE great for the customer, but only if the customer has the infrastructure needed to manage the project well.

So as technology frameworks have simplified the development of technology, the trend in consultancies has been toward smaller and smaller organizations, but increasingly these consultants are providing only technology development, not the infrastructure that many have come to expect that results in complete delivery of the final project. Customers own project management, QA and other typically core engineering functions – the consultant is just manpower.

 

The Implications of Architecture in Start-ups

Tuesday, January 17th, 2012

One of the interesting artifacts of developing technology in a start-up is that the “what” isn’t the only important thing. “How” is pretty important as well.

When you are building a start-up, you are trying to create value around the asset. Obviously, job one is to be all “MVP” and “build something customers want”. After that – after you have done the impossible job of building a business – something that looks a tiny bit like “traditional” product management starts to appear. Your product has to evolve and certain decisions about what to build next need to be made.

Today, much of this is solved via “user stories“. User stories capture what users will do with the system and how that creates value. The goal is to separate what needs to be built from how to build it. While this is a noble goal, it can actually interfere with the building of the value of the asset: In certain situations, the goal is not just to solve the users problem, but “lead the industry” or “map to a potential acquirer’s reference technology architecture”. In these situations, the “How” it is built becomes just as important as the problem being solved.

The only cure for this problem is tight linkage between business and technology. Just as a user story is an invitation to have a conversation around a user problem, that invitation must encompass the larger “how”. Of course, that presupposes that the business has some inkling of how technology approaches build business value.

Recruiting Engineers at User Groups

Wednesday, November 2nd, 2011

I was at lunch the other day with a very skilled engineer and I was bemoaning the difficulty in finding skilled engineers to get involved in start-ups. My buddy responded that he would just go to tons of coding oriented meet-ups if he was doing a start-up and wanted to meet skilled, motivated junior engineers.

He had two great reasons why meetups are a great place to recruit for start-ups:

  • People that attend meetups for coding clearly think of coding as an avocation, and not simply a vocation.
  • People that attend meetups are probably single.
He made some great points. I don’t go to these meetups for the same reason that doing a start-up is hard: Family commitments. Finding engineers unencumbered by these is good for your start-up!

Let Me Advise Your Start-up!

Wednesday, October 26th, 2011

I love Founders Institute’s new Founder Advisor Standard Template. I am on the advisory board for several companies – most of them very early stage – and one of the things I have always done is have a “conversation” about my compensation, without putting anything in writing. Given my desire to be an asset to the company, one of the things I have always done is say, “let’s defer getting this all legaled up”. I don’t want my start-ups wasting money on lawyers pre-fundraising (or even post, frankly) – and I have always felt that I am both a little bit willing to risk getting screwed and a little bit willing to demonstrate my value and worth. Once I demonstrate how hard I work for my companies, I have yet to be screwed, so in that respect my approach has tended to work out well for me. But I have always thought, “It would be nice to formalize this”.

Founders Institute’s attempt to create a “seed series” standard document for setting up advisory boards is a brilliant idea and very valuable to early stage start-ups. I also am a fan of the approach that they have taken to recognizing that various advisory organizations will have varying levels of commitment.

It is getting easier and less expensive than ever to build a high-performing start-up.

Organizational Credibility and The Need To Tell Lies On The Job

Wednesday, October 19th, 2011

Being in sales is incredibly difficult. If you are not in sales and you wonder why some sales people make crazy money, the answer is that sales is hard. Most of sales involves experiencing a steady stream of belittling and rejection and your average person simply cannot cope with that. I, for one, am on the record as being a terrible cold caller. Calling 99 people and hearing how dumb I am so that I can get to that 100th person who will hear my story is very tough.

The result is that if a sales person has a good relationship, that is like a gold vein to them. You treasure it! Someone that you can call on again and again and they will buy from you repeatedly is incredibly valuable.

The result is that, at some level, a sales person will treat a new job with suspicion. They simply cannot afford to burn their valuable relationships if it turns out their new employers products suck. Many sales people would rather fail at a new job and keep their confidence and relationships intact than risk blowing up a customer.

The result is that for a company to get a salesperson going, they must instill 100% confidence in their products in a salesperson. Particularly for early stage businesses that are just building their sales organization, this can be very difficult.

Instilling that confidence is not second nature to most people. In fact, I would say that the average person wants to:

  1. understate and overdeliver
  2. be honest about capabilities

These two things can be deadly in early interactions with a sales organization.

Selling a tiny bit ahead of capabilities is critical for the success of most organizations.

Quick sidebar: I was working at a publicly-traded company at one point in my life and I was listening to the earnings call and I heard the CEO describing some capabilities we were developing. I turned to my boss and said, “Oh my god, that was a complete lie the CEO just told.” To which my boss responded: “About time he started competing with everyone else.” My bosses point was excellent: Everyone else in our industry packed their calls with lies. We knew this. Turnabout was fair play in this situation.

Similarly, I was confronted with an interesting challenge recently: We are building a large sales force basically from scratch. We had a product that is coming out in 30 days and during a sales presentation, I presented it as such: “Regarding X, This product will be available in a 4-6 weeks, I will give you plenty of details then.”

I do this for two reasons:

  1. I am a believer in building my organizational credibility through meeting my commitments. If I say, “X will be done by Z”, it will be done. If I lack confidence, I refuse to give dates because I want people to know that when I give a date, they can bet their bottom dollar that it is going to happen.
  2. I like sales to sell what we have. One of the things that drives me nuts about sales people is that when you tell them what is coming, they tend to tell their customers – which can cause a customer to hold off on placing an order – which can cause a salesperson to say that the reason they can’t sell is because “X product isn’t done”. So I always tell people, “Tell the salespeople that the product will never get any better. If they want to work here, they have to figure out how to sell what we make.” Of course we want our product to get better, but a good salesperson should figure out how to sell what we have. To be all Glengarry Glen Ross about it, if you can’t figure out how to sell our crappy product to these good leads, I don’t want to give you the good product to sell. Make it rain!

Regardless, my boss came over to me afterwards all fired up: “You need to go back to the sales force and re-characterize our capabilities in this area as being available today.” My response was, “But it isn’t!”. To which he replied, “That is not germaine to this conversation!”

Great line.

Moral of the story, if we waited 6 weeks to start selling a capability we will have in 30 days, we won’t see a deal for the next 90 days. And it is Q4! Now we have the capability and our team is actively closing business around it. Win/win.

While many product people, and many people in general, take the same approach I typically try do – organizational credibility development through constant under-promising and consistent over-delivering – it is critical to success in life and in business that you recognize moments where this philosophy serves you poorly and a little over-promising and then going out and making it happen is actually what it takes.

Furthermore, it is important to recognize that sometimes your organizational credibility isn’t what is important. If the business needs you to take a body blow – hey buddy, that is why you get paid the big bucks.

One more story: In my first company, I remember closing our first six-figure deal. Prior to that deal, our biggest job had been around $70k and this job was for $250k. My partner said to me when they offered us the business, “We might not be able to do this!” My response was, “If we can’t do this, we will never have the kind of company we are trying to build.” We took the job, we made it happen, we built a company I was proud of and led it to a great exit.

It is easy to always under-promise. Easy. Just push back whenever people push on you to over-commit. It can be a habit. But don’t think that just because you are always making your commitments and managing expectations that you are doing the right thing. What is hard is recognizing moments when you need to demand more of yourself and your team to catalyze change.

Programming Cults in the Baltimore/DC Area

Friday, May 13th, 2011

If you are a non-technical founder of a company similar to the kinds of companies that I might start, your job is to be a talent magnet. You have to convince awesome people to quit their jobs and join your start-up. If you can’t do that, then you probably aren’t doing your job. Your job as a non-technical founder in a very early stage software start-up is three things:

  1. Get critical talent to join the team
  2. Sign up a few customers
  3. Raise money

If you can’t do #1, #2 is hard – customers like products.

If you can’t do #1, #3 is hard. As I told a group of entrepreneurs at a recent Founders Institute event: “If you go to a sophisticated investor and ask him to put money in, but none of your friends have joined your company, that is a huge red flag: If you can’t convince your friends to quit their jobs and join your company, why would a complete stranger trust you with their money.”

One thing I think about a lot when I think about what my next company might look like is Steve Newcomb’s “Cult Creation” essay. One section in particular is very compelling to me, so I am going to quote it in its entirety to give context to the rest of my blog post:

Create a Dominant Market Share – one of the things that I took notice of was Google’s move to develop a lot of their tools in Python.


Curious, I thought.  Why would they do that?  At the time Python was a new(ish) language, although growing quickly in popularity.  Then it hit me.  They were going for a dominant market share in a specific talent pool. If you can get in on a new talent pool trend, the benefits can come back ten-fold.

Here’s the strategy.  Get the first luminaries in the field, then as that language grows in popularity you are labeled as the de facto place to go if you want to code in that language.  Then hiring get 10 times easier.

Brilliant.

In 2005, when we founded Powerset, we realized Ruby was the new Python, so we went after some A-level people in the Ruby community.  The top two we went after were first, Kevin Clark (a 20 year-old wiz-kid who we were trying to convince to quit school) and second Tom Preston Werner (now the founder of GitHub).

We got both of them, and within a matter of months, we had one of the largest Ruby teams on the planet.

Anyone who wanted to code in Ruby knew about Powerset simply from the Ruby meetups which were dominated by either Powerset or Twitter people.

We then did the same thing in the field of computational linguistics.  At one point we estimated that of the 200 or so people that really understood computational linguistics in the world, we had about 40 of them.

What’s the benefit?  Once we knew we had this level of talent market share penetration, we had almost a guaranteed worst case scenario that most startups would dream about.  We knew that our talent pool was so strong, that even in the event that we just ran out of money, one of the big three search engines would simply buy us for our team.

At that time we knew that a talented engineer in a tough to get tech was worth about $1.5 million per head.  Thus, I knew with relative assurance that since we were going to hire at least 70 people with our Series A money, that our worst case scenario was about a $100 million exit.

If anyone is paying attention, you are now saying, wait a minute!  Didn’t Powerset sell for $100 million to MSFT?  …. Yup, we nailed our worse case scenario!

That really struck home with me. Recruiting engineers is incredibly difficult and this implied that it might be easier: All you have to do is pick a language that you can dominate the market in and you are positioned to easily recruit engineering talent – one of the hardest parts of growing a company.

So what language should I choose if I am starting a company in the Baltimore/DC area?

Interestingly, Baltimore has a very large Rails community: So many Rails people that RailsConf has come to Baltimore several years in a row. But of course, that means there are already places that are Rails nexi for the community: 410 Labs and Smart Logic Solutions come to mind.

I think of Clojure or Scala as relatively specialized languages – probably inappropriate for whatever start-up I may one day have in mind. What choices do I have? PHP? Python?

I am interested in hearing people’s thinking here. What are the best languages for me to try and build a cult of ninjas around in this area?

Companies Are Sold, Not Bought

Tuesday, April 26th, 2011

“Companies are bought, not sold”

This is a cliche as old as M&A, and there is a lot of truth to it. When I started my last company, from time to time we would get interest in acquiring the business from third parties. My wife would start to get excited if I mentioned this stuff and I always tempered her with a couple of comments. These are my M&A cliches and I want to share them with you now for the permanent record:

  • Selling a company is a “large complex sale”. Just like real sales. That means you probably need 100 meetings to get a buyer. So I always tried to imagine that you need 100 meetings with different people to sell the company. That means that this meeting, no matter how optimistic the potential acquirer might sound, is unlikely to result in a sale and you should remain even-keeled about these things. The thing you should celebrate – and this is what my wife and I always did – is “We are one meeting closer to 100 meetings!”
  • No matter how good a fit you think you are for the business, you have virtually no input into the process. This is where I always thought half of the cliche came from – the key things that have to happen to make this transaction take place are events inside the buyer where you have little or no control. The CFO wants to focus on integration of the last transaction, your champion is job-hunting and suddenly quits, there is a spat about who would manage the acquisition and someone ends up going scorched earth (“If I can’t have it, then no one can!”, the CEO resolves to focus on maximizing profits to hit a number this quarter, the buyers chief competitor announces a new product and they send M&A off to focus on other things as a result, or technology says they could recreate all of your core technology in a week. This kind of thing happens every day. Every day. There are third party forces at work, which you are unaware of, attempting to derail your acquisition. If the buyer gets distracted, the opportunity goes away.

But I am here to tell you that this is the truth, nothing but the truth, but a partial truth.

There are things you can do to make the sale of a company more likely.

First, go kill it. If you build a great business, people want that. It needs to be a blend of great proprietary technology and a large and growing customer base/revenue stream. Duh. I assume you are reading this because you don’t have all of that. Sales is easy when you have the perfect product.

Second, there are things I don’t know about. I have sold two companies now, and I know that there were things I did to make the sale more likely, but there are lots of people with bigger exits, more exits, and more experience here. Good lawyers probably have ten things that they would put on this list.

Third, momentum is your friend. People talk about deal heat all the time. If the deal is moving, make sure you move it along. The faster you move, the less time a naysayer has to insert obstacles.

Fourth, ABC, baby! Always be closing. When Greg Yardley founded Flurry and I was still at Aol, every time we had lunch, the running joke was that he would start the lunch by saying, “Just so you know, I have a fiduciary responsibility to let you know that we are for sale.” That is a little, ok maybe a lot, tongue in cheek, but you get the idea. Greg was doing two things right: Networking with potential acquirers and looking for opportunities.

Because here is the other half of that cliche: You never know when a company will suddenly decide they need to buy something in a space. When that happens, you want to make sure you that you broke bread with a player in the organization recently and told them your story. Otherwise you might not get the call.

Here is the bottom line: In every transaction I have been involved in, the buyer knew someone on our team, had a long term relationship (greater than one year) with that person, and was familiar with our business as a result. When they felt like buying, they called us.

And that is how we sold.

Let’s get an awesome comment thread started. Give me your reaction now!

Judging Startups & Judging Startup Weekend

Sunday, April 17th, 2011

Mike Brenner was kind enough to ask me to be a judge at Startup Weekend this weekend. I passed, but I never really told him why. I was talking to an entrepreneur this past week about his ideas and I better articulated my thinking. I thought I would document it here because I think my conclusions have interesting implications for some of Startup Weekend’s participants:

Judging start-ups at an early stage is a bullshit business. Having said that, lots of people do it. But they invariably take a portfolio approach and invest only in areas they feel like they can understand. Because usually they are guess wrong.

Everybody knows it. The best one can really hope for is to understand if the business might be interesting to you.

Josh Kopelman has probably made as many early stage investments as anyone in the country over the last couple of years and he passed on Twitter.

I probably talk to an entrepreneur or two every week, so I hear a fair amount of ideas. Here is the trick: most ideas, your average idea, it is hard for me to tell if it is a good or bad idea. All I can really tell is if it is an idea that I could, if time were invested, come to a conclusion regarding whether it is good or bad. The answer to most of these is no: I can probably never tell if your consumer Internet app is a good idea. I can usually never tell if your enterprise software app is a good idea. In fact, the closest I can probably come is that most online advertising start-ups, given time, I could probably determine if they are good or bad ideas.

Unless they are in the affiliate space. Then I wish I would be able to figure it out, but I probably won’t be able to.

The good news for founders is that most people think most ideas are terrible. That means nothing.

If Ev had taken JoshKopelman’s rejection personally, no more Twitter.

Josh passed on Deconstruct Media, which I subsequently grew and sold!

Josh is a better judge than anyone else that is going to look at your start-up and he is wrong all the time.

The only judgements that matter are the yes’s that lead to people writing checks – and the best kind of checks are customers.

The last place team after 54 hours could easily be the most financially lucrative. Don’t trust outside opinions. Unless they are right!

Is Twitter Evil?

Sunday, March 13th, 2011

It is super tragic watching Twitter struggle to find a business model. As has been widely documented, they have made, at some level, a fundamental shift that implies that people should no longer be able to build businesses using the Twitter API.

Frankly, this change in their Terms of Service is nothing less than shocking:

Courtesy of TechCrunch

Now, I am sure that Twitter represents this as “focusing development activity”, but when you look at developer-focused companies (“developers, developers, developers”), developers have always migrated to the most profitable areas and been slowly pushed out of business niches by the integration of functionality. If companies make Twitter clients and fill them with ads, will those end up being more popular than a Twitter client without ads? If Twitter can’t make a client people want to use, what does that mean?

The flip side of this is that, obviously, Google doesn’t let third parties scrape their organic search results and not show the ads.

Twitter is struggling toward some sort of balance, but it is very tough to turn a ship.

Alex Gizis is Worth His Weight In Gold

Wednesday, February 23rd, 2011

Alex Gizis is one of the biggest geeks I know. And I love him for it. This post is about how great it is to know geeks. And more importantly, start companies with geeks.

One of my favorite sayings is that true innovation happens close to the iron. By that I mean that people like myself tend to move the world in one of two ways:

  • incrementally, or
  • impractically

The reason that is true is that I am not close to the iron. I am a suit. People close to the iron can realize much more dramatic change.

I was asked to give an example of this the other day and I used Alex in my example. The example goes something like this:

I have a great idea for a new start-up: We are going to build teleportation devices. Huge market opportunity. I am going to have a market cap bigger than all the car companies, all the airlines, and Fedex… combined. Awesome idea.

Should you join my company? No. I am an insane person. You would dismiss me out of hand.

If Alex called me and said, “Hey Brent, I think I figured out a way to build a machine that teleports matter,” I would quit my job the next day to help him realize it. Because when a guy like Alex tells you that he has ideas that sound crazy, he has figured out how to make them work.

Look at his current company, Connectify. He was playing around with Windows 7 and thought, “I bet I can turn these computers into routers quickly and easily”. Lo and behold, now every Windows 7 box can be a wifi station for free. If I told you, “hey, lets turn every Windows 7 computer into a wifi hot spot and build a mesh network”, I sound crazy. Alex already did it.

I am a suit. My ideas relate to markets and needs that customers have that become more or less apparent to people studying the market. People close to the code see things you can do with the code that no one imagines to be reasonable.

Those are innovations that change the world.