/manager-README

A summary of the values and principles I aim to adhere to at work.

Introduction

Hi! My name is Rian van der Merwe (Blog, LinkedIn), and I look forward to getting to know you. I am a Director of Product here at Cloudflare, and I support our Data team. The purpose of this document is to summarize some of the values and principles I try to adhere to at work. But we are human and this is a relationship not a contract, so I see it as a way to kick-start how we work together, not the end result.

I also recognize that documents like these can be abused by managers, so this is not a way for me to excuse any bad behaviors. If you see me doing something that is not reflective of these values, please call me out so that I can improve.

Ok, let’s get to it!

My Leadership Philosophy

I believe that we do our best work in healthy, safe, fulfilling environments. That means that to me, the person will always be more important than anything else that might be happening. I am here to be your partner. To listen, to coach, to help clarify with context, to take your feedback to heart, to figure out issues together, to provide guidance—all of it with the ultimate goal of making you successful.

When you are happy and successful, I know that our business and our customers will also be successful. If (well, when...) I fall short of this overall guiding principle please let me know right away. I want to hear that feedback and keep improving in this area.

To put all of this another way, I have two primary goals:

  • Make our customers and business successful, and
  • Build a happy team that loves the work we do

My Product Philosophy

I am a big believer in Daniel Pink’s assertion that people are ultimately motivated by Autonomy, Mastery, and Purpose. That’s why I believe in enabling empowered teams to make the best decisions they can for the business and its customers based on high quality data.

I see my role as a product leader to provide the product strategy, goals, and strategic context to teams. And then I trust teams to come up with the best ways to accomplish those goals through the product. I am ultimately accountable for the outcomes of what we work on, so I remain intimately involved in the details and help guide with context and questions and suggestions.

If our goals or priorities are not clear, or if you feel like you’re lacking strategic context to do your job well, please let me know. Those are essential components of our combined success, so none of that should ever be unclear.

I believe in matching strategy and process to team context, so I am not dogmatic about specific frameworks or ways of doing things. I like to understand how teams get things done, codify what works well, and come up with possible improvements collaboratively. But to get a general sense of where I’m at, here are some principles I like and have seen success with:

Some blog posts that go deeper into certain aspects of my product philosophy:

Communication Preferences

I do my best work in asynchronous environments. I like being able to read or review documents during Deep Work time so that I can provide thoughtful feedback and comments. For non-urgent communication I prefer email over Slack/Gchat because calm > chaos 🫠

That doesn’t mean I hate meetings! I just prefer meetings to be for work that shouldn’t happen asynchronously. For instance, our 1:1s are sacred to me. They will happen every week. If I have to cancel I will provide as much heads up as possible, and provide a clear reason. Team brainstorming meetings are great—I love jamming together on stuff. Also great? Meetings to come to a decision that we couldn’t figure out asynchronously.

For synchronous meetings I prefer a clear agenda and outcomes, as well as a pre-read (if available).

I might sometimes send emails during off-hours. It will usually be a relevant article I read, or a thought about a thing we’re doing next week. I have zero expectations that you will respond during off-hours. This is not some kind of test, I really do mean that.

Decision-Making Style

I prefer collaboration over consensus. It’s really important to me to have as much diverse input as possible when a decision needs to be made. Ultimately my guiding principle is that decisions should be made by those closest to the data. That means that I might ask questions, and ask for lots of other viewpoints, but I will mostly defer decisions to those who know the situation best.

In terms of frameworks, for larger projects I like to have a clear DACI.

Expectations and Feedback

I am extremely transparent with my teams (to a fault sometimes, I’ve been told). I don’t believe in managers being umbrellas for their teams. We are partners in search of meeting our common goals. So expect to hear “real talk” from me all the time—about our challenges, our opportunities, and how we could work together to improve the world around us.

My preferred framework for giving (and receiving) feedback is The Accountability Dial. You can read about it in more detail if you’d like, but the most important principle there is The Mention. It’s the first step and it means pulling someone aside to tell them something you’re noticing—as close to real-time as possible. This is, in my experience, the best way to deal with something quickly without it becoming a big deal with lots of festering feelings.

I believe in kindness over everything else. I will never accept that it’s ok to give feedback in a way that is disrespectful to the people around us. That doesn’t mean that I don’t know how to be decisive.

Conclusion

If something is missing here, or if you have questions, or if you disagree with anything you read... I would love to hear about it. I’m serious. This is on Github (and not a PDF) for a reason. It’s a living document. It evolves as we get to know each other.

Addendum

Books that have shaped my thinking

For more books, newsletters, and blogs, see my recommendations page.