Developer Advocacy and the Project Triangle

If you have been around software development long enough, or even just the business world in general, then you will likely have heard of the Project Triangle. This is the saying of: "Good, Fast, or Cheap. Pick two." It is unclear as to where this phrase originates, but it has been used in project management circles since at least the 1950s - and it applies to developer relations as well.

The Project Triangle

The general idea behind the project triangle goes something like:

• To get something done quickly, and with high quality, will be very costly
• To get something done quickly, and with low cost, means it will not be of great quality
• To get something of high quality, done at a low cost, will take a long time

There are a lot of humorous takes on this, usually depicted as a Venn diagram. Where the circles overlap is usually marked as "does not exist" or the likes.

When it comes to developer relations, the "something" is usually building community. Building community is generally viewed as a slow, and intentional process - the long game. It does not have to take a long time, but that means a shift in how the other two constants relate. Let us take a look at how these break down.

Fast and Good, Not Cheap

If you want to build a community quickly, and you want it to be a quality community - one in which you have a meaningful dialog with your customers - then it will not be cheap. While there are certainly a list of ways to spend that money, two specific scenarios I have seen in recent years come to mind.

The first scenario is to hire well-known talent (good, but not cheap) in the areas that you are looking for growth. As an example, these people might be well-known contributors on popular open source projects. Said people will most certainly come with their own community, which quickly (fast) gives you an audience of interested developers with which to dialog.

Another scenario might be to acquire (good, but not cheap) a company that has already built a community of its own. These developers will most certainly want to know what it is that you have planned for their favorite product(s) after the closing, giving you an open door to productive dialog (fast).

Fast and Cheap, Not Good

This is what I consider to be the marketing-heavy approach.

Social media gives just about anybody a massive megaphone through which to shout their message - or in the case of developer relations, about their product. A few dollars will go a long ways to boost search engine rankings. You might take a stab at a viral video, or project. Or maybe you just cross-link the heck out of a several dozen blog posts on different media outlets (channels). There are a myriad of [fast and cheap] approaches to take here.

Inevitably, some developers will hear your megaphone. Some may find your message compelling, and give your product a try. These developers however, will not generally be particularly invested in your offering (not good) - at least not at first. This means that having a dialog with them will be difficult, and that the feedback you receive will be just as shallow as your initial marketing blast.

That is not to say that this is a bad approach; indeed it is ideal for startups and smaller companies that cannot afford a dedicated developer relations staff. You do however have to be realistic about the resulting quality of community.

Good and Cheap, Not Quick

Developer relations does not have to be expensive (cheap), but building a quality dialog (good) with your customers will take time (not quick).

That time investment means more than hosting a monthly meetup, or speaking at the occasional event - it means building quality documentation, it means making sure the barrier to entry is as low as possible. It means putting the time into the quality of your product up front. It means hearing, and addressing every single piece of feedback, through every possible channel. And so much more.

Developers do not often have a lot of time to experiment with new technologies. This usually happens in what most companies call "10% time" which might mean a Friday afternoon (four hours of a forty-hour week is ten percent). If you have invested the time in your product (including documentation), then using it will be like magic. Problems that might have seemed too big for an afternoon, suddenly become child's play.

Congratulations, you are half-way there ...

Now comes the time to start a dialog with those developers entranced by the magic of your product. Eventually (not fast), a passionate (good) community will form.

A Friend in Need ...

I sometimes take issue with the term "developer" as used by most companies. The term can dehumanize the very real people spending valuable hours of their lives using your product. Regardless of the situation, do you like it when a company (or person) wastes your time? Same difference.

I like to think of developer communities as my friends - after all, it is only in that setting where I can truly get my geek on, and in which we can have an open exchange of ideas. I would never intentionally waste the time of a friend. To that end, how good can a friendship be if ...

• You spend your lunch hour together every day at the finest restaurant in town?
• You buy them a Happy Meal at McDonald's once a month?
• You share a bag of granola while spending the weekend on a hiking trip?

Further yet, how does one even quantify a friendship? Can you say that Bob is worth $10 but Linda is worth $100? Answering "yes" to this question is where many companies go wrong with developer relations. If you commit to these types of quantifications, then you have just turned a relationship into a number, and taken a sharp turn into the world of sales.

Back to that Triangle Thing ...

To be sure, none of this is quite as cut and dry as we might like it to be. Sometimes you may find yourself spending more time on product, and other times on marketing blasts. At other times, you may look into acquisition. Each of these are integral parts of doing business, but it is important to recognize that each comes with trade-offs - even in developer relations.