Narrative Dev Culture

To judge “culture fit” in a non-handwavey way, we have to first define what our culture is. Below is a high level definition that was written with software development in mind but can be applied to other parts of the company:

What culture isn’t

Culture is not the stereotypical startup perks like ping pong tables, free beer, t-shirts, or a shared love of videogames. It is not high-level statements that are essentially impossible to dis/agree with, like “we work hard and play hard.”

What culture is

In one sentence: culture is the shared set of values by which people get s(tuff) done.

Narrative’s Culture


Everyone at Narrative needs to be able to act quickly and effectively in various business situations. This starts with two things: communication and transparency. Transparency is all about what we communicate, and communication is about how we do so.

In order to make effective decisions people need access to all of the pertinent information and expertise available in the company. The only way this is possible is with a culture of complete transparency. We share and allow access to all information by default – whether that is something to celebrate like a large sales deal or a major feature push, or something to learn from like a production bug that resulted in downtime. Transparency ensures that everyone has the information to make effective decisions, and helps pre-empt any big surprises down the road where people ask “how in the world did we get here?”


Although we default to transparency and err on the side of over-communication, we also need to pay attention to how we communicate. To minimize disruption and noise, we should prefer channels that are: opt-in, asynchronous, and persistent.

Preferring opt-in ensures that people can sign up for information that is relevant to them, versus forcing them to opt out of information that is not. Broadcasting is still necessary and there is definitely a balance to be struck, but who hasn’t gotten stuck in a meeting that has either been side-tracked to an unrelated topic, or was too large to be useful in the first place? Preferring async ensures that information can be consumed without disruption of anyone’s workflow: for example, using Slack or email to ask a non-urgent question vs calling an ad-hoc in-person meeting. Preferring persistence builds a knowledge base over time and makes it easier to access information in the future: for example, a google doc discussing the design of a system can serve as valuable documentation for a future new hire. Conveniently, all of these are also valuable practices as companies and teams become increasingly distributed.


Taken directly from the book Team Geek (now known as “Debugging Teams”), HRT stands for Humility, Respect, and Trust.

Humility is the recognition that we are all imperfect. We all have our corresponding strengths and weaknesses. There are many things we do not know and many mistakes that we will make, and we should embrace this as opportunity for growth.

Respect is the recognition that others on the team are also imperfect in the exact same ways. We should always have empathy for others and remember the Golden Rule.

Trust is the realization that everyone is working towards the same goal regardless of role, seniority, etc. We each have something different to bring to the table, and while that might result in disagreements on occasion, at the end of the say we’re all working towards the same end.

Taken with the concept of transparency, HRT does not mean that all of our communications need to be “nice” or sugar-coated. It does mean that feedback is welcome and should be constructive and respectful, not given or received as a personal attack.

Quality and Getting S(tuff) Done

Time pressure can make it tempting to sacrifice quality in exchange for short-term velocity. However, this behavior just hurts our ability to GSD over the long run. For example, skimping on testing can save a bit of time today, but makes all future work harder. Much like eating our vegetables, we must forego some short term gratification in exchange for long term happiness.

However, it’s also important to not get stuck in the ivory tower and let the perfect be the enemy of the good. Even assuming achieving theoretical perfection were possible for a given project, “done” is never “done” in software. Requirements evolve over time, plus maintenance tasks like scaling and operations will always require additional effort. Therefore, we should strike a balance: scope for small rapid wins, adjust course as needed, and always work towards higher quality.