Hacker News Reader

Hi, I wrote the blog post last week, and decided to publish it on Monday. https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

The title was chosen poorly, and the blog post did not reflect on its intentions. For that, I deeply apologize.

The experience and first time with Heroku is my raw impression, also the fact that I am a backend developer who is learning frontend and web apps.

It is a hard lesson learned today, although I am here for it. Iterate and improve, listen to feedback, and learn.

Sytse helps with his expertise and vision on the 5 minute production app, responding here to help. He is not to blame at all, I truly appreciate his guidance and thoughtful responses.

thanks @dnsmichi for taking responsibility quickly. personally, I think competition is what drives the web tech forward and I appreciate the openness gitlab brings to both the technology and the process you are using. The blog post process you have linked demonstrates this very well. Btw, I dig your flame emoji :-D

I hope they give you a nice bonus for trying to fall on the sword so honorably, but even if no one else read your post before you posted it then that's still a leadership failure, frankly.

I just want to say that I think most (If not all) of the vitriol is not directed towards you, but GitLab itself.

A guy linked a bunch of GitLab tickets in another comment showing that you went through the proper process and had multiple other people approve the post, so I think there wasn't much else you could personally do.

and now a retrospective with big point "hey, we made it to 1# on HN at least"... facepalm

I wrote that sentence and you took that completely out of context.

Here's the context if someone really does care: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

It's also important to note in a non-transparent company you wouldn't see any of this

> While the sentiment of the feedback was mostly negative for the reasons below, the fact is we were able to get to the top of Hacker News - something we attempted in a previous OKR but were not successful with. So while I agree that this might not have been the way to do that, I think we DID learn something about it, and that the "ideal" post is somewhere between "writing attention-grabbing titles" and "only publishing boring, technical, emotionless content."

So which is it, this was just one employee's personal opinion or this was an attempt to meet a company OKR? You can't have it both ways, and it's quite shitty to put your employees in a situation where if they're successful the company takes credit but if they're not they get thrown under the bus.

We attempted it in a previous OKR last quarter: https://gitlab.com/groups/gitlab-com/marketing/corporate_mar.... That's why I mentioned it in the past tense. This article was not part of that old OKR, you can see the issues that brought it up.

And the "we" there refers more to my team - the author of the post is on my team. GitLab OKRs start at the company level, but every team has their own that roll up: https://about.gitlab.com/company/okrs/.

The author wrote a blog post about a project GitLab is working on to shine more light on the work that is being done. While the tone and content of the post needed to be better, as we have acknowledged in both comments and changes to the post, we did receive feedback that can help us improve this project going forward.

We're also going to learn from this and improve how we write blog posts in the future, too.

To address your last point, I want to be clear that the author is a valued member of my team. His hard work has been recognized repeatedly in recent weeks in the form of awards and other recognition. This blog post will not change the high regard I, and his other colleagues, hold him in.

Everything you have seen today is our team living up to its values: the author's bias for action in publishing this post, the transparency and being quick to say sorry in how we responded and addressed this community's feedback, and how our team assumed positive intent and worked together to try to improve and learn from this situation.

You can read more about our values here: https://about.gitlab.com/handbook/values/

The comments are filled with GitLab employees, including your CEO, blaming the low quality of the post on it being "unfiltered", i.e. the employee's fault. If you value your employees, give them the tools they need to be successful, in this case an editor.

Hi,

> This was not a poor accident by a single employee. It's noble that the author tries to take all the blame on himself, but honestly, I feel like that is a moment where a leader has to step in and accept their mistake and not let a small trooper eat all the bullets.

The issues you have found are all assigned to me, or I created them. My task is to create blog posts, some of which being a hackathon and challenge. The KPI are impressions, other metrics are hard to measure. As a Developer Evangelist, I often need to learn new technologies, or dive into unknown areas connecting the dots.

You can learn more about our focus areas in our handbook: https://about.gitlab.com/handbook/marketing/community-relati...

I'm focussing on the Ops side, with a backend development background in the past 15 years. I was once a maintainer of an OSS monitoring project called Icinga, a Nagios fork back then. I decided to take on a new journey with becoming a Developer Evangelist in March 2020 (you can learn more on my website https://dnsmichi.at/about/ in case you're interested).

That being said, I've found it interesting to learn about web apps and their deployment, and dive into new things. Never having found a use case for trying Heroku, March brought up one: There was a Twitter theme of "Everyone is building a better Heroku" - https://twitter.com/adamhjk/status/1369704730218299392?s=27

From there, I thought of learning Heroku while comparing it with the 5 minute production app. I underestimated the challenge of creating a web app with a persistent backend, and decided to stick with the simple battleships demo I had initially found.

This state of the blog post felt good enough for me, and I did not include the persistent backend just yet, but moved it into a separate blog post. This is feedback I got during the review.

Turns out that this decision was wrong, next to other negative raw sentiments I had added in the blog post.

You can try to convince that it is not my fault, and I will convince you - it is, and I am standing up for it. Public and transparent.

I know we all get better from making mistakes. The lesson I learned today helped me improve a talk I gave at a meetup in my evening, it added technical insights as well as helped with the story line. That's the tracking issue: https://gitlab.com/gitlab-com/marketing/corporate_marketing/...

We will continue to iterate, and have a retrospective on what we can improve from the lessons learned today. Thanks for your feedback.