Fifty-Two.

That's how many articles DealerOn has published in the last 12 months. One article every week. When this project started, DealerOn had been wanting to get more involved in the tech community and provide some of their thoughts and insight on the various technical problems and challenges they've faced, along with giving everyone involved a few more excuses to learn something new and share that knowledge. At the core, the DealerOn blog arose out of a desire to grow, not only our public footprint and roots in the tech community, but ourselves as well. I've learned a great many things in this past year and my career has changed shape substantially beyond the "Engineer" role (hat number 1) as part of this growth.

One year ago this week, our first article was published, "Why car lovers make great software engineers" by our very own Tim Kaetzel (whose own career has changed dramatically in that same twelve months, but that's a story I'll let him tell). The article was long overdue, as we had been itching to start our blog for a very long time, but no one was ever able to quite make it a high enough priority to see it through. After the 4th retro in a row where Justin "You're Welcome" Thomas put "Blog" at the top of our "What we can improve" column during our monthly team retro, Kaetzel, Eisenhardt, and myself decided to finally do something about it.

The first problem: Getting Started

Kaetzel volunteered to write the first article, I would take the second, and Tim would help as an editor/reviewer/road-block destroyer for the time. That gave me time to look into hosting options and figuring out all of the other minutia involved with starting (and more importantly, running) a blog (unofficial hat number 2). In the end, we settled on Medium as our initial hosting platform. As you can tell, since you're likely reading this on Dev.To, our plans have since changed, but I'll get to that in a moment.

We chose Medium initially due to the huge initial barriers it removed in the published blog format. It gave a very nice paradigm of "publications" where authors could contribute articles and editors could approve them, make corrections, and publish them on a schedule. It was great and worked well for our work flow. We could queue up a few articles in the down time between other major work we were doing which provided a nice buffer for when certain tasks became more complicated than we expected.

The second major thing that made Medium a great initial choice was the syndication. Medium would push our articles out to people that were interested in the topics we wrote about. Boom! Instant market share. It was a great way to get started and to get our content out in front of the people that would be most interested in it without requiring substantial marketing effort on our end, which isn't something we had a ton of time to spend on. We were essentially operating the blog as a skunk-works project in between all of the other regular commitments and expectations. This is the key point that lead to some of the substantial career changes I mentioned earlier.

Over time, Medium rolled out various changes to their business model, some of which we didn't agree with, and some which seemed more user-hostile than we were willing to accept. No longer would our articles be sent out to users that were interested in our kind of content without us allowing the articles to be part of the Medium paywall, meaning readers would no longer be able to read our content for free, which was our goal. There wasn't even an option for us to pay instead of the readers. Due to these changes, along with a lack of features we were looking for in regards to sharing code (Medium's Gist support is terrible), I began looking for another hosting provider.

As you can tell, I landed on Dev.To and so far it has been great, the features available much more align with our needed feature set, and the best part is that if there's a feature we really need that doesn't exist, we can contribute to it. Dev.To has been a great home and lead to more directed feedback and communication with some of our readers.

The second problem: Getting content

The second major hurdle we would encounter on our journey to blog-dom was finding content. We have an ample group of very talented and capable engineers, but I've learned over the last year that getting that knowledge out of their brains is a hundred times more difficult than getting it in there.

Everyone hits that initial barrier of "I'm not a writer", and that brings me to my first lesson, and something I find my self needing to repeat to everyone participating in the DealerOn blog from time to time:

Everyone is a writer

No matter your skill level, there's always someone that can stumble across your content that is learning that technology for the very first time today. You may be the inspiration that keeps them on the path of development when they're having doubts. You can be the voice of encouragement cheering them on, showcasing that "I too, had trouble learning this, here's what finally helped". Everyone, and I do mean everyone, has something to share. The best way to get started is to just begin writing. I find "Stream of Consciousness" writing to be a great starting point as it gets your mind into the right state after a few paragraphs of "I don't know what to write. This is so stupid. I feel like an idiot just sitting here talking to myself like this". I find it very similar to Rubber Duck Debugging, something that most of us have found helpful at some point or another. If you get stuck getting started, talk it out with someone. Just getting the words out of your head can help you substantially for figuring out how they fit into the picture you're painting.

Everyone needs encouragement

Along with people having trouble starting an article, they often times have trouble finishing. They'll get a few paragraphs in and get discouraged, thinking their style is terrible or that there's nothing interesting there. That's where my job comes in. I'm the editor for every article that is published, which means I'm reading several articles a week to help with spelling, grammar, forming thoughts, and providing ideas when our authors get stuck. Everyone can use a little encouragement from time to time.

Keeping to a schedule is tough

I thought it would be easy when we started this. I thought I was clever by giving everyone a "due date" that was two weeks prior to when I planned to publish their articles. That should have given enough time for them to remember the due date last minute, write the article, and have it ready a few days late so I could review it in time for publishing. That worked well enough for a few weeks, but they quickly caught on, and we quickly entered into an article deficit. Thankfully, I've had some amazing colleagues that seem to love writing and have no end of inspiration, so they have saved my bacon more than a few times by popping up at the last minute with a "hey, I was bored, so here's three articles I wrote last night". I started out with a schedule planned about 2 months out at a time, assigning articles to specific people that I thought would have something interesting to write about, or people that expressed interest in writing something. "Interest" and "Available time" rarely coincide. I eventually shifted to a "team-based" approach instead of individual people so that each team could prioritize and figure out among themselves who would have the time and interest in producing an article. So far that's worked out fairly well, and now every team knows they have an article due every 6 weeks. As we grow and add teams, that gap will grow accordingly.

It became clear to me that with all of these substantial time sinks of problems related to running a blog, this wasn't something we could continue to manage as a skunk-works project. I spoke to my manager about finding a way to make this "official" and part of my regular job responsibilities so I didn't feel like I was sneaking around to do this all the time, especially when it was clearly something we wanted to do as a team. We sat down and detailed all of the "non-engineer" things I had taken on as day to day tasks and we established a new suffix that can be applied to titles to indicate a non-insignificant portion of their day to day will be spend on non-engineer related tasks. That took effect for me officially at the beginning of the year, about 3 months into our blog's life. Enter official hat number 2.

With the suffix of "Developer Advocate" officially tacked on to me, I was able to spend more time planning and structuring out the blog without feeling guilty about it. (Other initiatives like GreenLight, "Tokens of Appreciation", OSS Policy, and others fell under that umbrella now too.) This lead to the changes I mentioned earlier like switching platforms and being able to set an official publication schedule.

This leads me to lesson number 4:

For anything to work, it requires higher-up buy in

Even though we now had regularly scheduled articles and had managed to publish an article every Friday since we established that's what we wanted to do, my authors were still feeling stressed out about their articles and being able to work on them during normal business time (something I was adamant about, along with each author receiving credit for their work and not publishing it under a "DealerOn" group pseudonym). The problem was that even though we were creating tickets in our normal work system for these items so time could be estimated and tracked right along with all the other items in a sprint, they didn't feel like they were actually allowed to. They needed reassurance from higher up that yes, this has been approved and you are allowed to do it. The Development Managers and I worked together to increase the transparency of the message and make sure that everyone knows they're allowed to work on these.

Through a recent team adjustment into more domain focused teams (effectively, more scrum-ish groups, through which I gained another temporary hat of team lead), it will be easier to accommodate this work as part of the normal expectations from a team, and with the endorsement from on high, everyone knows that they are able to, allowed, and encouraged to work on their articles during work hours. It's not extra work, it's a different type of normal work. Of all the lessons learned this year, this is the largest that I wish I had picked up on earlier. I've caused a lot of undue stress and headaches for everyone involved by not ensuring it was explicitly clear and known by all parties involved (Devs, Managers, PMs, etc) that teams had this other work expectations as well.

All in all, it's been a great year. We've published a ton of articles on a steady schedule right out of the gate, a cadence many did not expect us to be able to keep (and most of which we've managed to port over to Dev.To). We learned so much along the way and sparked that writing spirit in a number of our teammates. In the end, without the amazing determination of everyone involved in this project, we would not have been able to make it to today. We have one year under out belts now, and I'm looking forward to the ones ahead.

Thank you team, this wouldn't have been possible without you all.