Saturday, August 24, 2013

Rebooting the Bay Bridge: A Classic Rewrite Story

This post was written with Mathew Spolin and published in VentureBeat.

From the smallest startup to the largest multi-national company, the ground-up software rewrite is the unicorn of organizations. At some point, a software system needs to be rewritten from scratch, usually for one or more of three reasons:

  1. Architectural flaws inherent from the onset.
  2. External market conditions that the software can not meet.
  3. Too much deferred maintenance such that the software is unstable and unchangeable.

Software is sometimes hard to understand as it is abstract. However, we have the ultimate physical, real-life rewrite on our doorstep here in San Francisco: the rebuild of the eastern span of the Bay Bridge.

Architectural Flaws

The eastern span of the Bay Bridge, first opened in 1936, had a significant architectural flaw in that it could not survive a high-magnitude earthquake. The magnitude 7 Loma Prieta earthquake in 1989 caused a 76- by 50-foot section of the upper deck to collapse onto the lower deck. There was a single fatality on the bridge and the bridge was out of commission for a month, from October 17 to November 18.

Sometimes software hits an architectural wall, and has to be rewritten. The current mobile and tablet phenomena has caused many traditionally web-only companies to substantially overhaul their software in order to deliver their service to mobile devices.

The Technically Obvious “Rewrite” Proposal

Bridges are hard to build, and the more complicated the bridge, the more complicated and expensive the construction project. The existing eastern span of the bay bridge was nothing fancy, and could be replaced relatively easily by a modern, economical skyway at a cost of $1.1 billion.

When proposing a rewrite of software, things may seem simple at first, and engineers and managers think that they can rip out a new version relatively quickly.

The Rewrite Maelstrom

Although there was a simple alternative, there are lots of stakeholders who couldn’t get what they wanted from the existing bridge and wanted to put their imprint on the new bridge. Jerry Brown, then the mayor of Oakland, demanded that the new bridge be a “statement bridge” since Oakland deserved a modern suspension bridge on par with what San Francisco has with the Western span of the Bay Bridge. Biking advocates demanded a bike lane, even though there is not much to do on Yurba Buena and Treasure Island and the Western span of the bridge doesn’t have a bike lane. Everyone settled on a self-anchored suspension bridge, a type of bridge design that had never been attempted at the scale of the Bay Bridge.

Even though the Governor at the time, Arnold Schwarzenegger, attempted to override everyone and go back to the simpler skyway design, there were so many people and factions involved that eventually the more extensive design was greenlit.

When rewriting software, it is important to consider that there are many people that are stakeholders in the existing solution, and likely have pent up requirements that they were not able to solve with the existing solution that they would now finally like to be addressed with the new solution. It is also extremely difficult to remove features as people expect a new solution to improve on their current solution. This type of requirements creep is all very normal and should be expected, and needs to be addressed well as it can lead to a significant amount of analysis, sometimes paralysis, and a lot of change management.

Agreement Challenges

Even once a new design and its features are agreed upon, there will likely be additional disagreements. In the Bay Bridge’s case, Mayor Willie Brown of San Francisco and Mayor Jerry Brown of Oakland, bickered over whether to put the new bridge to the North or South of the existing bridge. Brown wanted the new bridge placed to the South of the current bridge in order for its shadow to not decrease the value of prime real estate on Yurba Buena Island. Even the Navy was involved, since it was transferring the land to San Francisco, and wouldn’t let Caltrans test the soil at the site. The disagreement dragged on for two years and added hundreds of millions of cost to the project.

When rewriting software, it should be expected that there will be disagreements, so it is critical that all the stakeholders meet regularly, keep the overall project goals in mind, and have the ability to engage in frank and open dialog in order to address issues.

Unforeseen Problems, Delays and Cost

The Bay Bridge had numerous delays and cost overruns, ranging from bad welds due to welders being rushed to bad bolts that the manufacturer changed specifications on after they were initially tested.

During all the debate about what type of bridge to build, and exactly where to build the bridge, China’s building boom began consuming all available concrete and steel, driving up prices. The delays in the Bay Bridge construction ended up costing billions of dollars. The state and local agencies haggled constantly on who would pay for overruns, leading to toll increases and debt. The simple design was estimated to cost $1.1 billion, and the bridge ended up costing $6.3 billion and was delivered years late, with some potential flaws.

In large, complicated projects, unfortunately it should be expected that there are going to be unforeseen problems and delays, in even the most padded schedule. It is a fact of life of engineering and time and cost overruns are unfortunately very typical of large projects. In addition, these types of delays can cause endless thrash in organizations as people expected the new solution and deferred maintenance and features on the existing solution.

Finally, a New Bridge!

I have learned the hard way, unfortunately more than once, that rewrites are an incredibly painful process. They may initially seem simple, but end up taking far more time, money and coordination than initially envisioned. However, on the other side of the process, you end up with a brand spanking new bridge, ready for the future.

For more on the Bay Bridge project, see Wikipedia and

Thursday, August 22, 2013

How to Sell to the CIO, Part 3: Closing the Deal

This post was published in the Wall Street Journal's CIO Journal.

After almost two decades of selling enterprise infrastructure to IT organizations, I have spent the last two years on the other side of the table as the CIO/CTO of CBS Interactive. This is part three of a three part series on how to sell to CIOs.

In part one, I provided tips for getting into an account and in part two I discussed how to navigate the sales process. Now it’s time to close the deal.


Deals are going to take as long as they take, and there is really not much a vendor can do to make all the stars align within a big enterprise. A sophisticated vendor understands that large enterprises have a lot of processes in place to close deals and an aversion to new vendors. There is generally no shortcut through legal, finance and other internal approvals.

When a vendor asks for deviations so that they can make a number or close the deal in Q4 as they promised the board, it makes them seem weak and engenders doubt. It leads everyone internally to ask, “Are they really so desperate that our $150K is a make or break for them?”

While there’s no way to tactfully ask for a deal to get expedited, a vendor should understand a company’s process and track that the deal is going well. We had a deal with VMware Inc. that slid for two quarters for various reasons. They were so patient and diligent that in the end, we took them out to dinner.


Sometimes vendors agree to a price range at the beginning of a sales process and then change the price when it’s time to close. Agreeing to terms during contract iteration and then shifting parameters around and returning something completely different for each subsequent iteration makes a vendor look untrustworthy and unreliable. We once got very far along with a vendor, showed them how to pitch to our business units, had everyone lined up to switch to this vendor, and then they started playing tactics like this and we walked away.

When the reasons behind pricing are not clearly communicated, the vendor gets blamed. We once requested a tiered price instead of a flat fee for a deal to access segmentation information ad hoc. It was a reasonable request that the vendor accommodated, but unfortunately a rumor spread through our organization that we were paying by the impression to access our own data. The pricing was so customized that we had a hard time getting buy-in. As word of the pricing debacle spread, it reflected poorly on the company. So if the pricing model is customized in order to close the deal, be sure that it is very clear why this is the case and that the information is disseminated widely.

Deals always seem to get hung up on indemnification. While everyone seems to know where a deal will end up, it often takes weeks of back-and-forth between legal and a couple of ultimatums to close. If I ever run a software company again, I will be sure to have two pricing tiers: greater indemnification at a higher price, less indemnification at a lower price. You pick, and we all save ourselves a big headache.

Reputation Matters

The biggest surprise I had upon running a large IT organization is the level of information sharing and collaboration between CIOs at different companies, particularly about vendors. Most CIOs and IT VPs are all very accessible, candid, and frank with each other about what products they are using, how the vendors are doing, and how they make internal decisions.

Vendors should be aware that their performance quickly makes the rounds, both in a particular vertical and across different verticals. This type of diligence accelerates as more players across finance and legal get involved in a deal. “I heard they completely screwed up at Company X” will kill a deal even if it is on the verge of signing. Vendors need to make sure that they have happy customers.

In addition, executives often transition between companies in a vertical such as media or finance. One of my biggest internal stakeholders for a video platform had a bad experience with a potential vendor at his previous company — a cable channel without a large video-streaming offering. The vendor CEO’s reasoned that the previous company was small, and that we would be treated a lot differently as a large customer. Wrong answer. A much better approach would have been to figure out exactly what went wrong at the previous account, remediate it, or at least offer a “lessons learned” on how they have improved service.

Reputation is also important globally. If a vendor does a global deal with a company but doesn’t provide good service to the satellite locations, the international offices will go out and find their own vendor, causing a lot of thrash throughout the company. A global deal is not done until it’s delivered well internationally.

Account Management

Once a deal looks like it is about to be signed, there is typically a hand off to account management. A lot of vendors fail at this step. Salespeople need to be incented to ensure that there is a clean handoff. Vendors would also be wise to ensure a single account management point of contact, especially for larger organizations. Handing us an organizational chart with different contacts for professional services, technical issues, and billing makes us feel like we are not getting what we paid for.

And finally, a note of caution about growing organically within an organization: Although it can look like a vendor has traction because they are used in multiple departments, they can still be replaced. For example, in the cloud file-sharing segment, we were running Dropbox Inc., Box Inc., Google Inc.’s Google Drive, and others. When it became clear that we needed one official cloud storage vendor, our corporate IT folks took all the vendors through a rigorous process and picked a single vendor. Soon after, the other vendors were blocked at the firewall level. To stay relevant, a vendor should stay ahead of the customer with new features, provide excellent service, and be proactive if there is downtime or failures.

Sell to Yourself

The best thing a vendor can do is have staff who are domain experts at what they are selling and also staff who have worked in a decision-making capacity within enterprise IT. Sometimes that’s not possible, so I’ve shared my experiences to give vendors the inside look on how enterprise IT makes purchasing decisions and how to optimize time for everyone involved. A clear, straightforward pitch, a salient case for how your product will help the customer, and a good deal of patience go a long way when it comes to selling to the CIO.

Thursday, August 15, 2013

How to Sell to the CIO, Part 2: The Sales Process

This post was published in the Wall Street Journal's CIO Journal.

After almost two decades of selling enterprise infrastructure to IT organizations, I have spent the last two years on the other side of the table as the CIO/CTO of CBS Interactive. This is the second of a three part series on how to sell to CIOs.

The tips I laid out in part one helped you get into an account. But getting the meeting is just the beginning. Now it’s time to sell your product.

Sell the ROI

The question enterprise IT has for the salesperson during a sales meeting is, “Will your product save or make us money and does it have low risk?” As Founder and CEO of Upstream Group Doug Weaver writes, “They’re not thinking about helping you out or what kind of day you’re having. ‘What’s in it for me?’ is the order of the day.”

A vendor needs to have a very clear and verifiable return on investment (ROI) story with measurable metrics. There are times when companies buy software or services without evaluating ROI, such as during the e-commerce push in the dot-com boom and the social craze of the past couple of years, but these are the exceptions.

An ROI story should use the right numbers. I have experienced several instances where vendors offer ROI examples that don’t add up. For example, a database-as-a-service solution that is deployed on-premises and is pitched as cheaper than Inc.’s Relational Database Service. The comparison leaves out the cost of the database administrators needed to run the solution on premises. Also, many vendors don’t take into account the difference between capital expense and operating expense, a distinction that should always be included in ROI calculations.

There is generally a significant transition and maintenance cost to adopt new technology that IT organizations consider before starting a new vendor relationship. Numerous vendors have pitched us on “reporting in the cloud,” but never consider the cost of copying vast volumes of our data to their system or the compliance and regulatory headache that comes with having our proprietary data in their hands. The reporting features need to be morethan an on-premises solution for us to even entertain the concept.

Product Fit

It is critical for vendors selling a product to an enterprise to have people with domain expertise on their team.

Vendors should be very careful about “vaporware,” products that are announced but not yet implemented. For example, once a vendor showed screenshots and demonstrations of their product working in a certain way, but when we trialed the solution, we found that the software was missing several key features. The vendor then acknowledged that the features would be coming out in six months. Unfortunately, after wasting my team’s time, we will not give them another chance any time soon.

While it’s important to cater to the customer, make sure other enterprises also need a product feature before adding every feature a company requests. One approach for vendors is to have a blanket policy that three customers must request the same feature before it is implemented (but be careful when wielding that stick as customers often do talk to each other). There are, of course, certain products that inherently need to be customized and should include a set amount of professional services. Finding the right balance will result in a product fit that works for both the vendor and the customer.

Go to the Right Person

To sell to an IT organization, convince the person who actually has the problem. When someone three levels down in my organization comes running into my office and proclaims that they found a great product that pays for itself in six months, will save us money, and that they have already trialed it and it works well, there’s a great chance that deal is going to get done.

Get the attention of the database manager, the networking director, the system administration manager, the procurement director or whoever is the appropriate person and convince them to try the product. The best way to sell to people on the software side is to have a product that they can find, deploy and use on their own without needing to talk to anyone at the vendor.

MySQL’s Marten Mickos perfected this strategy with his “15 minutes to delight” philosophy, previously unthinkable for a product like a database. Subsequent products from Atlassian Inc., New Relic and Splunk have adopted this business model, and their growth reflects this philosophy’s focus on delivering a killer product.

Once a product has already been tested, the sales process becomes much smoother. Vendors can direct their salespeople to focus on learning the organization and helping to navigate finance, legal and stakeholders’ agendas to ensure that required features are added to the roadmap. Once a product sells itself, the sales organization doesn’t waste time chasing down leads and requesting face-to-face meetings.

This advice does not apply to companies selling deep workflow solutions like order management software that requires a lot of analysis, buy-in from multiple stakeholders and has a long implementation time. These types of solutions still require “traditional” sales techniques and cycles. The best way to close a deal like this done is to understand that it will take a long time and to identify an executive champion that will help push it through.

I will explain more about how to close a deal in the final part of this guide on selling to the CIO.

Thursday, August 08, 2013

How to Sell to the CIO, Part 1: The Initial Pitch

This post was published in the Wall Street Journal's CIO Journal.

After almost two decades of selling business infrastructure to technology companies, I thought I knew it all. But since spending the last two years on the other side of the table as the CIO/CTO of CBS Interactive, I realized how much I didn’t know about selling to enterprise IT.

The way to truly understand how and why an enterprise purchases technology is by gaining the ability to understand how IT departments at medium to large-size organizations work, how decision-making actually happens and how vendors can avoid getting in their own way.

Based on my experience on both sides, the following guide aims to help salespeople and companies become more efficient for both their clients and themselves.

Be clear what it is you do

A pitch, whether from a small startup or a multinational corporation, should always concisely state the following:

1. Description: What the offering specifically does, how it’s different from competitors and how it can help a CIO. Ideally this includes some tangibles, such as screenshots or performance graphs.

2. Validation: What stage the product is at and who else is using it.

3. Process: How can the offering be purchased, what the typical on-ramp looks like, and how much it costs.

Here’s a mock example of a good pitch:

Super Interconnect provides a next generation fiber interconnect that is 10x the speed of existing interconnects. Super Interconnect makes it possible for your web and application servers to quickly access backend resources such as databases, thereby significantly reducing latency to customers. As you can see in the attached graph, we offer 25x the price/performance of 10gigE, and are a year ahead of other nextgen fiber interconnect technologies.

Super Interconnect is a young company, however we all come from networking companies such as Cisco and Juniper, and are well funded by top venture capitalist firms Accel and Sequoia. A few of your peers such as PepsiCo and Walt Disney Company are actively using Super Interconnect and can serve as references.

We sell our product direct to IT organization and can work through your preferred resellers. A typical POC takes 30 days to deploy with minimal time by your staff. Super Interconnect is priced at $1K/server, a 300% significant $/gbps savings over 10gigE.”

If an introductory pitch can’t cover this basic information, IT professionals will get the sense that a meeting will likely be painful and will want to avoid it.

Also, if a company is new and doesn’t have a product yet, it’s best for the vendor to be honest and say that they are in a research phase. Instead of polling a number of CIOs, vendors might consider finding and collaborating with a domain expert that knows the next thing an enterprise will need. Hype and vision won’t sell.

Time is not the answer

Virtually every contact a CIO receives has the same ask: for a meeting or phone call. As most CIOs’ schedules are crammed, realize that coffee, lunch, drinks, dinner and events are particularly tough requests. So instead of asking for the CIO, who is not even the best decision-maker on a lot of new technology, vendors should ask to talk to the right experts in a CIO’s organization.

For startups in particular, sales and business development executives love to have big brand names and titles in their pipeline. Even when it is clear that a product is not a fit, they still push hard for a meeting in order to justify their own value to their management chain. This can reflect badly on a startup, so salespeople need to work to find the right targets and measure success not by the amount of meetings, but by how many prospects are moving into the next step in the sales funnel.

Bypassing IT is not realistic

Selling directly to a line of business and bypassing IT is not realistic. IT is generally with the program, supportive of cloud applications and no longer a roadblock like in years past. And lines of business need to have their tools integrated with their company’s overarching systems as well as be in compliance with security and Sarbanes-Oxley policies.

Treating the IT department like a speedbump signals that the vendor does not value what IT thinks. Lines of business typically partner with IT, and a deal takes agreement between the two.

Understand the IT culture

While IT vendors spend their time trying to sell to IT departments, they rarely have anyone on staff that has actually worked in an IT department. IT departments have a certain culture and the best way to sell to them is to understand how they work.

When a vendor secures a meeting, it’s in their interest to show up early, be on their best behavior, dress and act professionally and make sure not to reschedule unless a significant life event occurs. Once a vendor has the attention of IT management, they should tell it like it is and then try to close a deal. There are quite a few vendors that don’t answer direct questions regarding features and pricing.

Startup companies need to make sure to spend more time talking about how their passion is solving a customer’s problem, than about how their idea is “awesome.” The history of the company and its various pivots can be interesting, but only within the context of how excited the founders are to solve a business problem for a customer.

Getting feedback

IT managers are generally loathe to give any feedback since it usually engenders hostility. Quite often, what a vendor is selling is not a good fit for a particular enterprise. Particularly for startup founders, learning this can be quite emotional. It is important for founders to contain that emotion and try to learn exactly how a product needs to shift in order to meet the needs of an enterprise customer.

The best way to get feedback is to ask specific questions. For example: What is it that the customer likes and doesn’t like about their current solution? How hard would it be to move to a new solution? And is it realistic that the customer would move to a new solution or will they simply wait for their existing vendor to add the missing features?

The flip side

Enterprise IT is guilty of wasting vendors’ time in order to learn what’s going on in the industry and to keep options open. A question I used to ask when I was on the vendor side of the table was, “What’s the last product you bought and what was the process like?” If no one can answer, the IT group is clearly very conservative and a vendor should come back in a year after they have found and closed some early adopters.

In the next part of “How to Sell to the CIO,” I will discuss the sales process.

Saturday, August 03, 2013

In Mastering Machine Intelligence, Google Rewrites Search Engine Rules

This post was written with Cameron Olthius and published on TechCrunch.

Google has produced a car that drives itself and an Android operating system that has remarkably good speech recognition. Yes, Google has begun to master machine intelligence. So it should be no surprise that Google has finally started to figure out how to stop bad actors from gaming its crown jewel – the Google search engine. We say finally because it’s something Google has always talked about, but, until recently, has never actually been able to do.

With the improved search engine, SEO experts will have to learn a new playbook if they want to stay in the game.

SEO Wars

In January 2011, there was a groundswell of user complaints kicked off by Vivek Wadwa about Google’s search results being subpar and gamed by black hat SEO experts, people who use questionable techniques to improve search-engine results. By exploiting weaknesses in Google’s search algorithms, these characters made search less helpful for all of us.

We have been tracking the issue for a while. Back in 2007, we wrote about Americans experiencing “search engine fatigue,” as advertisers found ways to “game the system” so that their content appeared first in search results (read more here). And in 2009, we wrote about Google’s shift to providing “answers,” such as maps results and weather above search results.

Even the shift to answers was not enough to end Google’s ongoing war with SEO experts. As we describe in this CNET article from early 2012, it turns out that answers were even easier to monetize than ads. This was one of the reasons Google has increasingly turned to socially curated links.

In the past couple of years, Google has deployed a wave of algorithm updates, including Panda and Panda 2, Penguin, as well as updates to existing mechanisms such as Quality Deserved Freshness. In addition, Google made it harder to figure out what keywords people are using when they search.

The onslaught of algorithm updates has effectively made it increasingly more difficult for a host of black hat SEO techniques — such as duplicative content, link farming and keyword stuffing — to work. This doesn’t mean those techniques won’t work. One look into a query like “payday loans” or ‘‘viagra” proves they still do. But these techniques are now more query-dependent, meaning that Google has essentially given a pass for certain verticals that are naturally more overwhelmed with spam. But for the most part, using “SEO magic” to build a content site is no longer a viable long-term strategy.

The New Rules Of SEO

So is SEO over? Far from it. SEO is as important as ever. Understanding Google’s policies and not running afoul of them is critical to maintaining placement on Google search results.

With these latest changes, SEO experts will now need to have a deep understanding of the various reasons a site can inadvertently be punished by Google and how best to create solutions needed to fix the issues, or avoid them altogether.

Here’s what SEO experts need to focus on now:

Clean, well-structured site architecture. Sites should be easy to use and navigate, employ clean URL structures that make hierarchical sense, properly link internally, and have all pages, sections and categories properly labeled and tagged.

Usable Pages. Pages should be simple, clear, provide unique value, and meet the average user’s reason for coming to the page. Google wants to serve up results that will satisfy a user’s search intent. It does not want to serve up results that users will visit, click the back button, and select the next result.

Interesting content. Pages need to have more than straight facts that Google can answer above the search results, so a page needs to show more than the weather or a sports score.

No hidden content. Google sometimes thinks that hidden content is meant to game the system. So be very careful about handling hidden items that users can toggle on and off or creative pagination.

Good mobile experience. Google now penalizes sites that do not have a clean, speedy and presentable mobile experience. Sites need to stop delivering desktop web pages to mobile devices.

Duplicate content. When you think of duplicate content you probably think of content copied from one page or site to another, but that’s not the only form. Things like a URL resolving using various parameters, printable pages, and canonical issues can often create duplicate content issues that harm a site.

Markup. Rich snippets and structured data markup will help Google better understand content, as well as help users understand what’s on a page and why it’s relevant to their query, which can result in higher click-through rates.

Google chasing down and excluding content from bad actors is a huge opportunity for web content creators. Creating great content and working with SEO professionals from inception through maintenance can produce amazing results. Some of our sites have even doubled in Google traffic over the past 12 months.

So don’t think of Google’s changes as another offensive in the ongoing SEO battles. If played correctly, everyone will be better off now.