12/15/2023 Last edited: 3/28/2024

README

Dustin Schau

Product & Engineering Leader

whoami

My name is Dustin Schau, and my current role at Postman is Head of API Client. I joined Postman in October of 2023. What matters is what I do next, but before Postman I was co-founder and VP of Product & Engineering at Gatsby and before that a software engineer as a consultant and at Fortune 500 companies. As Head of API Client, my role is to ensure that the core engine of Postman in API Client (sending, debugging, and testing requests across multiple protocols) continues to improve.

Personally, I am a new, first-time dad and lucky husband to my wife Maggie. I live in San Francisco, CA but am from the middle of America (Iowa!) and moved to the Bay Area in 2019. In my spare time, I like to spend time with my family exploring local parks, neighborhoods, and coffee shops. I like to read (recent favorites have been the Red Rising series, as well as Tomorrow, and Tomorrow, and Tomorrow), explore new restaurants in San Francisco and in the world, and golf when I can although less than I used to with the little one.

Leadership style

Don’t listen to what leaders say—watch what they do.

– Frank Slootman, Amp it Up

It’s challenging to distill something as complex as leadership into a few sentences, so ultimately the test of my leadership style will be predicated on the long-term process of building trust. My style is predicated on this central belief: great teams trust their leaders, and great teams trust one another. We are building a team, and teammates have to trust one another and their leader.

How I build that trust is shown, demonstrated, and embodied over time with my actions, but at a high-level, here are some of the things I value and try to cultivate and demonstrate:

• Driving decisions downwards. Ultimately, it is my role as a leader to create an environment where good decisions happen by those closest to the work. Of course I will make decisions, and set just enough top-level strategy to create this environment, but I am successful if I give enough autonomy and authority to those closest to the decision to make it and feel empowered to confidently pursue a direction. To use a metaphor: my role as a leader is to draw the shape of an owl. Your role, as a member of the team is to help us all draw the rest of the owl.
• Over-communicate, especially written. I try very hard to ensure that nothing I communicate is surprising. This is done primarily via writing, sharing documents, and communicating well across timezones and with async-friendly artifacts, leveraging meetings where appropriate to enhance or share important updates. A good, written document is the best way to communicate, share, and solicit feedback about an idea.
• Feedback is a gift. I try to actively solicit feedback since as a leader it is not given particularly often. I welcome and relish feedback, particularly if it’s something you particularly liked so I can do more of it or something that could be improved so I can do less of it. I will try and do the same, although admittedly I will not always have feedback and I only give feedback if I have an observation and something to share.

Expectations of myself

As indicated, the foundation of a successful leader is one of building trust. As such, my expectations of myself are that I always operate with integrity and as transparently as I can. Some things that I commit myself to to establish, hone, and continuously build this trusting environment:

• Follow-through. If I say I will do something, I will do it. Typically, I also self-impose a deadline for accountability purposes, and if that deadline slips, I will communicate that proactively. If I slip on something I said I was going to do that you are relying upon, please let me know and likely I’ll be frustrated with myself.
• Authenticity. I try to bring my full, authentic self to all my interactions. That means I will share my honest observations, my honest responses, and bring my full self to work and in all interactions. If I don’t know something, I will say that and usually I’ll try and get an answer too. I will do my best to communicate the why especially in cases of disagreement. The weight of ideas matters more than the weight of a title.
• Strong personal relationships. If you are a direct report, we should meet weekly since 1:1s are the bedrock of strong relationships and trust. If you are an indirect report (report to someone who reports to me), I will try and meet monthly but please reach out via DM if you’d like a different cadence. In both scenarios, don’t wait for a 1:1 and if you need my time, request it. Nothing is more important than the people, and I will always have an “open door” policy with my time.
  • 1:1s are for you, which means that while I’ll sometimes have topics to discuss, ultimately what you get out of them and the agenda should be driven by you. In service of that, I typically have a Google document that is shared only between us, where I encourage you to add topics and track takeaways.
  • 1:1s are a great way to share topics that you wouldn’t share with others, share an idea or a strategic topic you’re uncertain about for guidance, and to give and receive feedback.
• Minimize surprises. Good communication is clear, transparent, and rarely surprising. This doesn’t mean it’s never surprising, but my commitment is that when there is information relevant to a team or an individual, I will do my best to make sure it’s communicated regularly, repeatedly, and in different venues (Slack, Google Doc, synchronous meeting, etc.).

Expectations of team

In many ways, my expectations of the team are largely the same as my expectations of myself. I hold myself to the same standards of excellence that I expect of my team. Importantly, I think of us as a team not a family. As a member of the team we all have an obligation to help the team thrive and win, and we should have high expectations of one another.

1. Care deeply. Each of us may have a particular set of variables about what we care about, but ultimately, we should care about the customer, the business, the product, and each other. Passion is a prerequisite for success, and we should care quite a lot and take pride in what we do. We are working on a ubiquitous developer tool and our users rely on us, let’s treat that with the respect and care that it deserves.
2. Kindness not niceness. Since we’re a team, we operate with kindness over niceness. A simple example: niceness is telling someone what they want to hear, whereas kindness is telling someone something they need to hear. Great, trusting relationships are predicated on the ability to hold one another accountable, and kindness is a better long-term path to get to that trusting relationship.
3. Show up prepared. If you are attending a meeting, leading a session, leading a meeting, do your part to prepare and make sure that what you’re doing is successful. Something as simple as reading the agenda, adding topics to a 1:1 or thinking about a prompt from a previous 1:1, or thinking about a good question to ask in an All Hands goes quite a long way to improving the outcome for all. It may only take you five minutes and that five minutes is time well spent.
4. Be active. If you are doing something, do so actively and seek results, clarity, and understanding. If you believe there is something that is unclear, be active and seek making something more clear. Actively listen. If you have a question in a meeting about something, ask it! If you are not so sure about a technical direction, raise it. Don’t forget: you can do great things by being an active agent of change and improvement and you’re here to deliver and improve.
5. Communicate to broadest relevant audience. I am a big believer in over communication, and great teams communicate well. Whenever possible, try and communicate with documents, with Slack, in meetings, and don’t be afraid to repeat yourself. Especially with a remote company, communication soothes all ills and helps everyone understand what we’re doing and why we’re doing it.

My quirks

1. I tend to over-prepare. Plan for the worst, expect the best. In way too many scenarios, I tend to over-prepare. That could be 1:1s, team meetings, all hands, and really anything where I am in a position of visible influence. How I turn that nervous energy into productivity is I write things down. So, you may notice that I do a lot of writing. I think it’s a good thing, and I encourage you to read most of what I write (and I’ll explicitly note the must-reads), but it’s my way of preparing and ensuring that I can explain what I am trying to explain and that I am always prepared. a. Previous employers joked a phrase of mine was: “I have a doc for that!” (And there usually was… ) b. You don’t have to write as much as I do, but I do encourage my team to write well and write more. It’s the best way to communicate for understanding and comprehension. Across timezones, across teams.
2. I care a lot about communication. I can be a little pedantic about good, broad communications. This is highly intentional, but it can come off a little nit-picky at times. For example: I may encourage you to post a message in a team Slack channel instead of in a 1:1, or to post takeaways from a meeting that all of us were at, and so forth. I care about good communication because I believe it’s one of the most important things that separates good from great teams, but I also acknowledge it can be a little pedantic Feel free to push back from time-to-time.
3. Concrete examples help me. While I’m still technical and can understand most things, concrete examples and demos help me understand much more easily than an abstract, high-level example. You may see me re-phrase sometimes and say something like: “So does that mean X? Is that an example of what that concern would lead to?” and that’s largely just to help myself understand it and make sure we’re on the same page.

How I like feedback

If it’s something constructive (e.g. you have room for improvement and I didn’t like when X happened and here’s why), I prefer that type of feedback in person in a 1:1 or an ad hoc meeting. It lets me ask questions to clarify my own understanding and helps you make sure the feedback is well understood. I will usually ask questions not to dispute the feedback, but to make sure I understand and can internalize the feedback.

If it’s something you liked, feel free to share a Slack DM or a 1:1, whatever you prefer! It helps me immensely as a leader to know when something was liked, appreciated, or particularly clear, so that I can do more of that type of thing in the future. Otherwise, I have to read the room which while I’ve gotten good at, still isn’t the easiest especially via Zoom.

In both scenarios, I prefer just-in-time feedback, so that the interaction is still readily apparent in my mind.

Misc. metadata