I recently became a Director of Engineering at a startup and one of my first official tasks was to revitalize the company’s very stale developer blog. I started thinking about what makes a good dev blog, and began writing up recommendations for what I thought the team should do. I got all the way through these and realized that I could have gone into nearly any startup and given this same advice. So, here is some advice on how to run your startup’s developer blog.

Mission Statement

Most likely, your startup’s dev blog has primarily been used as a tool for recruitment, and while that’s certainly still an objective, you’ll fare better if it isn’t the main focus. At it’s core, a developer blog should be written for developers and by developers about everything that goes into making and supporting a your infrastructure. A developer blog should be a blog that’s useful to developers. That’s it. Pretty simple.

As a recruitment platform, you need to demonstrate that you are a team worth joining. In order to demonstrate that you are a team worth joining, you need to look at what your goals are - both as a company and as an engineering department. What kind of people are you trying to attract? What kind of message are you trying to send? The company I’m at doesn’t seem to have those written up yet, but I honestly don’t think it matters. The standard answers to those questions are “smart, hardworking people.”

Are you a team worth joining?

What kinds of teams to developers want to join? With no scientific evidence and only a brief google search, but with 16 years as a working developer, I’m going to guess that most developers will say they want two things: 1) to work on cool shit with 2) people they enjoy being around. Often developers will add that they also want to work at a company that values and supports their development team.

You need to demonstrate that you have the company culture that supports developers. That you are a self-reflective team that is able to process your failures and adjust accordingly. That you are willing to work to deliver a quality product without burning out developers in the process.

And while we’re talking about culture…

It’s tempting to use your developer blog as a way to show people how “fun” it is to work at your startup. You have beer fridge and happy hours and cases of champagne scattered around the office after a company meeting. You need to separate development from drinking culture. Good developers may not drink, but even if they do, they may not have an interest in drinking with their coworkers. Shanley has an excellent write up of what your culture is really saying. Go read it. (This is also a good write up about drinking and exclusion in tech.)

The reality is that while you’re struggling to build something cool you spend a lot of time figuring out just how not to drown. Sometimes you survive by drinking beers while you’re doing a 3am push. It’s fine that it happens, but it shouldn’t be a common occurrence and most certainly should not be how you portray your team on your developer blog.

But How?!

It’s actually quite simple.

  1. Find things you can blog about
    Your team can probably come up with a bunch of things they can blog about. Your company/brand may have some things they don’t want discussed. You may have ideas about topics you’d like to investigate. Go forth and find ideas. If this is where you’re stuck, well, I don’t have any other help for you just yet.
  2. Put blog stories into your work tracker
    Pivotal Tracker, JIRA, ScrumSomethingSomething - whatever you use, make writing blog posts a point-worthy task that’s accomplished in a sprint just like any other.
  3. Publish
    And rejoice when you get to share things you’re learning and get feedback on things that you’re still uncovering.

What’s in it for me?!

You will benefit because doing this you will:

And the most self-serving reason of all: it will make you a better developer. If you’re not a developer and don’t care about any of those things, probably stop reading because I can’t help you just yet.

The reality is that much of the work you do is probably fairly standard development, so focus on the things that do make you unique - the approaches you take to solving problems, the things you do that don’t work, and the ways that you interact with your product and your process.

I believe that sharing your path as a technology team supporting a growing startup will contribute value to the broader “development blog” landscape and you’ll as demonstrate that you are a team that good developers want to join.

A Sustainable ‘Healthy Blog’ plan

Get each developer to write a blog about something they’re working on individually.

This can be difficult because not every developer goes home and hacks on things. The assumption that they do can be exclusionary (often people who don’t immediately fit into the “brogrammer” culture are excluded from this - people have family obligations that prevent them from leaving a job coding all day to go home and code all night). If they don’t work on side projects, encourage them to blog about something they’re learning at work.

If they’re not learning anything at work, you have bigger problems than stale content on your developer blog.

Each time there’s a sprint retrospective or project post-mortem, ask: “can you blog about this?”

If you’re not sure, here are some more questions you can ask:

  • Did you try something new that worked?
  • Did you try something new that didn’t work?
  • Did you stop doing something good or start doing something bad?
  • Did a team member take an action that impacted the rest of the team?
  • Did a major technology fail us? Why?
  • Did something completely unexpected happen that threw us off course?
  • Did you systematically deny a truth that would have made this project better?
  • Did you under- or over-estimate?

If you don’t answer yes to at least a few of those questions, you may have a development team full of automatons. Out of retrospectives and post-mortems come valuable insights about breakdown in process, changes that will improve workflow, and problems caused by technical short-sightedness. Give your developers a task to write up an overview or deep-dive of this for the blog. If it ends up filled with too much proprietary or otherwise private information, you’ve still won as a team because everyone can read it, and you’ve given a developer practice in distilling, organizing and presenting information. At worst, you’ve helped your developer grow. At best, you’ve done that and benefited your blog.

Keep a bucket list of possible blog topics.

New technology, hackathons, nuanced challenges, that list of steps from above - the more you start thinking “Can I write a blog about this?” the more you’ll find things to blog about, I promise.

Yes, but…

Yes, there is always “money” work to do. There are always projects that need attention. There is always technical debt that you could be paying off. Is having an active dev blog a worthwhile use of the business’s time? It is. Go back and re-read the “what’s in it for me section.” It’s going to be nearly impossible for developers not to benefit from involvement in this process. I read somewhere that developers can have three years of experience, or can have the same year three times. This is one way you can guarantee that your developers are growing.

And if you’re feeling altruistic, think about how you’re joining in a community of practice that’s larger than your functional or project team and that is going to enrich everyone’s experience.

tl;dr: If you want to recruit good engineers, don’t (just) post pictures of mimosas on your developer blog.

Did I miss anything? Tell me! @drnikki