Category Archives: Uncategorized

The CMO Files: Alan Cohen, Illumio


Name:
Alan Cohen

 Organisation: Illumio

 Job title: Chief Commercial Officer

 Location: Sunnyvale, California, US

  1. Where were you born and raised?
    I was born in the Coney Island section of Brooklyn, New York, a few blocks from the Cyclone roller coaster and Nathan’s hot dogs. I lived there until I was 16 and went to college.
  2. What was your first job?
    I was always working, even from a young age. I started working with my father in his catering business when I was under 10 — I would put toothpicks in the hors d’oeuvres and wrap trays of food; he would teach me how to figure out the gross margin of a delivery. My first tie and jacket job was with the Department of Energy in Washington, D.C., where I was an analyst.
  3. What was the first product you got really excited about?
    From an IT perspective, it was my Leading Edge XT PC. It had one floppy drive and a 10MB hard drive. I wrote a master’s thesis on it and it changed my perspective on writing. From a consumer perspective, it was the Sony Walkman. Taking your music on the move was amazing.
  4. Who has been the biggest influence on your career?
    Early on it was my brother who paved the way to my understanding that there are no obstacles to your achievements other than the limitations you impose on yourself — no matter how humble your background. You create yourself.
  5. What has been your greatest achievement?
    The companies that I have helped build sent a lot of kids to college and helped pay a lot of mortgages.
  6. What has been your biggest mistake?
    My mistakes have been around timing. I had a twisty road into tech and started in bigger companies. It took a while to understand how to build a market. My first startup built a brilliant 3G router when there were no 3G devices to take advantage of it. We were all dressed up with nowhere to go. It was a colossal fireball.
  7. What is your greatest strength?
    I am a classic right brain kind of person. Non-linear thinking is useful in the world of engineers – it helped differentiate me from the pack. My experience and track record is the contrarian evidence to Vinod Khosla’s ridiculous comments in about English majors.
  8. What is your biggest weakness?
    In the closing of Othello, the lead character says, “Say not that I loved wisely, but too well.” You need to be a passionate advocate of your product and team if you build a career in marketing, but that means you also must choose well. I have not always chosen perfectly, but I have gotten better in the past 15 years.
  9. What do you think is the aspect of your role most neglected by peers?
    All too frequently, people see marketing as a discipline or series of sub-disciplines (positioning, demand generation, competitive, etc.). This is huge red flag. Marketers need to understand how customers relate to a product or the company from the first time someone hears about it, through the acquisition cycle, to how people experience the purchase over time. That is the role of a chief commercial officer versus a CMO.
  10. Which word or phrase is your mantra and which word or phrase makes you squirm?
    Three descriptors that make me squirm are: thought leader, visionary and entrepreneurial. If someone describes him or herself that way, it is likely they are not.
  11. What makes you stressed?
    There are good and bad forms of stress. Stress is what keeps animals alive in the wilderness. When people do not do the best they can, that stresses me out.
  12. What do you do to relax?
    Long bike rides and high-intensity workouts are great day-to-day reducers of stress. Sitting in a glade of giant sequoias and breathing is magical, but I do not get to do that as often as I like.
  13. What is your favourite song?
    Anything by the Grateful Dead or Mozart
  14. Which book taught you most?
    Viktor Frankl’s Man Search for Meaning puts pretty much everything into perspective.
  15. Do you have a team or sport that you follow?
    I have been a devoted Oakland Raider and Golden State Warrior season ticket holder for over a decade. I did not just jump on the bandwagon.
  16. Which country would you like to work in?
    I would love to live in Copenhagen for a few years. The Danes must be the happiest people in the world.
  17. Which company do you think has the best marketing? You must answer this question over time versus in the moment (5 years ago you might have answered Apple, but maybe not so much anymore).
    I would say Disney. Disney is an experience brand as much as a product brand, and almost every Disney experience is fantastic. They hook you at very young age and keep you through life, even though you do not know many of their brands are Disney products (e.g., Miramax).
  18. What do you love most about your job?
    I get to reinvent it every day. There is no cookbook for what Illumio is doing.
  19. What is your favorite book?
    James Joyce’s Ulysses. It takes place over the course of one day and you see a historical slice of an entire city, country and culture in it. Imagine if you could experience your life like that every day?
  20. What keeps you awake at night?
    Very little keeps me up, but a lot wakes me up early in the morning (4:30-5:00 a.m.). I always feel like I am behind and there is more to do.
Advertisements

Go Slow & No

The shift from mainframe to client-server computing between 1980 and 2000 led to an explosion of choices for IT. Until 1980, there was usually a piece of big iron (from IBM) that sat in the data center and ran a limited number of applications. The post-mainframe generation of IT expansion came with a corresponding growth of specializations and silos in the IT organization.

CIOs, throughout this transition, increasingly presided over a range of organizations and titles that reflected the various infrastructure categories (networking, compute, etc.), the application development process (developer, architect, etc.), and related functions that enabled the performance and protection of company business processes and IP (security, architecture, etc.).

From the perspective of building new applications, much of this choice actually slowed business by introducing many human touch-points in both decision-making processes and technology integration. When industries were defined by long-term structural competition, the speed of IT was not a gating factor. Today, when software is eating the world, however, speed is everything.

DevOps (and Speed) Come to Security

Specific IT roles that developed evolved into personas or stereotypes, sometimes grounded in truth and sometimes not. Application developers were the fast or ‘go’ crowd as they faced the changing needs of the business and were tasked to respond. Infrastructure teams were ‘slow’, reflecting the challenges of bringing up new systems mired in a range of complexity. And the security teams were the people who said ‘no’ to doing new things, often leading to forms of shadow IT and even larger risks for the enterprise.

There are reasons why security and risk professionals often react with a ‘no’. When you are tasked with assessing and reducing risk, going fast might not be the first instinct. Orchestration tools and infrastructure virtualization have removed many of the barriers from DevOps and infrastructure from going fast. Now, even in the era of the mega-breach, there are tools that have emerged giving security teams an opportunity to move at DevOps speed — making them a true partner as opposed to a traffic cop.

DevOps-style Security and the CISO Who Says ‘Yes’

In a recent podcast with Jawbone CISO Justin Dolly, we discussed how a CISO can move rapidly through new technologies but also still mitigate risks by understanding which technology assets, people and processes must be prioritized. By instantiating security directly into the development process – when a workload spins up to create a new application – and continuously delivering security directly on the compute layer, IT teams can fully support new movements such as DevOps without fear of increasing risk. This is especially true when it comes to providing security for the newest compute innovations as well as dynamic environments such as Amazon Web Services (AWS) and Microsoft Azure.

By enabling continuous security at DevOps speed, IT can both have fine-grained controls of computing but also adapt to changes in the environment. This requires a new approach with the following five principles:

  1. Security gets built into applications and not bolted on afterward
  2. Security becomes increasingly a distributed responsibility that mirrors the computing it is protecting
  3. Security integrates with modern orchestration tools such as Puppet Labs, Chef and Ansible
  4. Automation and continuous monitoring and enforcement will replace manual management of rules and policies; security teams can focus on high-risk threats and incursions vs. lower-level infrastructure management tasks
  5. Security becomes decoupled from the infrastructure so it can adapt to new infrastructure, and it must provide the same or better visibility and segmentation/isolation that the infrastructure supports in computing today

As DevOps speeds make their way into the security cycle, it is likely new security titles will appear as well, including, security automation architect or security workflow expert. A key attribute of each will be that they will all get to say, ‘Yes, let’s go fast’.

Good Fences Do Not Make Good Neighbors

Continuous delivery of software and applications is one of the most significant advancements that has taken place in the computing industry in the past 25 years. It is catching on so fast that you can now hear the death rattle of the 18-month software delivery cycle. The rise of cloud computing infrastructures — both in corporate data centers and infrastructure-as-as-service providers (IaaS) such as Amazon Web Services (AWS) — is powered by agile software development teams using orchestration tools like Puppet and Chef to decouple application development from the infrastructure, adding speed and agility to the enterprise.

Just as enterprise computing is having its DevOps moment, though, much of the security profession has woken up to the fact they are mired in the traditional infrastructure and silo approach. When everything in computing is dynamic, distributed, heterogeneous, and hybrid (i.e., alive), security that is bonded to static infrastructures like the network — an architecture based on hierarchies and chokepoints — appears out of sync with the new reality. If you are a security professional, continuous delivery and agile development is your future.

Consider the traditional approach to securing applications. Development creates a new app and then passes it over to the infrastructure team, which then onboards it to server, storage, and networking platforms. When that is complete, the security team comes in to protect it so employees, partners, suppliers, and customers can use it securely.

Software Development Lifecycle

The organizational “fences” among these teams can leave security practitioners with poor visibility into how an application is constructed from a security perspective. It may start with limited or no documentation of how an application communicates among its various components as well as its various user groups. This causes risk challenges for IT in several ways:

• The handoffs among the various IT teams increase the operational overhead related to security and drive opaqueness among them. This means deployments are delayed, which creates pressure on security teams to meet schedules related to the business.

• More “cooks in the kitchen,” as it relates to the application development cycle, can increase the “attack surface” available to hackers by leaving ports on physical or virtual servers open or ignored by traditional perimeter security technologies.

• Any changes in applications (patches, updates, etc.) will have ripple effects for security teams trying to keep up, which must revisit the impact to both the application as well as the infrastructure.

What would happen if security became part of the development process from day one? What would happen if security adapted to a more fluid, continuous delivery world?

The good news is that security is evolving. Gartner has outlined how new Adaptive Securityplatforms are emerging that treat security protection as a continuous process, mirroring the changes in application development and software-defined infrastructures. Rather than bringing “batch” updates to firewall rules or IDS/APT systems, new adaptive security approaches can both streamline data center security processes as well as reduce the friction among various IT constituencies.

For security to flourish in the age of continuous delivery, it must meet the following requirements:

1. Security policy must be embedded into the application development cycle at inception. This means developers must co-join with infrastructure and security teams to create and instrument policy when they are creating new apps. Just as continuous delivery dissolves the barriers between developers and infrastructure, security will be the next silo to go.

2. Enforcement of security policies must move and adapt with the continuous delivery approach. If new applications are moved between private clouds and IaaS environments, security must move with the applications.

3. Thus, security must be decoupled from infrastructure to support the distributed and fluid nature of continuous, on-demand applications and supporting infrastructures. This provides an added benefit of being able to dynamically add resources on-demand, including security

4. Finally, as Gartner notes, security must offer detective, preventive, responsive, and predictive capabilities that adapt with changes in the threat environment and provide transparency to the various IT constituencies involved.

While the leadership of the security team in protecting a company’s IP and assets will never go away, the responsibility increasingly must become part of the mission for other IT groups. Perhaps Robert Frost did not have it quite right: good fences do not make good neighbors.

This article originally appeared in SecurityWeek

When building a company, it’s the destination, not the journey

Platitudes are a dangerous way to build a company.

What passes today as start-up wisdom can be attractive, even seductive to new entrepreneurs. We have witnessed the creation of a sub-industry of how-to advice on creating the next tech blockbuster. Don’t get me wrong: A lot of what’s written or spoken about is incredibly valuable, but, out of context, of it can be dead wrong, even dangerous.

The Winning Viable Product (WVP)

I am a fan of the Lean Startup approach. If you are creating a consumer app in a new category, the idea of minimum viable product (MVP) is an ideal way to get something out, test it, and then either move forward with conviction or fail fast. If you are going to take on a large technology or Internet company on their home turf, then you should be thinking about the winning viable product (WVP), the one that will give you a multi-year lead over incumbents.

Make no mistake, if you are just a bit better than the incumbent, you will likely flame out early. Try messing with a giant’s profit sanctuary: A market leader will fight, discount and outright stretch the truth about pending capabilities while they hustle to catch up. Moreover, their installed base will usually wait for them if the gap and obvious benefits are not wide enough. Switching costs are one the most powerful forces in the tech universe.

If you want to take a market away from a multi-billion dollar player, to paraphrase former Chairman of the Joint Chiefs of Staff Colin Powell, enter a conflict with clear intent and overwhelming force. Since you cannot manifest this early on with market reach — sales, marketing, deep customer relationships, etc., — then your product must make the decision a no-brainer for customers. WVPs are your weapons of mass disruption.

It’s a sprint, not a marathon

When a shift in the market occurs, the “execution machine” must be in high gear if you want to translate early mover advantage into something sustainable. Prior execution machines such as Data Domain gained disproportionate benefits,particularly in the first few years of creating a new market, by pushing the pedal closer to the metal as sales took off. You could argue this underlies the early (and continued) success of Salesforce.com, Facebook, FireEye, and even Snapchat (yes, I said Snapchat!).

This means your product both must hit its target market with force and then you have to hit the afterburners to get to as many paying customers as possible. Build your company, product, and go-to-market like you are a participant in the Hunger Games. This takes a lot of confidence not only of product fit, but market readiness. Moreover, if your company will take some time to monetize, then you need a big war chest. This is why we are seeing larger A and B rounds.

It’s OK to go home with a different date

There is nothing smarter than being cheek-to-jowl with your early customers. Do your job well, and you will have them for life. Building a company, though, is not about going to the prom.

Sometimes your initial customer group is actually a poor fit for your product strategy (e.g., you were thinking about a vertical insertion in retail and healthcare is a more attractive segment). You have to get past an emotional conflict, like a teenager leaving the dance with a different date. An entrepreneur must not fall into the trap of Shakespeare’s Othello: “one that loved not wisely, but too well”.

It’s a zero-sum game

Some companies build their strategies around being in the “herd,” one of five to 10 players in a market with a hope of getting acquired. That is a failed path for your company and your investors. Most value accrues to top one or two market share players.

As Will Farrell’s infamous racecar driver character, Ricky Bobby, kept repeating: “If you’re not first, you’re last.”

 

This blog originally appeared in Gigaom

 

 

How to Survive the Era of the Hack: 5 Things Every Enterprise Should Know

Commentators called 2014 the “year of the hack.” Many companies (and individuals) were sorely pressed to counter a seemingly non-stop vector of cyberthreats, as the bad guys became smarter and more lethal in the damage they could inflict.

With the rotation to all things cyber, there is less focus on core security capabilities that could have reduced much of the attack surface as well as the spread of breaches and malware.

One key question worth positing is whether companies fundamentally changed their security posture vis-à-vis their infrastructure and applications during this period. If enterprises want to counter cyberthreats, they need to both invest in APT and anti-malware technologies and improve their overall security posture. Following are five approaches enterprises should consider.

1. Ubiquitous Understanding of Computing in the Data Center and Cloud

If you ask an IT team whether they know all of the computing images running inside their data center and public cloud, they are likely to say “probably.” If you ask whether they know what ports each workload has open, the answer will change to “probably not.” This is the equivalent of not knowing whether all the doors within an apartment building are locked when a cat burglar is lurking in the building. Because of the threat of lateral communications exposure, enterprises need comprehensive and continuous visibility to all of their computing assets.

2. Shrink the Attack Surface, Reduce the Spread

The rough segmentation and isolation presented by the data center perimeter—hard crunchy exterior, soft chewy interior—means, for the most part, once you are behind the firewall, things are pretty much in the clear. Building on ubiquitous understanding, it important to create finer-grain segmentation of applications beyond traditional networking approaches like VLANs, zones, and subnets to make it more difficult to get to specific computing assets. The secondary benefit of micro-segmentation is reducing the ability of malware to spread between workloads in the data center.

3. Built In, Not Bolted On

Today’s standard operational model of building applications usually calls for security to be “added” to an application after it has been built. The very act of having a developer hand off her work to someone else to secure it dramatically increases the risk profile of protecting the application since they have to “discover” exposures. IT must move to a model where security is embedded into the development process and not just bolted on afterwards.

4. Reducing Complexity Can Make You More Secure

Everything in the computing world has become more dynamic, distributed, heterogeneous, and hybrid over the past 10 years. Yet the network-oriented security chokepoint is built on a hierarchical model that requires everything to be brought back to it. Enterprises have thousands to millions of firewall rules, ACLs, and zones, many of which serve no purpose, but IT managers are too afraid to take them down (not knowing the impact of doing so). The easiest way to reduce this complexity—and remove the primal fear of living in this regime—is to create a security architecture that adapts to the changing computing environment without the “policy debt” of IP addressing.

5. Embrace Diversity: Data Center and Cloud, Bare Metal and Software

Today’s computing environment is a little like Rome: The current empire is built on top of the previous ones. The only way to thrive is to embrace the past and not simply add an additional layer of security. Said simply, security approaches must embrace both the data center and the cloud, and not bifurcate along infrastructure lines. Today, it is common to see an enterprise’s computing stack running on Linux, Windows, virtual machines, and increasingly containers, on premises or in an Infrastructure-as-a-Service environment such as Amazon Web Services.

Charles Dickens noted that we “forge the chains [we] wear in life.” No one should simply throw away the practices of the past, nor should they be bonded to them in a changing landscape.

 

This blog originally appear in Wired.

More Maslow’s Hierarchy, Less Maslow’s Hammer

Walk into many startups and you will find products code-named after mythic figures and superheroes (one of my companies designated its releases after characters in “The Lord of the Rings”; another named them after Marvel’s Avengers series). Lofty aspirations are on the lips of thousands of entrepreneurs every day, much like “… and world peace” comes out of the mouths of beauty contestants in the film “Miss Congeniality.”

heirarchyofneeds

Building new technologies and new companies are part of how company builders move up Maslow’s Hierarchy, the organizing theory put forth by psychologist Abraham Maslow to describe human motivation. Despite the lower-than-market-rate paychecks and long hours spent away from friends and family, we flock to fledgling companies because of a higher sense of purpose: We want to create something new, to work with a great team, and to be part of something.

Challenging existing boundaries is a key extension of our national psyche, and part of the popular culture upon which America is built. Today, Steve Jobs and Elon Musk are our pop heroes, much like Lewis and Clark, Thomas Edison and Henry Ford were in the past.

Changing the world — actually, changing anything — turns out to be staggeringly hard work and exceedingly rare, as my former board member Ben Horowitz illustrates in his must-read book about company-building, “The Hard Thing About Hard Things.”

In the technology world, most startups and existing players actually set the bar way too low for their company, employees and investors. While many entrepreneurs are motivated by raw technical challenge, many experienced company builders easily fall into a Catch-22 of taking what they know from a prior technology or work experience and applying it to something new. My first startup did exactly that, with a spectacularly poor outcome — a colossal fireball of lost money and opportunity.

nail

What causes many new technologies to fail is that instead of being enough Maslow’s Hierarchy, they are too muchMaslow’s Hammer: “If you are a hammer, everything is a nail.”

This paucity of ambition is especially true of innovation teams trying to repurpose an existing technology into a new niche. While large companies are most frequently accused of this error of judgment, startups are subject to the same sin. Repurposing an older technology is familiar and comfortable, like putting on a favorite pair of jeans; it still looks good and somehow just feels right. But, it rarely works.

As a company or technology builder, there are some self-diagnostics you can perform to make sure you are not falling into an ambition gap. One is simply to tap into the language of how you describe your product or service. Are you calling yourself a:

  • Next-gen something or other,
  • Uber (or other market leader) for X,
  • or a second or third player in X industry?

If you describe yourself that way, wake up and look for the missing smell of disruption. When people tell me how things occurred “in the day,” I usually want to run in the other direction. As Tony Soprano once reflected, “‘remember when’ is the lowest form of conversation.”

If Einstein were alive today, perhaps we would have come up with a general theory of technology inertia: Given the choice to do the same thing or to radically innovate, one is more likely to do the same thing.

Big bets present big risks. And big bets can yield big rewards. For those of us with clay on our feet, it is easy to feel inadequate when comparing oneself to Elon Musk, a man simultaneously changing three different industries — automotive, space flight and home energy. But at a time when our nation is making a rough transition to a post-industrial and globally integrated economy, we need more moon shots and fewer food-ordering apps.

We need practical solutions to a lot of problems, but we also need a level of aspiration that creates a broad range of self-actualization beyond quick hammer smashes. That is how we will create the industries of the future — and the economic and social benefits to follow.


from re/code, November 13, 2014

http://recode.net/2014/11/13/more-maslows-hierarchy-less-maslows-hammer/