diff --git a/_posts/2023-03-10-things-to-bring-back.md b/_posts/2023-03-10-things-to-bring-back.md
new file mode 100644
index 000000000..4bb3766a6
--- /dev/null
+++ b/_posts/2023-03-10-things-to-bring-back.md
@@ -0,0 +1,86 @@
+---
+title: Things to bring back
+description:
+---
+
+I recently marked 10 years at GitHub. The company changed a lot since I joined a manager-less and idealistic organization of a little over 100 people. Growth, funding, scandal, loss of direction, acquisition, even more growth, and a pandemic - 21 re-orgs later, it's been a wild ride.
+
+Here are N things from GitHub's earlier days, that I wish we could bring back at our scale today:
+
+## Culture tools 
+
+We used to have a concept called "culture tools" to describe how we crafted internal tooling.[^3] Culture tools were more than just get-the-job-done internal tools, but brought the samae level of attention to detail, taste, and craftsmanship to internal products as we did our customer-facing ones. 
+
+Their character was driven by the culture of GitHub and the way we worked. The foundational mechanics of communication at GitHub (at the time) was things like URLs, @mentions, markdown, and emoji. These weren't just features we wished our internal tools had. These were features we expected them to have. They were features that let us work the way we want to work - Asynchronously, whenever, wherever, on whatever - and let us jump from tool to tool, and things just worked the way you'd expect them to without any learning curve. These tools, at their core, helped us optimize for Hubber happiness.[^4]
+
+## Being oppinionated about how we worked
+
+Like many startups, we saw everything as an opportunity to reimagine the status quo, and as a result, thought very deeply about how we worked, and how we could work better - sometimes to a fault.
+
+We were among the earliest adopters of ChatOps (what we'd now call DevOps), developed the now-standard "GitHub Flow" branch + PR model, and pioneered the concept of "pull requests as a conversation" (which we now call "code reviews"). Meetings were rare (I had fewer than 50 my first year at GitHub), and even experimented with "no managers" and "no titles" for a number of years. We also [open sourced almost everything](#).
+
+ANOTHER PARAGRAPH. MAYBE TALKING ABOUT ASYNC AND SELF DIRECTION.
+
+## Talking about how we worked
+
+For as much time as we spent thinking about how we worked, we spent almost as much time sharing how we worked. Blog posts, conference talks, open source tools - we were a company that was obsessed with how we worked, and we were proud of it.
+
+Culture of blogging and speaking: Zach's talk/posts, Ryan's
+
+## Shoutouts
+
+One of my most missed aspects of earlier GitHub was something we called "shoutouts". Each Friday, we'd have a company-wide all-hands (known then as "beer:30"). At the start of the meeting, we'd have a "shoutout" segment where the CEO would call out Hubbers who'd done something awesome that week. It was a chance to recognize the work of our peers, and to celebrate our culture and the things that made GitHub special.
+
+Anyone in the company could nominate anyone else for a shoutout. My first shoutout was to a fellow Hubber for "taking the time to drop some Ops knowledge on a n00b, despite everything being on fire (and then putting out the fire)." Sometimes they were serious, sometimes they were silly, but they were always genuine, and a great way to fuel an ongoing appreciation economy.[^1]
+
+Shoutouts didn't scale as the company grew to now thousands. We continue the tradition to a degree today with our "sparkles" chatop, but it's not the same, in terms of recognition or visibility.
+
+## A weekly dose of culture
+
+Speaking of our weekly all hands, I still remember one of my first beer:30s, where the then CEO gave an inspiring talk on designing from first principles. It was the kind of Ted-style lightning talk that you'd expect at a high-profile tech conference. He talked about jobs to be done, with 20 examples of design in every day life, the most vivid I remember is his recent experience opening yogurt on an airplane. It was all about helping customers reducing the time to their envisioned future, and it was immediately applicable to our work at GitHub.[^2]
+
+But the thing was, I soon came to realize that talks like this happened every week. Inspiring talks like that, that spoke to the core of who we were as a company, and what we were trying to do, or what it meant for a product to be "GitHubby", was the norm. It was a weekly dose of culture, and it was a great way to keep us all energized and building the best and right things.
+
+Best of all, it was the start of a *conversation*. The audience would ask questions ("how would you think about applying X to Y?"), and everyone could participate. As a company grows, it's all to easy for all hands to become highly curated and crated "messaging" sessions from "leadership" to "employees", a one way information flow of "here's what we're doing" or "here's what's important to *me*", followed by a brief press-conference style question and refutation session, for as long as the remaining time allows. 
+
+But at earlier GitHub, it was a conversation. It was a chance to ask questions, to share ideas, and to learn from each other. It was a chance to be heard, and to hear others. It was a chance to be inspired, and to inspire others. It was a chance to be a part of something bigger than ourselves. FIX THIS.
+
+* Leadership accountability
+* Safety of being wrong
+* Time to learn/tinker/hack
+* Not shipping the org chart / quality / wholistic experience
+
+## Speaking like a human 
+
+We used to use the phrase "speak like a human" to describe the "GitHub voice". From our documentation to our in-product copy to our [public-facing blog posts](https://ben.balter.com/2015/07/20/write-corporate-blog-posts-as-a-human/), we sought to connect human to human, not as corporation to customer. Internally, we didn't adopt the traditional "BizSpeak", pinging servers, not humans, driving consensus, not "alignment", and taking things offline __.
+
+
+* demo days
+* Individual customer focus
+* Memes and having fun
+* Developer friction.
+* Work being more important than the game of work
+* Default to yes, vs default to let’s talk
+* Healthy debate good intentions
+* Emoji, GIFs for celebrations
+
+Things we did keep:
+
+* developer happiness
+* Output > input
+
+Things we got rid of:
+
+* Shipping for the sake of shipping
+* Changing direction every 6 months
+
+
+Link to twitter thread.
+
+[^1]: Rework
+
+[^2]: TL;DR: Everything we touch and experience can be designed. The choice to care about these things is up to us. We can all be designers.
+
+[^3]:  As the documentation then put it: "GitHubbers work differently than other people. It is important that our tools not only reflect this, but encourage it and support it." 
+
+[^4]: As the Culture Tools "Ethos" put it, "Actions required of a hubber that do not benefit the hubber == process. Don't do this. Ever... Work with hubbers, not against them. Features should fit the way hubbers already work."
\ No newline at end of file