Coté

Advice for being an industry analyst

Occasionally, my fellow analysts ask me for advice on being an analyst. Here’s an edited up version of one of my recent emails:

Learn how to listen to yourself, focus

You have to learn to trust your intuition about what you focus on, your own style and voice, and, most importantly for monetization, how you market yourselves. The last point is important for commercial success: in most cases, the (analyst) company you work for will do a poor job marketing you compared to how well you can market yourself.

The first points are on the core parts of being an analyst: deciding what to focus on. While you may proofer opinions about “everything,” it’s good to have a stable of things you really focus on. You’ll need this when it comes to getting things done: you need a way of deciding what to cover, there’ll be no end of offers and topics that people want help on once you’re mildly known, and you need focus. Commercially it’s good to have focus as well. It’s easier to market yourself as a specialist and close deals on that than a generalist.

Try new things without asking

The other thing I would do - depending on your relationship with your boss and management chain - is stop asking permission for anything. Since “publishing” and onion-mongering is so freewheeling and basically “zero cost” now-a-days, you have to go out there and try new ways of publishing all the time. It’s like the advice us analysts give business: stuff is changing so fast, you have to adopt and use new technologies or die! The same applies to analysts, and yet we’ve got Cobbler’s Shoes Syndrome (we experiment very little).

Just do things that seem like they will help to first promote your personal brand (and therefore “worth”) and second bring in a profit to your firm. As a self-serving example, though small, pretty early on I just started uploading presentations and “brochure” stuff to my SlideShare and, of course, my blog. Several engagements were driven by this, and it also gave me URLs to send to people. Before doing this, I’d been sitting on my thumbs waiting to hear back about getting permission to do this…and then I just started doing it. Think a podcast would help? Just start one! And so forth.

And, on the second point (bringing in profit to your firm): all the motivational crap for net-heads like us focuses too much on the building a personal brand, doing what you love, and whatnot; you have to remember to bring in money to your employer. Your firm will notice you bringing in revenue (and esp. profit!) and clients above all else; they’re a business, not a charity, and that’s what they care about.

Don’t work too hard impressing your manager, impress their manager

To that end - to give general work advice - make sure you have as good a relationship with your boss’ boss (your “second line” manager). This is good for any company, and applies to analyst work, especially where it’s easy for management to lose track of analysts (they have a company to run and can’t keep up with everything you publish - I know! Weird, huh?).

Your second line manager is the one who approves and hands out bonuses, promotions, arbitrates disputes, etc., with minimal input from your actual manager, in general. Analysts shops tend to organize along a taxonomy instead of being flat (I know, weird, huh?) so the individual analysts get lost in the upside-down tree. You, then, have to do the work to establish a relationship with the management chain above you. There are no immediate benefits, but it’s good “credit” to build up. Ask for a 1:1 meeting every two weeks or at least once a month. Just to discuss ideas, what you’re up to, and ask him what you can do to help.

As my snide aside above indicates, most analyst shops are hopelessly behind on using IT on their own. Make a bar-chart of knowledge of “Slack” vs. “SharePoint 2008” and see what it looks like. One thing you can impress (or “be known for”) the management chain with is always suggesting new tools; more than just pointing to them, explaining what they are and why they will improve the company. You know, being an analyst to the analysts.

This isn’t marriage, so date frequently

I would also force yourself to causally interview, if not formally, for new jobs at least twice a year to get a sense of what’s out there, who’d be interested, your worth (do people know you? Are they interested in hiring you?), etc. Interview at other analyst shops for sure - you’ll get a peek into how they operate that will be useful - and non-analyst companies. I find that I can only work at my current job confidently if I know I can get another job easily. Plus, you want to avoid being isolated and only understand the labor market through your current employer’s.

No one really knows what they’re doing

I’ve been an analyst, now, for almost eight years of my ~17 years working. I was (very!) lucky to be hired by RedMonk who taught me near everything I know about being an analyst, and then work in strategy/M&A at Dell which taught me a lot more. I learn new things all the time at my current job at 451 Research. There’s not really a good manual or understood practices for doing analyst work. The issue, once again, is that things are changing fast so new methods are constantly needed.

The analysts I admire don’t really “reinvent” themselves constantly - that’s madness - but they’re consistent in three primary skills:

  1. Learning and understanding, driving towards forming an opinion about the topic/technology at hand. They stay curious and will tell you what they think. Part of this is being honest about what they don’t know. If you never hear an analyst say the phrase “I don’t know,” something is probably wrong with them.
  2. Succinctly communicating and “explaining” what they’ve learned. This can be quantitative (think charts and spreadsheets) or qualitative (think prose and speeches), or in the best, both.
  3. Promoting themselves. I could dress this up in some fancy language that made it seem like less than self-promotion, but that’s what’s needed. It is less annoying “branding” and more controlling the flow of attention to yourself and, thus, driving work and monetization. Like a VC, an analyst needs to develop “deal flow” - the analyst requires a flow of information, prospects, and knowledge coming in through their network. Unless you build up and garden your own “brand,” you won’t get that as good as you need it.

On the last point: an analyst company is always going to be less interested in creating “stars.” Instead, the company wants to make a star out of its brand. This is understandable, and just fine for them (you would act the same way if you were management whose goal is to grow the value of the company, not the individuals in the company). Thus, for you, the individual analyst, you have to learn how to take care of yourself first and accept that no one is better positioned to do so than…yourself.

Don’t be a screwball

As one final piece of advice, so as not to make you into a psychotic spewer of self-promotional filth always busting up the china shop, figure out where “the line” is when it comes to behavior and activities in your firm. Who are people in your firm that have bad reputations “in front of clients” or are generally thought of as screwballs? So long as you’re operating in the company, try not to be like them, walk right up to the line of acceptability, but don’t cross it.

(For view from a different perspective, check out my recent update to “How to deal with industry analysts” talk.)

Selling to Hoodie and the Sticker-Festooned - Building a Developer Relations Program to Win Over Developers as Paying Customers

I’m just about the give a short presentation on developer relations and marketing at our HCTS conference. For those who didn’t make it, here’re the slides and the “script” I typed out. As you may recall, I wrote a large report on this topic published back in August. It’s been fun talking with people about over recent months.

Lost presentation: Selling to Hoodie and the Sticker-Festooned - Building a Developer Relations Program to Win Over Developers as Paying Customers

I often type out a “script” for presentations, not something I actually read, but just something to figure out what to say. Here’s the script for this one:

HCTS Developers

Hello, I head up the infrastructure software team at 451. Part of that is focusing on software development, developers. Back when I did real work, I was a programmer for a decade, so to me, the old saw applies: the answer is developers, what was the question?

Slide 2

More seriously, if you study the IT industry as I do, you notice a common trend: developers seem to gravitate around successful vendors and platforms. Sure, there’s a chicken and egg, cause/coorelation issue, but if we look at some big names, it’s obvious that having the good graces and favors of developers is key to making money in for many technology companies.

In the 90s and 2000s, Microsoft’s was a developer powerhouse, and still is, with countless applications written on its platforms. AWS rose to prominence rapidly from nowhere largely fueled by developers desire to run application on their platform. Similarly, Softlayer (now owned by IBM), expertly targeted developers as a core constituency. And, of course, there’s Apple, which is really cheating as an analyst to use as proof of anything.

We’ll get to some lesser known examples, but the message here is clear: developers matter a lot in the technology world and learning how to “market” to them is key for many vendors in this space. That’s what this talk is about: how to market to developers.

Slide 3

Now, as much as I like to be hyperbolic and categorical, not all technology companies need to worry too much about developers. Aside from the obvious cases - you’re selling middleware, IaaS, or PaaS - there’s an interesting heuristic to use to figure out if developers matter to you. As this timeline from Geva Perry shows, the role of developers in IT buying has been enabled by friction removal in the IT procurement cycle. If I have to go through months of fancy steak dinners and procurement paperwork, developers will have less of a role. If I can just download a database, install it in the public cloud, and go, there’s virtually no friction…and developers will more and more be the primary movers for IT procurement decisions.

Again, metered IaaS is an obvious match, and PaaS, of course. Look at your go-to-market - really map out each step it takes from concept to quote to cash - and see how much friction there is. The less friction, the more likely developers will be an important constituency.

Slide 4

Here’s two examples of that Heuristic at work: DigitalOcean and Atlassian.

DigitalOcean is one of the handful of SSD-fueled cloud providers out there that developers are flocking to. They do excellent product and developer marketing. Just like there’s less friction when you remove spinning dishes, the IaaS nature of getting to a blinking cursor in minutes to near frictionless. Developers love the easy performance boost SSD brings and the love how easy it is to sign up. As our recent reports on them show, this has resulted in 30% m/m growth and rocketed DigitialOcean to the 5th largest hosting company in the world according to Netcraft.

Atlassian is another example. They’ve been at it for years, putting out developer tools (requirements tracking, version control, etc.). They’re famous for having “no sales” and instead have removed so much friction from their GTM that developers can easily get their tools. And the tools are good. As you can see, Atlassian has been able to grow revenue from $59m in 2010 to $149m in 2013. That’s amazing consider that, you know, “developers don’t pay for anything.”

Both of these companies are good at developer relations and marketing and have harnessed developers to grow revenue. Let’s look at some highlights from my recent report going over tactics.

Slide 5

First, let’s define the goal of developer relations and marketing. I borrow this idea from several folks in the field, and it’s that you want to establish your technology as the de facto standard. Think Windows, HTML, Linux, the LAMP stack, the iPhone. Each of these became one of the top short-list choices for developers. Not all of them were “industry standads,” or even the #1 in the market, but they became de factor standards.

The result is that developers do all these activities in my Smart Art here:

  • they consider using your technology
  • they try it out
  • if they like it, they word of mouth it
  • they’ll purchase it (if it’s available to buy)
  • and they’ll use it

This is pretty classic stuff, but the point is focus your goals around establishing your technology as the de facto standard. You can do other things, but it’ll be more difficult: you’ll have to convince people that your “exotic” thing is needed, like high-end Unix boxes vs. Linux and Windows.

Slide 6:

How do you do this? A lot of hard work and time. Really. There are no simple solutions. As analysts marketers ask us for the quick wins a lot - esp. towards the end of the quarter and year ;)

To give you a sense of what a developer marketing program will look like, here’s some examples.

  • You’ll do classic things like advertising
  • You’ll provide white-paper level research to help developer understand and evaluate your offering
  • Training is a large part of developer relations, and also a revenue opportunity: you’re indoctrinating people
  • You’ll also need to understand developers needs. Right now, that has a lot to do with APIs and documentation for how to use them. APIs are becoming the de facto standard for how developers interact with platforms, and you’d better figure out your plan there. You’d think docs were obvious, but it’s shocking how often vendors miss this.
  • At the code level, developer marketing is also often done in code. I call that “code as marketing.” You might source extenstion, do some biz-dev to get others to do it, or lucky enough that your community can do so.
  • And there’s lots of publishing. Lots. The Internet is the primary channel to reach developers and stuffing that channel is all about content.

Staffing wise, this could be a partially dedicated person, but pretty quickly you’ll want someone fully dedicated who can keep all the threads going in their head. Also, they’ll start to establish a personal brand, credibility in the space. Developers actually like people, just developer-y people.

The team can obviously grow. SAP’s team is massive, and it has massive effect.

Slide 7

So, you’ve got a notion for what it looks like. How do you plan what to do?

Don’t just throw up a blog an start typing. Take some time to plan. Get some ice-tea and patinad table like these hipsters here and establish goals.

And don’t forget that you’re doing this for business reasons. Talk with sales to find out how you can help them with deal flow and closing. Talk with product management to see how you can be a bi-directional channel for driving product direction.

Know what you want to accomplish with your developer marketing program so you can measure and meter funding. Once you have the developer in hand, you need to pass them off to someone who can make money from them.

Obviously, you need to establish metrics so you can track progress and argue for more budget and corporate oxygen. I find that most people rarely base-line current performance how they’re currently doing before starting a new project, so that’s a good start: otherwise how do you know if it’s working or failing?

Finally, make sure you understand who “your” developers are. One off project lone wolves in coffee shops, startups, other vendors, enterprise developers? It drives what comes next.

Slide 8

So, what appeals to developers? It of course depends on how long their beard is.

More seriously, while there’s different types of developers, there are some core value props that usually work.

Developers like speed. They want to do more with less, they want things to compile quicker.

Many of them (not all!) want to try out new technologies. Their worth is all locked up in their head, so each time they learn something new, they become more valuable. Any many of them just like learning.

To that end, they like stability in their knowledge. It takes a long time to learn Java or node. They want the investment to pay off. Don’t be changing things around all the time.

They like solving riddles and puzzles. That’s what programming is, what tends to separate it from more “factory” like work.

The business side is simple: someone else comes up developers and tells them the requirements, what the code must do. This is where a lot of “enterprise grade” features come in like compliance, audit, and regulations. Developers generally don’t care about that, but they like satisfying the requirements.

And, while they may act - and dress - like they care, they care a great deal about getting paid. Those 128 gig iPhone 6 Pluses don’t pay for themselves. Developers rank themselves by pay like any one else. Money means freedom to developers, like most people.

Slide 9

Let’s close out by highlighting a few tactics from the report.

First, show up! Developers are very social, esp. online. There are numerous “communities” that they rely on for their work and entertainment. GitHub is popular, Hacker News, Stackoverflow, and numerous other sites. Large developer marketing programs like SAP even setup their own, highly successful communities.

We did a survey of the early mainstream DevOps market recently and found some interesting results there. Obviously we like the analyst reviews, but it also shows that “traditional” outlets are valuable to.

Find where developers are and go there.

Slide 10

So, when you show up, what’s the work product?

Content can take many forms. Blog posts are good, podcasts can work for certain types of developers if done right.

And look at everything as a “store front”: support forms, your docs, demos, and other “marketing material.” All of this, if tracked and experimented with properly is can the ether your developer marketing program flits about in.

Books can be oddly effective if you write one that’s a definitive “how to” of a narrow topic. I profile one on code reviewing that helped drive growth for SmartBear before it was acquired.

Presentations, webinars, and talks are always good as well. Check out what goes on daily at InfoQ. It’s documenting the tribal knowledge out there, which is incredibly valuable in a knowledge economy like developers.

Slide 11

Here’s some specific topic ideas, all of them good.

Let me highlight one, a wicked problem solved.

Back in 2012 when Thailand was flodded, Backblaze had a problem getting cheap hard-drives from its supplier. So they arranged employees to travel around the bay area and beyond to buy hard drives at CostCos and Best Buys. Developers loved this story. It’s a classic puzzle to solve in an almost subversive way. I know many, many developers who love and use Backblze.

Stories like this come out from other companies.

Also key is explaining your “philosophy” on the industry and even culture. To go back many years, as it was called then “37 Signals” used their philosophy of rebelling against Enterprise Java to help advance the adoption of rails and their own products.

Slide 12

So, other than reading my full report and doing crazy amounts of consulting with me, what are some tangible next steps?

  • Understand how developers will drive revenue and growth. How do they fit into your value chain?
  • Figure out who these developers are. There’s probably at least three types, if not more. Know them, and how long their beards are. And then go talk to them!
  • Start with some cheap experiments. Have a beer and write-up what you think is wrong with how things are done; record a screen-cast of an obscure feature in your platform; rise-wash-repeat. Just do something!
  • As you learn what works, get a regular cadence for content production. Blog posts, podcasts, docs, code, whatever works.
  • Finally, never forget that your job is to move product. Engage with sales and product folks to fit into their pipelines and process. If you round up all this developer favor, how do you deliver that into your companies money makers?

Slide 13

So, that’s a really quick overview. If you like reading, there’s a full report on the topic available. There’s a lot more in there like:

  • types of developers
  • the role conferences play
  • more on different channels and mediums, topic ideas and content
  • and several large and mini-case studies of what’s been successful at for other companies.

Speaking of case studies, we’ve put together a panel of folks who’ve been successful at developer marketing and relations and we’re going to debrief them now to help you understand developers more.

The great OpenStack conundrum: with 15,000 members, why is adoption lagging?

This is the common OpenStack meme for coverage. Each Summit there’s more and more users - “customers” - but it will take a while before OpenStack is suddenly us an “overnight success.”

Looking at it from a different perspective, OpenStack is one of the biggest, new model for open source development: they’re iterating on the concept and mechanics of open source in new and novel ways, deep in bazaar mode vs. Fred Brook’s surgeon model, to mix metaphors and ages.

I think it’s best to think of OpenStack as a continuation of the Eclipse model, that isn’t really too explicit about it: the point of the overall effort is to provide and commoditize all the common components needed to make cloud software. The vendors - be try ISVs, service providers, or SIs - who take those common components make most of “the real” products (not all, of course). If there happens to be a fully functional cloud platform as a result apart from vendors, even better.

What’s incorrect in my comparison is that this doesn’t seem to be the explicit mission of the community. Indeed, I think holding back from a strong mission like that is intentional: and that’s where the OpenStack is more like the ASF. Unlike the ASF, the OpenStack community isn’t opposed to profit and business; those ASF guys seems allergic to it (which maps to their mission perfectly well).

Hence, it’s all sort of new. I don’t really know what “The Model” is yet.

See also Nancy’s piece on the meme.

The great OpenStack conundrum: with 15,000 members, why is adoption lagging?

Press Release Quotes

As an analyst, you often gets asked and paid to provide press release quotes (see some of mine here, though the I haven’t been good at saving all of them). Yes, press releases are still widely done and used. As someone who write-up the tech world happenings, I actually find them handy. Knowing how a vendor talks about themselves is actually important for analyst work, and the good press releases are more like media kits that line up all the relevant facts and links to other sources…and there’s all the bad stuff too, that’s still floating around.

So, as an analyst, how do I do press release quotes?

In general (meaning I don’t always do this) I try not to reference the vendor in my press release quotes. Instead, if I believe it to be the case, I try to follow a format that points out the problem the vendor is solving and then say something along the lines of “there’s clearly market desire for products that address this problem” type of thing. However, if I truly believe that the product/vendor in question is somehow awesome (and, esp. if they have a track record) I’ll reference them directly.

Put another way: I try to make most of my press release quotes into just validating the problem the vendor is working on, and, if real, that there’s market potential there.

(And, yes, if the news, vendor, etc. in particular is BS, I don’t just stand there and say “this BS is awesome!” That can be a tricky situation.)

@cote@hachyderm.io, @cote@cote.io, @cote, https://proven.lol/a60da7, @cote@social.lol