# Daniel Heo-Lu's Manager Readme

**Director of Product at Crunchbase**

# Intro: So uh, what is this?

This Manager ReadMe is a quick introduction to me, my style, and what you can expect working together. It is primarily for my direct reports, though I often share it with my peers and leadership team (Hi boss!). My goal is to set expectations and answer common questions up front.

If you’re new to the company, you’ll also get personalized onboarding and we’ll get to know each other better over time. This ReadMe is just a starting point. If you have specific needs, accommodations or preferences, you can let me know in a 1:1 or send me a note on Slack.

This ReadMe emphasizes topics that can get lost in the day-to-day. For example, I don't talk at all about "Shipping Product" though it is really important.  In this document, I want to carve out space for things that are [important but not urgent](https://hbr.org/2018/07/how-to-focus-on-whats-important-not-just-whats-urgent).

# A bit about me

I’m Daniel and I’m your friendly neighborhood product leader. I've been in product management for long enough where I'm reluctant to count the years. Though I will say, I’ve been a fan of em dashes long before ChatGPT came along.

Prior to Crunchbase, I was at Velocity Global (now Pebl), Dropbox and Intuit (QuickBooks Online). I have also worked at startups like Imgur (pronounced im-ij-er), ChartCube, Evernote and SlideShare. I care about productivity tools, but also embrace the joy of cat gifs. 

![](https://s3.amazonaws.com/managerreadme/images/kims-convenience-meme.gif)

![](https://s3.amazonaws.com/managerreadme/images/cat.gif)

My recent TV binges include Pluribus, Nobody Wants This and Murderbot. I have a deep love for anything performed by [Suzy Eddie Izzard](https://www.youtube.com/watch?v=xxX7QCll3oc). If you want an easy ice-breaker, you can ask me why productivity apps are like the _Fresh Prince of Bel Air_ ([hint](https://www.youtube.com/watch?v=hFjwbKMlmF4)). 

On a slightly more professional front, I've enjoyed _[Creativity Inc](http://www.creativityincbook.com/)_ about Pixar, _[Grit](https://angeladuckworth.com/grit-book/)_ by Angela Lee Duckworth (her [TED Talk](https://www.ted.com/talks/angela_lee_duckworth_grit_the_power_of_passion_and_perseverance?language=en) is fabulous), most of [Atul Gawande's articles](https://www.newyorker.com/magazine/2004/12/06/the-bell-curve), and Brené Brown's Netflix special. 

I have been procrastinating on finding a local pick-up basketball game or weightlifting. I seriously need to counter-balance my love of carbs and the fact that I can walk to Trader Joe's.

# Leadership Philosophy

**I like to build teams around this idea of deliberate learning.** Too often in tech we end up working harder when we should be learning faster. I want to lead teams that get better week over week, month over month, quarter over quarter. I believe that learning compounds over time, just like interest in a bank account.

In physics terms, I care about acceleration, not speed.

This can be difficult because it requires discipline and focus, and a whole lot of feedback over a long period of time. But I hope we can build a culture and cadence that builds toward this. 

## Balancing out my leadership style

I want to acknowledge that document describes a leadership style that can be long-term oriented. And may not match with contexts where we need to deliver near-term impact.

Ideally we are setting up near-term milestones as stepping stones for longer-term goals. From a planning perspective, we are intentional about resourcing efforts that return results in-month vs in-quarter or in-year.  
On occasion we shift into a more urgent mode of operation, though I'd like to maintain a healthy balance over the long and medium term

# My job around here

My goal is to help you become the best Product Manager or Designer you can be, this flows directly from my leadership philosophy. I focus on providing coaching, context, and air cover. And as much as possible, making work fun and a bit more human.

I believe doing things end-to-end. Meaning if there's something that is hindering you, I'll try to help even if it _technically_ falls outside my domain. I hope you take a similar approach.

# Imposter Syndrome is real

Imposter syndrome is very real and it happens to you, me and CEOs everywhere. It can be hard to talk about. Personally, I think it is weird when I speak to people who have never felt imposter syndrome, but that is a separate topic. You don't have to talk about it with me, but you're more than welcome to. Please do let me know if you're feeling underprepared or overwhelmed.

What I've found most helpful is having a team that supports each other. So I value collaboration over competition. (I don't believe in breeding [super chickens](https://www.ted.com/talks/margaret_heffernan_why_it_s_time_to_forget_the_pecking_order_at_work)) 

# Good form really matters

If you lift an empty box, you may not worry about your form. Lift a few heavy boxes, and you’ll pay more attention. If you’re lifting heavy boxes every week, you are likely to get a coach. We do a hours and hours of heavy lifting every week—so good form really matters.

While good form is task-specific, the principles are similar for both product work and weightlifting. Strong fundamentals let you apply the right approach across different situations. And efficient, repeatable habits help prevent burnout or self-doubt. 

Every quarter we will set aside an hour to talk work on your career growth. Often we'll pull out the company career ladder and use that to see if there are places where we need to improve fundamentals. 

As a note, it is common to grade harder as you level up. I think it is because it is easier to see how much you have left when you’re close to the finish line. So sometimes you’ll grow a lot in a competency but give yourself a lower rating. Totally normal.

# Feedback

Good form isn’t just about repetition, it’s also about getting regular feedback. Most of our growth comes from giving and receiving feedback, and practicing what we learn.

I want to emphasize that I don’t have a monopoly on feedback or teaching. On this team, everyone teaches and learns from one another.

I try to give feedback in context and, whenever possible, in person. If you ever get feedback from me that isn’t helpful—for whatever the reason—please let me know.

Here are some real examples of feedback I’ve given to team members right after meetings, shared here with their permission:

**Feedback after Sprint Planning:**

![](https://s3.amazonaws.com/managerreadme/images/Screen Shot 2019-02-20 at 10.24.02 AM.png)

**Feedback after presenting a project to cross-functional leaders:**

![](https://s3.amazonaws.com/managerreadme/images/Screen Shot 2019-02-20 at 10.31.50 AM.png)

For myself, getting feedback via Slack often works best. But I am flexible. I care more about speed than the channel. So I’d rather get a quick feedback shortly after, than wait a week for our next 1:1.

## Design Crit

I admire [Figma's stance](https://www.figma.com/blog/design-critiques-at-figma/) on design crits: 

> Our driving philosophy is the belief that critiques should be motivating, not intimidating. Helpful, not discouraging.

Design crit is a shared responsibility. I very much would like your help making sure we reach that bar. If we ever miss that mark, please let me know. It can be in a 1:1 or on Slack.

At its core, crit is not a forum for approval. It is a place to sharpen thinking, explore alternatives, and make sure we're solving the right problems effectively

**How to Show Up as a Presenter**

Your role as a presenter is to frame the problem and explore design solutions. You don't need to overpolish. Rough work is welcome! A few things I've found often helpful to guide the conversation.

- Context
  - The user problem we're solving
  - Where in the workflow are we (What happens before? What happens after?)
  - Relevant data, constraints or legacy decisions

- Goals
  - User Goals
  - Business goals

- Design Phase 
  - Early and exploring
  - Converging onto one idea
  - Shipping and iterating

- Framing your asks for feedback
  - Specific areas of uncertainty
  - Tradeoffs to be made

**Showing up as a participant**

- Focus on the problem, not the artifact or mechanism
  - Good Example: "I worry users going through this flow won't be very technical. Can we simplify the language and the call to action?" 
  - Bad example: "The CTA is too long"

- Give positive and constructive feedback. 
  - Crit sessions where everything is great are sometimes the least productive.

- Label your intentions. 
  - "This is just an idea"
  - "I want to strongly encourage..."
  - "This is a contradiction with our existing design system"

# Fostering bandwidth

One of the things I often ask is, “How are you on bandwidth?” I also ask in our weekly team meetings, not because of performance concerns, but to make sure everyone is supported. It’s a quick check-in and you'll see my bandwidth too.

I have found that it is easy to accidentally overload someone or lose track of how long they have been operating at, near, or over capacity. And when you are exhausted, good form is the first thing to go. It can very quickly all unravel. It often takes at a week or two to implement changes that reduce your workload so we need to monitor proactively.

# New Things

I believe learning happens when you consistently step a little out of your [comfort zone](http://invisiblebread.com/2016/12/do-it/). So I encourage you to try new things, hard things, silly things. Even on occasion a this-is-probably-a-stupid-idea thing. These experiments  are important!

It is ok to [be a beginner](https://vimeo.com/24715531).

# 

# Work in Progress

I’ve reported into managers who expected everything to be highly polished before I shared it with them. That is decidedly not my style. If you bring me the final draft of your one-pager or presentation, my first feedback will probably be: “Loop me in earlier next time!”

I prefer to give feedback and input early and often. I want our process to be collaborative and feel like we’re working together to refine your work before sharing it more broadly. My goal is to support you from start to finish, not just review and approve at the end.

By the way, not obligated to act on every piece of feedback I give. You’re the owner of your work and responsible for the outcomes.  

![](https://s3.amazonaws.com/managerreadme/images/do as i say.gif)

  

# Let's Talk

I am often running around doing who-knows-what. But there are very few things more important than being available if you need to talk. If you see time on my calendar, feel free to book it. If nothing’s open just Slack me. I will evict something to make time.

If you’re ever unsure about adding me to an email, tagging me in a doc, or @mentioning me on Slack, go for it. I’d rather be looped in early and often. I find it much easier to ask for less than to ask for more. 

# Responsiveness

In general, you are not expected to respond to email or Slack outside of working hours. I try to use schedule send for email or Slack messages I draft after hours. I occasionally slip up, and want you to know that I am not expecting you to be perpetually online.

I used to say that in the very off chance that I need to interrupt your personal time, I will be explicit and use ALL CAPS. However, I actually haven't had to use that and I don't expect to in the foreseeable future.

## Pronouncing Names

I'd really like to pronounce your name correctly. First name, last name, all of it. I know it can be awkward, but it really is ok to let me know if I'm mispronouncing it. You can think of it like a coaching exercise if that helps. You can let me know real-time or pull me aside later or send me a Slack message. This is true even if we are past the "new" phase or if I was pronouncing correctly but suddenly reverted. 

Conan O'Brien was [mispronouncing Steven Yeun's name](https://www.youtube.com/watch?v=xtc-1WbF9PE) for years and before discussing it (humorously) on television. I think it's better if we don't wait quite so long.

# 1 on 1s

I believe 1:1s are your time and you should be setting the agenda. We can briefly discuss status of projects, but ideally we're diving deep into 2-3 topics to make sure we're aligned. We will separately have quarterly career conversations where we just talk career development.

You may use whatever format you'd like for our 1:1 doc. I created an [example doc](https://docs.google.com/document/d/e/2PACX-1vTBtpLsBmICKk_ej4QSDwHJtlQg_E9GS0lOc5IXMCpneHhJ4x37zXB_DxK8c108Jj1M4HxXtAq7YOx7/pub) you can use.

# Where to focus on your first 90 days?

This broadly speaking how I think about onboarding in the first 90 days. 

- The first 30 days is getting to know the product and the users (both present and future).
- The next 30 days is getting up to speed on what the team is doing and why.
- By your 90-day mark you should be telling me what you plan on doing by the 120-day mark. I'd like you to be confident in forming a point of view on the work, your product area and how to proceed.

You should have individualized onboarding material that will help walk you through your team, op-mechs, and tools.

# 

# Reading

- [Questions for our first 1:1](https://larahogan.me/blog/first-one-on-one-questions/) by Lara Hogan and think about your answers 
- [Why You’ve Never Been In A Plane Crash](https://asteriskmag.com/issues/05/why-you-ve-never-been-in-a-plane-crash) by Kyra Dempsey about Post-Mortems
- [Personal Best](https://www.newyorker.com/magazine/2011/10/03/personal-best) and [The Bell Curve](https://www.newyorker.com/magazine/2004/12/06/the-bell-curve) by Atul Gawande
- [Priorities in a time of plenty](http://www.asymco.com/2016/02/16/priorities-in-a-time-of-plenty/) by Horace Dediu
- [Good Pressure, Bad Pressure](https://medium.com/the-year-of-the-looking-glass/good-pressure-bad-pressure-c8d9ff4530a5) by Julie Zhuo
- [Grow the Puzzle Around You](http://foundersatwork.posthaven.com/grow-the-puzzle-around-you) by Jessica Livingston

![](https://s3.amazonaws.com/managerreadme/images/giphy.gif)