As I’ve explained in previous blog posts, I come to marketing not from a traditional marketing background, but from product development and engineering. When I first showed up in marketing, I was as baffled as many of you might be by all the different roles in B2B marketing, and wish I’d had a primer to explain what all the different roles in marketing are.
This is that document. I hope it’s a handy guide for folks outside of the marketing department who need to interact with it. It’s also helpful for startups to understand what kinds of marketing they need right now and what types of people they should be interviewing.
The Dark language and coding platform launched this week, and I couldn’t be more excited. (I had half a mind to fly to St. Louis and see them launch in person at StrangeLoop.) For a while, I’ve been following what Paul Biggar (founder of CircleCI) and Ellen Chisa (a product leader whom I respect) have been building in Dark: a product to democratize software development and make it easier for everyone, particularly for folks who haven’t previously coded before. The frustration Paul expresses in his launch video –- about infrastructure and today’s delivery process getting in the way of delivering code – resonated deeply, particularly when I think about how we used to “deploy” in the early days of web software engineering (FTP-ing PHP files to production). Obviously, that was risky.
Today, however, in the name of risk reduction, we have complicated CI/CD pipelines, Kubernetes and rolling deploys, thousands of lines of AWS CloudFormation and Chaos Monkey to kill it all, and a million other extraneous guardrails that developers today need to learn just to get something into production. An end-to-end, low-friction developer experience such as what Dark is providing is certainly appealing, not just for new developers, but for old folks like me who would like to program again occasionally but find today’s frontend and backend stacks daunting.
In this post, I’d like to give my thoughts in just three
areas: what did Ellen and Paul and their team build? In what way could they
reasonably go to market? And also – to address some of the early criticism
about Dark, e.g. that it’s a closed ecosystem and not open source – does it
matter? Are there are other valid criticisms and how could they overcome them?
Yesterday was my last day at Chef Software. It is the second-longest I have been at any company — nearly six years. I have been very fortunate to have held four very distinct positions at Chef over my time there: professional services consultant, engineering manager, product manager, and finally, product marketing manager. When I contrast my experience working for a startup with the time I spent in the enterprise, I would, without question, state that this has been a better experience for me both personally and professionally. I could not go back to work for a huge company where the sense of urgency and determination to succeed are just not there, and where the needless bureaucracy snuffs out the flames of innovation before they have a chance to catch. I’m sure there are exceptions out there, but when I think about the poor customer experiences we all have interacting with our bank, college, grocery store, or health care providers, those are fundamentally a direct result of company-wide complacency driven by sheer size and corresponding market dominance.
It is also the first time for me leaving a company because I outgrew it — or maybe it outgrew me. In tech, we love to dump on the 99.99% of companies that aren’t Hacker News Hot Shit ™ while neglecting that many of them are doing quite well financially, thank you very much, and solving real customer problems. While the HN crowd is busy chasing shiny objects, the rest of us are off building businesses, and extremely successful ones at that. For me, though, there wasn’t much more I could do or wanted to do at Chef. The company is at a phase of its growth that is about immensely scaling the products it already has and deriving revenue from them, rather than launching entirely new product lines. As a product guy and engineer at heart, it’s therefore time for me to move along.
I wish my colleagues at Chef a great deal of success in the next phase of the company’s growth. It has been a privilege and an honor to have worked alongside so many of you and to have learned so much.
This past weekend I had the opportunity to attend the XOXO Festival right here in Portland. For those who don’t know about XOXO (as I didn’t before I moved here last year) it’s a festival and conference for and by makers of things on the Internet: game designers/developers, programmers, filmmakers, comedians, artists, podcasters, and the like. A single-track daytime conference accompanies the evening festivities, packed with thought-provoking keynotes delivered by very accomplished people such as Jonny Sun, Ijeoma Oluo and Demi Adejuyigbe. It’s primarily this part of the event that I want to say a few words about. Continue reading
Over the last couple of weeks, many open-source luminaries have written about open-source business models in response to Redis Labs’ modification of their license terms for some Redis Modules. Most of these blog posts dissect one thing: how does one create a business around open source? I actually think that this question, framed as it is, is kind of absurd. It sounds to me a lot like “how do we make money off the horses which have already fled the barn through the doors we left open?” Starting a company off on the wrong foot by giving away all of your valuable IP – and then figuring out how to build commercial products on top of whatever scraps of value remain – is silly. Many such conversations – led by technologists — start first with open-source zealotry and reverse into a business model which is the wrong way to do things. Instead, if you’re considering building a company based around an open-source foundation, first design the business model, and then contemplate how open sourcing certain pieces can serve as an accelerant to that business. If you can’t find an accelerant, maybe your business shouldn’t be based on your IP being open source. Continue reading
One of the biggest news events in 2017 for those of us working in devops was hearing about abrupt changes at Etsy. In April, institutional shareholders, disappointed by Etsy’s low share price, ousted CEO Chad Dickerson, and under new CEO Josh Silverman, proceeded to slash the workforce and reduce costs. Many talented engineers that I happen to know personally as well as CTO John Allspaw himself were either fired or saw the writing on the wall and made for the exits.
These events were discouraging on a number of levels. First, Etsy’s world-class engineering and web operations team scattered to the winds. Allspaw and many others contributed a great deal to the discipline of web operations by applying lessons learned from improving reliability in other fields, such as transportation engineering and nuclear safety. More importantly, though, is that Etsy’s very existence shone a light on whether it’s possible to build a socially-responsible company within the constructs of the current venture capital, and by extension, capitalist system. What is the place of the social democratic entrepreneur within these confines? Continue reading
Back in June, Chef launched Habitat, the product that I’ve been working full-time on since fall 2015. Habitat is a system for building and running applications in a way that makes them portable across a wide range of infrastructure platforms, anything from bare metal and virtual machines all the way up to PaaS and containers. Along the way, you get clustering, secrets management, service discovery, runtime configuration injection, and a whole host of other features for free. You can learn more about Habitat at habitat.sh.
Today, I’d like to spend a moment and talk about Habitat’s user experience design, and specifically, how we put a great deal of thought into making the command-line UX awesome. Continue reading
South Beach. CC-BY-NC, by Thomas Hawk – https://www.flickr.com/photos/thomashawk
A couple of weeks ago, Mathias Meyer wrote an article entitled “From Open (Unlimited) to Minimum Vacation Policy“, detailing how his company, Travis CI, has moved from away from an “unlimited” vacation policy. Mathias found that the dangers of unlimited vacation policies were coming true: Engineers weren’t taking any or enough vacation to avoid burning out. So, he decided to move Travis to a model where a minimum amount of vacation is required. Sounds great, but doesn’t it seem like we’re right back where we started? Isn’t this just a traditional vacation policy couched in different terms? And what was so bad about traditional vacation policies, anyway? Continue reading
A couple of weeks ago I finished reading Tracy Kidder’s 1981 Pulitzer Prize-winning book, The Soul of a New Machine, in which he followed Data General (DG) engineers around for over a year while they tried to pull a miracle minicomputer, codenamed “Eagle”, out of the company. The firm’s survival was on the line. They were being slaughtered by Digital Equipment Corporation’s VAX 11/780 and they needed a winner, badly.
DG’s “new machine” ultimately became the Eclipse MV/8000, a name that, like the CDC 6600, is nearly unrecognizable to anyone today besides old computer nerds like myself. In other words, it’s damn hard to build a company that lasts. Both DG and its main rival, DEC, are gone, shoved aside by the PC revolution and the march towards inexpensive, x86-based servers running Linux. And so if you work in technology, you probably feel (or should feel) an immense sense of urgency, because there is always a surplus of discontinuous innovations just around the corner to disrupt whatever you’re working on right this instant. And those disruptors will in turn be disrupted by others, and then by yet others… Continue reading
This is another in a series of reviews on management & leadership books that I’m doing on the blog.
Last week I finally sat down and read Jim Collins’s Good to Great: Why Some Companies Make the Leap… and Others Don’t. Obviously, at Chef we’re trying to build a great company, and I thought this book would show us a way forward.
Good to Great was written in 2001, so you might be wondering why it’s taken me 13 years to crack it open. Well, quite honestly, I once had a co-worker and friend who was given this book upon starting a new job, and he scoffed at it. In retrospect, I think he did so because it was obvious that his employer was most definitely not on the path to greatness. The notion that handing out copies of a business book could fix their dysfunctional culture & failure to execute is laughable. It’s about as useful as giving anti-drug pamphlets to a meth user. In any case, I associated his mockery with the conclusion that the book is bad, which it most definitely is not. Continue reading