Writing

As I've spent more time working with people and building a company. I've come to realize that my personality can be interpreted as abrasive. My intention is always to be effective, productive, or simple. I'm usually just following the principles I've devised for success. What follows is a set of principles that guide the decisions I make when it comes to work. Some sections include bits about what I expect from the people I work with.

I wrote this on my public blog, so it remains my property and not that of any company I work for. I hope it helps us work better together.

I adopted this principle as I started working in a more asynchronous manner. The nature of remote work means that high frequency, high bandwidth communications (and interruptions) do not exist. This means that to be effective, you need to be organized. Being organized is a great personal habit and it actually provides you leverage at work. I can write something once and others can potentially read, refer to, or use it hundreds of times. It becomes searchable when put into a system with powerful indexing so others can find it when needed. Writing things down is also great for historical reflection - was your thinking on a subject spot on? Far off? How far? When you have writings dated, you get a free audit log for the future.

Furthermore, writing allows you to review your thoughts before sharing - that is something real-time communication diminishes if you're not practiced. I enjoy getting the opportunity to make sure I mean what I say before another person takes it as input or feedback.

The primary tool I use for writing is notion - it allows you to achieve relatively high fidelity documentation of thoughts with lots of different "blocks" of text. It also allows for a hierarchical organization for a clear structure.

This means that a lot of how I communicate is written, typically via notion and sometimes via other mediums (like presentation decks, recorded videos, or spreadsheets).

Of course, writing can have its downsides, for instance, it's easy to misconstrue tone in writing and sometimes, messages are better delivered in a real-time setting, like zoom, a phone call, or an in-person meeting.

For people that are working with me:
Please know that I appreciate every single piece of writing you create for the organization we work for and will read as much as I can and evangelize this information when relevant.

I actually didn't pick this principle up from work, I picked it up from Burning Man. However, when I started to apply it to other areas of my life, I became obsessed. I even grow some of my own food as a result of how much I value this principle. What this equates to at work is that as much as possible, I try to act in a self-contained manner. If I'm responsible for a small part of some larger project, I try to think of all of the surrounding parts and where there may not be proper staffing, ownership, etc. In practice, this can be as small as taking over copywriting for a web page I'm responsible for coding when there are no copywriters or as large as making sure that a hiring process is in place when there are no HR people.

This can be construed as overstepping my boundaries - what I'm actually doing is just ensuring that any loose ends are caught and tied up. If you ever find that you feel I intruded on some task or area of responsibility that you own, then please make sure you document it and share it with me!

I also consider this crucial for self-education, if we believe "written communication is optimal" then we're doing everything we can to self-educate on internal/proprietary knowledge and also making sure we know what is being talked about at our organization by being knowledgeable about the core of our business, as well as the edges.

For people that are working with me:
I have always loved working with people at the edges. The areas where it's none of our responsibility officially, but we need someone to do it. If you pick up the slack that is not your job, expect gratitude and praise!

I stole this principle from a venture capital firm I worked at, First Round Capital.

Quite simply, speed matters. Practically speaking, almost every decision is reversible, or adjustable in a worst-case scenario. This means that in almost every case, we should be opting for a single round of analysis or synthesis, and moving forward with action. This primarily means pushing for things to get closer to completion. Sometimes it means we should just ask the customer or customers what they think instead of theorizing in a group setting. Now you might think that I'm being irrational and that we should be "measuring twice, cutting once" and that if we're not careful, we could just do a bunch of wrong things. I'd argue that just getting things done is the first, critical element of getting the right things done.

For me, this means I'm going to try to act quickly on anything I'm working on - I'll typically try to take the fastest path to completion on a given project, taking shortcuts if possible. This also means that if we're having more than 3 meetings on a targeted topic, there is a decent chance I'll just start doing things to fix it or drive it towards completion after that third meeting. Don't worry though, I'll be very vocal that we should act fast before then.

For people that are working with me:
I prefer but do not expect my coworkers to act with the same urgency as me. Life is hard, people have children, pets, hobbies, obligations, etc.

Over the years, I've failed at many large-scale projects. The learning every single time was "we bit off more than we could chew". In order to avoid these kinds of mistakes on a go-forward basis, I've devised this principle. It means that large-scale projects are good. Big hairy, audacious goals are great. However, we have to turn those big ideas into atomic, concrete steps to be taken. I will typically combine this principle with others to make things happen. For example, if we want to "Move to a new payroll provider", I'll do a quick analysis of the tasks to complete ("work smart, not hard") then I'll get started immediately ("have a bias for action") by finding the tiniest sliver of the task we can deliver, let's say "exporting all data from current systems" to complete and working with a small group to get the task done.

Another aspect of "think big, act small" is a continuous attempt to reduce scope to make the thing smaller. This means if we agreed that there were 10 tasks to complete "move to a new payroll provider", I'll continually ask after each task if we can cut other steps, or mark them as complete. This results in a real-time reshaping of the big idea, into a potentially smaller idea, that can be delivered faster.

For people that are working with me:
It may feel like I'm reneging on our agreements, if it does, let's discuss what I'm removing and why!

This is actually a principle I formulated after working with my co-founder at QuickNode, Manuel Kreutz. The first time I worked with him, we encountered a workload that required a lot of manual labor to ensure correct data. After about 3 days of this, Manuel created a fully automated tool that allowed our partner to upload the data, get verifications, perform autocorrections, show validations and automate the next step after the data was marked as correct. This created a shift in my mentality as a worker and programmer. An easy way to understand this is that if you're doing some annoying task over and over again, you should consider the tools available to you, to automate it.

One more aspect of this is taking in a single round of feedback and ideas from co-workers before acting to make sure you're not missing glaring items.

How I put this principle into practice is that I'm often looking for a solution that will at least automate the pain away. If the elegant solution is too big to implement, I'll seek the smallest possible shippable part ("bias for action", "think big, act small").

For people that are working with me:
This is a trait I try to infect my coworkers with. You should be continuously looking to master new tools both online and off to give yourself more leverage. This includes spreadsheet software, Zapier, APIs (Twilio, Clearbit, etc), and more. I really really want my co-workers to always be thinking higher-level because it can make their lives easier and mine as well. If you'd like some coaching on how to do this, I'm happy to give feedback.

I believe the best organizations are the ones where all ideas can be heard. This means that anyone should be able to disagree with anyone else in the organization, regardless of title, seniority, etc. This is a crucial principle for me because if I am operating or making decisions on information or views that are incorrect, it can hurt the organization. The same goes for coworkers. Since we are trying to "work smart, not hard" and we "have a bias for action" - it makes sense to get all of the incorrect assumptions out of the way as soon as possible.

Furthermore, we should be able to ask questions (to an extent, because I am trying to practice "radical self-reliance") in order to ensure everyone has the proper understanding of the situation so we can all move faster together. This is the reason I prefer public disagreements so that anyone who has the same question can have it resolved.

For me, it's important that if I am being questioned or disagreed with, I never raise my voice, curse, or be rude to the person trying to get the information.

For people that are working with me:
Being publicly wrong can be painful, if you are the sort of person who prefers to have disagreements in private, please let me know. I'm happy to move to private conversations here. Also, it's very important to note that I do not react well to people yelling or cursing during disagreements. I can cope with you being rude, and I will clearly mention any of the three behaviors I have on my block list. I expect you to do the same.

This principle is meant to help me make sure I do not make a move that violates someone's trust first. I actually decided to include this in my work principles after playing this game called The Evolution of Trust.

At work, I noticed that we're usually operating with imperfect information and people may not always have time to explain all nuances of their point of view. Additionally, bad things happen and it's better, speaking from a game theory perspective, to assume they were mistakes rather than malicious actions. This means I'm dedicated to giving people my trust and benefit of the doubt by default and only making changes to my assumptions after egregious repetition of mistakes without sufficient explanation. I try to make sure that I'm assuming the best from the people I work with, basically.

I'll also try my best to document my mistakes, share them and ask for forgiveness when I mess up.

For people that are working with me:
If you make big mistakes, it's OK. Write down what happened and why then share it. I'll do the same and we can learn from each other while growing our trust.

This principle comes from personal experience, but it is verified by third-party experiences, like that of Jeff Bezos and his two-pizza rule:

I like to practice the same. For a few reasons; the first is that fewer people means less communication overhead - each person doesn't need to spend the additional incremental time to communicate nuance to each person, the second is that it's easier to feel mission-driven with less people - it's us, we are the people who will complete the mission (or not).

My preferred team size is actually 1, but barring that, 4 is ideal. At a maximum, I can tolerate 10 people working with me on a project. When I see team size grow beyond this, I think about two things:

1. Are they finding points of leverage ("work smart, not hard")?
2. Do we need to find a way to break this team into sub-teams with their own autonomy?

For people that are working with me:
If you develop a strong sense of urgency ("have a bias for action"), gather information ("it's ok to disagree and ask"), understand you control our destiny ("radical self-reliance"), and find leverage ("work smart, not hard"), I think we will almost never run into this problem.

I prefer to emit and receive uncoded language, without using curse words or raising my voice when it comes to the working environment. Speaking simply, directly, and plainly is ideal for me. For example: "When can I expect the data dump I asked for yesterday?" is preferable to "I know you're busy. I was wondering if I could get an update on the data dump." - the former is concise and to the point, and the latter, is significantly more vague and makes room for further delays ("I know you're busy").

When I speak, I don't want to waste your time or spend my time trying to consider your emotional state (with the exception of obvious things like death, divorce, and health complications). I want to speak directly and receive honest answers, even if they are not what I want. For example: "I kicked off a job last night, the server is very slow, but the current estimate is 2 days from now. I'll update you by the end of the day if that is still accurate." is better than "I'm working on it, not sure when it will be done." - I fully understand that things change on a constant basis, including the amount of compute available to a VPS on a public cloud.

It's easy to interpret this as crass, and quite frankly, it is crass. However, the gain in effectiveness is worth the perception.

For people that are working with me:
Don't take my questions, directions, or other communications personally. It's probable that I'm just trying to get information that I can use, or that others can use. Let's be direct, get answers disseminated, and move forward!

In general, I struggle with the idea of deadlines for creative pursuits, such as coding. Instead, I prefer rolling estimated delivery dates which tend to be more aligned with reality. For me personally, deadlines are demotivating, especially when they're not self-imposed. What I've seen is that a lot of things tend to happen that cause distraction from deadlines that can be beneficial to organizations; new opportunities come up that are easier to seize, urgent fires that need attention, etc. for me, the right response to this is to never firmly commit to a date, but instead provide an update on an expected completion date each time something is completed, or if removed from the project, let stakeholders know there is no completion date in view.

This makes it harder to "schedule releases" resulting in a "rolling update" culture that is just focused on consistently shipping, which is a more natural approach to shipping software for me personally.

For people that are working with me:
Don't be alarmed, I can still commit to deadlines if you really want. Just know they hurt and I don't like them.

I hope this guide has given you more clarity into why I ask what I ask. Provided context on how I act and gives you an overall better idea of who I am as a coworker. If you have any questions on these principles or this guide in general, don't hesitate to reach out!