I’m Grateful for My Parental Leave

I am so grateful that I’ve been able to spend six months with my family taking parental leave for the birth of my daughter.

I think it’s important to pause for a moment and acknowledge the fact that I’m highly privileged to receive this much parental leave in the United States. Most people do not receive anything comparable. The federal Family and Medical Leave Act of 1993 (FMLA) provides 12 weeks of unpaid leave for mothers, but only if they work for a company with 50 or more employees. In California, we have Paid Family Leave (PFL), which provides 6 weeks of partially paid leave. A few other states have similar protections, but it’s not enough for families to recover from the trauma of childbirth and to be in the right mental and physical health before returning to work. I’m grateful that a number of tech companies are leading the pack in terms of parental leave, and very fortunate that I’m able to work in this industry, but hopefully one’s ability to care for their child or partner will not be dependent on their employer in the future.

So, with all that said, I’m very grateful that my employer provides six months of parental leave to either parent, for childbirth or adoption. It’s an amazing benefit.

I’m grateful that I was able to bond with my daughter in ways that took far longer to do with my son. I started a new job when my son was 7 weeks old and for the first year he only ever wanted to be held or interact with his mother. I was fortunate to have some parental leave after starting my job that let me build up a bond and trust with him over time, but it was slow going and frustrating for both my wife and myself. In contrast, there are currently1 no moments that my daughter prefers her mother over myself. Every kid is different, and that could be enough variance as it is, but I relish the thousands of her smiles I’ve been able to provoke and take in.

I’m grateful that I was able to be the primary caregiver for my son while my wife was recovering. Every recovery is different: my wife’s recovery from my son’s delivery was relatively easy – we were hiking when he was 2 weeks old. With my daughter, my wife depended on me for months2, and if I had not been able to be home, we would have needed other family members to come live with us or hire help for part of the time.

I’m grateful that I got to spend so much time with my wife. We’re both working professionals who sometimes overwork and after just a few days into my parental leave, I extended it from 3 months to 6.

I’m grateful that this was paid leave, as my wife’s was entirely unpaid. Financially, we could not have both afforded to take the time with our daughter and so my paycheck enabled my wife to spend more time at home before going back to work.

On a professional note, I’m grateful that I had a chance to do some succession planning so that the people I lead would succeed in my absence. I’m also fortunate that the culture in my office is that people, including leaders, take time to be with their families. In the past 3 years, I’ve had two moments where there were 3 managers in a reporting line who were out on parental leave for any duration, and several months where my manager was out. Thanks to strong succession planning all around, these moments created opportunities for everyone to grow, be recognized, and try on different roles and responsibilities.

Parental leave is not a vacation or sabbatical, and I’m not going back to work as an especially healthier or more skilled employee, but I am happier. I’m excited to head back to work after this time in a *different* position. And I’m so grateful that I’ve had this opportunity to be a full time parent for the last half year.

If your company offers parental leave, take it. Your team will succeed without you if you’ve set them up for success. When your company reviews the benefits it offers, encourage your leaders to embrace parental leave as a strong value add. Encourage your politicians to do the same, and support their efforts. The time with your family is worth it and irreplaceable.

1: This is subject to change at any moment.

2: She reminded me about this while editing this post; I’m not trying to pat myself on the back!

Avoiding Mistakes with your Manager README

It’s been over a year since I wrote about my version of Manager READMEs and it’s been great to see READMEs and discussions about them crop up all over the internet. I shared some tips about successfully sharing information through documents on Twitter and here I’ll apply them to a Manager README to help you avoid some common pitfalls that can lead the document to hurt more than it helps.

As a reminder, my intent of a Manager README had two parts:

  1. Share expectations
  2. Build trust

A year later, I think it’s better to focus on the recipient’s value of this document, hence this new and improved intent:

  1. Share expectations to reduce their anxiety
  2. Build trust as they get to know you

It helps to have this intent as a guide when you’re assembling and editing your document. Some folks use the North Star as their guiding landmark metaphor, but I’m going to use this oak tree because I love it.

Oak Tree in the distance on the horizon.

Our goal is to provide soothing context to the people with whom we work. Here are a few things that you must do as part of the README delivery to succeed:

  • Iterate on the document before you send it, gathering feedback along the way;
  • Treat the document as one piece of a multi-pronged communication strategy; and
  • Keep the document alive and refer back to it.

Let’s break down each of these in order to get you closer to success.

You can’t measure successful communication by yourself.

This is a document like any other which means you need to iterate on it before sending it out. If you don’t have much experience with this, here is a short list of suggested folks to add to your editing crew:

  • A peer who knows you. They don’t have to work with you, but they should be able to recognize if your README is in your voice and if it is accurately conveying what you intend.
  • One or two of the intended recipients; one is good, two is better if you have highly divergent personalities among your recipients.
  • Your manager. You don’t want this context to be a surprise to them in case they expect something different of your team.

If you’re really not comfortable talking to these people at work, you can also talk to strangers on the internet. There are various communities (rands leadership, software leads weekly, managerreadme.com) who can help you know if your intention is coming across and also if the tone is friendly and inviting or aggressive and combative.

As a reminder, the purpose of this document is to provide enough context about working in your ecosystem to reduce their anxiety; you want to avoid sounding aggressive here. You also want to steer away from distracting content: your aspirations, flaws you’re trying to correct, and anything that doesn’t explicitly help your audience reduce their stress as they begin this relationship with you. Sharing your personal goals with your team is a terrific thing to do, but save that for another time. The tone of your README is especially important if you share it on the internet to be judged by potential future employers and peers.

Only after you’ve received feedback that you’ve successfully communicated the message you intended, and you’ve confirmed your message doesn’t make you look like a jerk (self-serving, out of touch, attention-seeking, unprofessional, or other like qualities), will you be a step closer to success.

Oak tree closer

Documents are necessary but not sufficient.

There are a few ways to use a Manager README: as an onboarding tool for new team-members, as an onboarding tool when you’re new, and as a way to verify team expectations. It’s valuable to write these things down in addition to having 1-1 conversations. Some people process information more easily visually, and for most new folks on the team they’ll have a firehose of information and will want to refer back to it. In any use case, it’s not acceptable to send a document with a comment reading “RTFM, kthxbye” and expect them to fend for themselves.

Develop a multi-platform communication strategy including your README, 1-1 conversation, and possibly a group conversation with your team. The point of this strategy is singular: you need to ensure that you and your audience have a common understanding of your content.

You’ll also want to frame these conversations appropriately. Don’t just dump this document on your team citing, “I read this thing on hackernews, here you go!” Talk to them about your intentions so that they can better understand if engaging with you on this topic is worth it for them. If your team isn’t into it, they may not agree about the value and it’s not going to help you succeed.

With the proper set-up and follow-through, you’ll be a little closer to success.

oak tree even closer

Context changes, so context-setting documents should too.

You’ve iterated on your README until you’re pretty sure that it will be received well. You shared the document and then discussed it with its recipients, answering questions and closing any information gaps until you’re all well aligned. Are you done now? Nope!

Things will change over time, and your README should change too. You can handle this in myriad ways. You can distribute copies of your README as new folks join, updating as each person joins and sharing the updates with the rest of the team. You can refer back to your README in team meetings and discuss how things are changing as you see it. You can incorporate aspects into your overall team on-boarding documents and let those update organically. It doesn’t matter what document organization system you use, so long as changes are documented and understood.

If your README becomes static, nobody will refer back to it and as your behavior diverges from the README it will no longer be a trustworthy source. You’re allowed to change what you want over time – I encourage it – but if you’re not communicating those changes well, you won’t get the results you’re looking for.

Communicate the change you want to see in an ongoing fashion and you’ll continue to help reduce stress on your team and keep you headed in the right direction to a successfully delivered README.

oak tree up close


Manager READMEs are intended to share context in order to reduce the anxiety produced by not having information.

To be successful, you need to do the following on top of coming up with your content:

  • Iterate on the document before you send it, gathering feedback along the way,
  • Treat the document as one piece of a multi-pronged communication strategy, and
  • Keep the document alive and refer back to it.

I hope this helps bring you closer to your team; let me know how it goes!

Want to learn more about Manager READMEs? Check out my earlier post and my conversation with Corey Quinn on Screaming in the Cloud!

2017 in Review

2017 has been quite a year. Looking back at my 2016 in Review post, here were my two biggest goals for 2017 and a mini retrospective:

  • Give away my Legos so that I can work with new ones.
    • Despite having the same title, I had a very different job at the end of 2017 than at the beginning. Sometimes it feels like I went from this to this.
  • Keep learning…
    • About my slice of the industry by hosting more meetups.
      • This didn’t happen at all.
    • About management via the Rands Leadership slack.
      • This was a triumph, and my network is stronger than ever.
    • About parenting and my kid by using my parental leave.
      • I spent a lot of time with my kiddo, using 26 days in 2017, up from 16 in 2016.

What follows are the stories behind these snippets, and a few other things that happened. Continue reading “2017 in Review”

Gender Diversity in Tech Reading List

This collection of lists is predominantly skewed towards gender diversity in tech. I don’t mean to imply that racial diversity is less important, but this collection sprung out of discussions related to James Damore’s memo.

This article by Rachel Thomas touches on many of these issues (with citations), and I recommend it.

We have a problem with institutionalized sexism in (at least) the tech industry which reduces gender diversity. This has multiple aspects:

Gender diversity in tech is important. Here are some reasons why:

Are there any links I should add? Please let me know!

2016 in Review

Let me just start with: Wow.

It’s been a huge year for all of us, full of changes and growth.



At the beginning of the year, I was looking for a new job in software engineering management. My wife was 5 months pregnant, and I was trying to figure out how rapidly I needed to get a paycheck. I was very lucky to be able to sell some stock options from my last company to tide me over for six months and allow me to find the job I wanted rather than settling for the job I needed. That has not been my experience in the past, and I don’t count on it being the case in the future.

Finding a management job can be tough.

Continue reading “2016 in Review”

Testing Databases

I work with Oracle and MySQL on a daily basis, and one of the questions I’ve often met is: How do I test my database controllers? This post explores that question using Java, but the principles apply to any language.

Most of the time, you can mock your controllers away. For example, if you have code that retrieves a data set, performs some manipulation of that data, and then visualizes it, there are several tests to perform:

  1. Did the data retrieve correctly? (i.e. was your query correct?)
  2. Did the manipulation algorithm work correctly?
  3. Did the visualization work correctly?

(2) is the one that most people test through unit tests. Hopefully you can test your manipulation methods by passing in a testing data set and evaluating the resulting dataset. If necessary, you can replace your controller with a mock/stub so that you’re not actually hitting the database.

(3) is the one that usually gets picked up by UI integration tests with frameworks like Selenium, Jasmine/Jest, etc. These tests can be fragile as UI changes and are usually very slow, as they require full-stack latency (POST your request, wait for the server to respond, inspect the DOM, rinse and repeat).

(1) is one for which I’ve seen the least number of tests (outside of integration tests), but they have some undesirable expenses: you have to have access to a database, and the left-over data might screw you (or your co-worker) up later. Continue reading “Testing Databases”