I created this document while I was at Vimeo where I had to establish new teams, and by association new norms, across multiple teams that were geographically distributed. We had a number of larger initiatives that were key to the businesses’ success and needed to spin up highly performing teams, and fast.

I had heard of READMEs before and was against the idea of them as it felt like a mandate from a manager of how their direct reports were expected to behave. However, after digging around for additional examples from leaders in the space, I found a few that really resonated with me and decided to take a stab at writing my own. Based on the positive feedback I’ve received on it since using it, I’ve continued to keep it up to date and used it with all my teams since.

You’ll see that I’ve versioned and dated this document. I track when I add or remove large sections (foo.0), and when I make smaller tweaks or fix typos (0.bar). I also include a date, both to keep myself honest and to show the reader that this is a document I regularly review and update.

The largest changes over time have been fleshing out areas based on feedback, including more about my personal life, preferences in how I work and think day-to-day, and generally things that tend to be unspoken unless explicitly asked (e.g. what’s the best way to share bad news?).

I find READMEs to be most effective when they are honest and specific. If a README sounds good but isn’t actually reflective of how you think, work, and behave, it isn’t going to actually be of any use. It takes a lot of introspection and hard truths to ensure your document is actually useful for anyone that would be working with you, so the sooner you can get feedback on it from a diverse group of individuals and iterate on it, the better.

Similarly, if your README is too generic or deals in platitudes, no one will actually know what you’re talking about (I semi-jokingly call this “business speak”).

I've only worked at companies that have unlimited PTO, and most companies that offer unlimited PTO actually see that their employees take less time off on average than employees with specific allocated days off (

https://blog.namely.com/blog/high-turnover-high-growth-companies

I also like folks to know I've experienced burn out first hand - for many it's a concept rather than a potential reality. It can be one of those things that you don't know what's going on until you're in the thick of it, and so I like to explicitly call it out to keep folks mindful of their mental health.

This can be challenging especially with large, meaty problems with a storied past. I also find when we are not being as successful as we could be with supporting psychological safety, this aspect tends to be one of the first to start to suffer, as it can be seen as a weakness in reviewing what you’ve already ruled out or where you’ve already “failed”.

How I work async was the most challenging to articulate, only because it took a lot of feedback and back and forth for me to be able to understand what my preferences truly are. I had preferences related to async and remote work pre-COVID, but then the rest of the world took a crash course in remote work, and I had to reassess and adjust some of my working preferences once again.


Be explicit! Something as simple as: "This is a problem we need to further explore. What do you think would be best next steps?" vs. "This isn't working as both of us have expected. Let's see what we can do differently." There should be no room for confusion between those two things, otherwise as a leader you are not communicating effectively.


Your leader has put a lot of time and thought into this document, and they are sharing it with you with the intent of you hopefully being as successful as possible in your working relationship together. Know that READMEs go both ways, and ask if your leader is also sharing their doc across orgs and upward.

Take the time to really go through the document, give it some deep thought, and then go through it again.

Finally, feel good that you’re working with another human that values a tool like this to ensure open and honest communication at work. Maybe you’ll even be inspired enough to write your own!

I tend to keep a closer eye on folks as I'm getting to know them. Once I can tell where they lean in terms of this (fear of speaking up / fear of bringing up problems without concrete, 100% validated solutions, or overly confident, works in a silo, presents ideas once they have a "bulletproof" plan and are hard to convince otherwise), I can then push or pull them as needed.

In general, I try to remind folks that the job of a PM isn't to solve the problem by themselves, it's uniting all the amazing brains we have available to us to come to the best possible solution, and then make it happen. Especially as folks rise in their roles, the assumption grows that they need to do it all themselves. PM can be a lonely job!

This mostly works. But in rare cases when it isn't working (there is a known lack of psychological safety, or when I am first getting to know teams) I'll be explicit and ask at the end of closed sessions or smaller team meetings (e.g. not in a giant all-hands!).

In the rare cases when I am surprised, I will explicitly say "This is something known weeks ago; this should have been shared out so we could have done XYZ, but let's see what we can do today". Like the old adage (I am almost certainly misquoting this!), "The best time to plant a tree was yesterday; the second best time is today".

During my time at Pendo, I overlapped briefly with the brilliant SVP of Engineering (now at Google) Dave Rensin. He had brought with him to Pendo the idea of "Beat Dave Up", where he encouraged folks to bring the toughest questions possible about everything and anything related to engineering at Pendo.

His promise was twofold:
1. He'd always answer the question
2. He'd answer the question in the following ways: With the answer, with a promise to figure out the answer if he didn't know it, or if he did know it and wasn't able to share (for privacy, security, or other reasons) would state that explicitly.

Folks would even get points for bringing the best questions and would ultimately be awarded prizes.

It was a ceremony that deeply resonated with me, and I stole the idea and energy of and brought with me since. We held these sessions at the end of every quarterly strategy review, and strongly encourage folks to do the same in the large public squares of their own companies. You'll figure out very quickly what is working and what isn't in your culture!

Cassidy Fein

I created this document to help myself and future team members onboard faster. I've worked remotely for nearly a decade, and successfully utilizing a README can help speed up important relationships and help teams make the leap from forming to performing.

I’m Cassidy Fein (pronounced “Fine”).

I’m really excited to work with you, either as your manager or as a colleague.


I’ve created this README to help others understand what it might be like to work with me and to accelerate our working relationship, especially as I tend to work remotely.


This artifact is never meant to suggest how you should work, or suggest you modify anything you’re doing (and if it comes off that way, let me know! I love FEEDBACK).

I work as transparently as possible - my calendar is public by default.

I love solving hard problems for real human beings - both for our users, as well as for each other.

I’ve worked in product management nearly my entire career and am incredibly passionate about it. I teach for 

 in my spare time, and will occasionally coach PMs early in their career.


I’ve worked remotely for the last ~10 years, and strongly believe in the power and value of remote work. I love chatting about this, please bend my ear if you’re also passionate (for or against it!).


I’ve worked in B2B SaaS my entire career, mainly focused on enterprise. I love growing and scaling teams, fostering culture, and accomplishing big hairy audacious goals. I’ve worked at companies from 5 employees to 1500+ employees, and am familiar with the norms and frustrations that come with scale, especially with hyper-growth.

I’m based in Brooklyn’s Prospect Heights, and have a husband, a newborn daughter, and a dog. Hobbies include reading (always happy to talk book recs), cooking, painting, and MTG nights with friends.

, or just look at cute pictures of my dog 

You can Slack me 24 hours a day. It’s my preferred communication medium. I like responding quickly. Otherwise I typically check my email 1-2x/day.

I treat iMessage as a red alert - if you ever need to reach me, my cell is [redacted]. I will respond as soon as reasonably possible.

Sometimes I work odd hours. This is my choice. I never expect you to work on the weekend or outside your normal working hours. I might Slack you things, but it can always wait until work begins for you.

. If you haven’t taken one in a while or seem like you need some time away, I will suggest it. I’ve been 

 before and it is absolutely awful, so I try to get ahead of it for both of us.

 I’m better at helping when I have a good idea of what you need. “Take a look” is less helpful than “I’m looking for feedback on X and Y, by the end of the month, otherwise I cannot accomplish Z”.


. Explain what you've already searched for on your own, and what assumptions have been challenged. This also includes other options you may have ruled out. Having more than one option is always a more interesting discussion than having to defend why one option is the right one.


This may look like me being pedantic in meetings, but I’m trying to make sure there is a shared understanding, and that folks feel comfortable being vulnerable (e.g. asking “dumb” questions) so we can all work productively and happily.


I tend to listen and think in full sentences. 

This means even though I may disagree with what you’re saying or have something to add, I will wait until you are done speaking. I will typically use lots of nonverbal cues to show you whether I am processing, agreeing, or disagreeing.


I prefer to work asynchronously as much as possible

 We work in a global business, and async work means that information is purposefully documented and shared in a more repeatable and robust manner, which is better for everyone. It is a pet peeve of mine to receive information for the first time when it could have been shared in advance, so if I seem annoyed in a meeting this is probably why. I will also reject a meeting invite that doesn’t have an agenda or any advance notice as to its purpose.


I tend to make suggestions and asks rather than commands.

This is to leave room for your disagreement or better idea. 

If I’m not communicating expectations effectively, please say so and I’ll do my best to adjust my style.

 If I have a strong opinion about something, I will say so.

I strongly believe in focused “down time” and will block my calendar accordingly. 

If you’re a direct report, I will always drop everything to chat with you as needed.

For everything else, I need time to be able to do thoughtful heads-down work and to digest the outcomes of meetings. Please respect this time, and I strongly encourage you to set up the same if you feel like you’re underwater.

Work is not the most important thing in our lives

. We all have things going on, all the time, all at once. If you have something going on that won’t let you be your best self at work, and if I can help, please let me know. If you can’t talk about it, that’s 100% fine, I just want to make sure you’re okay.

These are some of the things I love to see from the teams I work with, as well as how I tend to work.

Operate using our company’s values as your guide

Provide our company with thoughtful, good work.

 Tell me if there's something preventing you from this, and we'll work together on fixing it.

If I’ve given you a large, complex, and high-risk project, it’s because I trust you and believe you will be successful. If you feel it’s too much or our goals are unattainable, you should tell me, and I will help.

Instead of waiting, move problems forward, even if that means grabbing 1:1 time with me to talk through it. I

f you’re struggling feeling comfortable with this, thinking through if it is a Type 1 or Type 2 decision can sometimes help.

 The outcomes of meetings and digests should always be documented in a company-wide available location. Document in real-time or immediately after so the information isn't weakened by time. This also helps invest in our future teammates that need to understand paths of decision-making to gain greater context.

If there's a problem or you're blocked on something, bring it up right away.

 I'll generally interpret silence as "everything's fine".

I firmly believe that regular feedback is vital to build trust and respect in a team.


At [company], a formal feedback cycle occurs twice a year. The first time we go through this cycle, we’ll draft a proposed set of goals for you for the next review period. These are professional growth goals for you and separate from any goals your team(s) or broader department may share. This also makes sure we focus on your goals as a human, in addition to (rather than simply) a linear track of promotion. My proudest moments are proactively managing people into achieving their goals, regardless of whether those goals keep them in my current team, org, or company.


Review periods are not the only time we’ll exchange feedback - I’ll ask you for feedback in 1:1s regularly. I will never stop doing this, no matter how many times you say you have no feedback for me. I believe building a healthy feedback culture is a cornerstone of building high trust relationships.

Disagreement is feedback, and the sooner we learn how to disagree with each other efficiently, the sooner we’ll trust and respect each other more.


If you don’t feel comfortable giving me feedback directly, please share it with my manager, their manager, or HR. I really hope you’ll consider sharing it with me first, but if you don’t feel comfortable, know that it is a sincere failing on my part.

Big thanks to Darren Murph and Michael Lopp (rands), from where much of this is borrowed:

Manager README from Cassidy Fein

Cassidy Fein README v4.1 (6/15/2023)

Hi! 👋

Sign up to see more