Culture

Message from our CEO

Although cliché, we feel that our company culture can be one of our biggest assets. As we begin to grow the team we felt it important to have a document that would outline Narrative's mission, values, process and procedures. As Narrative is in its infancy, so is this document. As the company grows so will this handbook. It is intended to be a living document and we want all employees to contribute to its content, just like we want everyone at the company to contribute and help mold our culture.

Please reach out if you ever want to discuss.

Nick, Founder & CEO

Core Values

Transparency is always better than opacity

Everyone working at Narrative needs to be able to quickly act to various business situations. In order for them to do that effectively they need access to all of the expertise and information that exists within the organization, something that is not possible if there is a culture of opacity. We will strive to be transparent in everything we do.

All team members are equal

While members of the organization will have different skill sets, personality types, and seniority levels, no one person on the team is better than any other person. We will treat each other with respect, listen to all opinions, and harness the value of a strong collective team. Narrative is a firm believer that diversity within our organization will allow us to make better decisions and thus create a better company.

Make quick decisions and then change course as needed

Many organizations become paralyzed by their inability to make decisions. To quote Aaron Sorkin "every once in a while, there's a day with an absolute right and an absolute wrong, but those days almost always include body counts." This same principle holds when running a business. Most decisions don't have a right and a wrong. In fact most decisions aren't binary at all. As an organization we should prefer making quick, well informed decisions, implementing those decisions and then course correct as needed. This is almost always preferable to taking a long time to make a decision and still having to course correct afterwards.

Culture fit

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.

Dev Culture

Transparency

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?"

Communication

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.

HRT

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 day 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.

Rules and Processes

Rules and processes do not exist for their own sake -- they are simply what we consider to be "best practices" and "good habits" for reinforcing the positive aspects of our team culture.

We share Bizo's view about rules and processes:

• They standardize expectations across the team, simplifying communication.
• They provide healthy defaults for how to efficiently write and maintain software.
• They encode our shared experiences, like a regression test suite for teamwork.

However, like any living codebase, our rules and processes still contain bugs, inefficiencies, and room for improvement. Part of maintaining our team is identifying places where our processes are not working and fixing them. Don't hesitate to break a rule if it is preventing you from GSD, creating high quality applications, or working together as a team. Do make sure that if you break a rule or change a process, you do so thoughtfully and communicate with the rest of us about how we can improve.

Credits

Bizo's culture document has served as inspiration while writing this document.