Learnings from Calibrate 2017

In September, I was in San Francisco to attend Calibrate 2017, a conference for new engineering leaders. I was joined by a coworker for this one day conference where we had the opportunity to listen to nine talks by senior engineering leaders and network with other engineering leaders (old and new) from many different companies. In this post, I will share some of my learnings from the day. I will post the talks when they become available online; in the mean time, I apologize for any inaccuracies in my recollections and interpretations that may exist in what I have shared here.

The opening keynote was “The New Manager Death Spiral” by Michael Lopp (Slack, VP of Engineering), based on his article of the same name. The first major point I drew from his talk was to delegate aggressively. Instinct may (wrongly) suggest that delegating work is giving up power. As a manager, you need to learn to ask for help and delegate more than is comfortable. As a manager, your job is no longer merely to get things done; your job is now to get things done at scale. Furthermore, delegation provides the opportunity to learn and earn trust from your team; delegating projects beyond an individual contributor’s current skillset shows them that its okay for them to fail in front of you (so long as you help them get back on their feet and get better) and it shows you their capacity to tackle complex work and grow to meet the challenge at hand. The second major point I observed was to build trust with your team. Every action you take is either building or eroding trust with your team. Engaging in healthy argument in front of your team shows that it’s safe to engage with you in open dialog. But unless you let others change your mind, you’ll be eroding trust with your team. Similarly, to prevent eroding trust with your team, you need to learn to say no to requests; saying yes signs the entire team up, not merely you, for additional responsibility. If you notice that your team is talking to each other or people outside of the team instead of you, it’s an indicator that you need to build trust with the individuals on your team.

The first talk was given by Jared Jordan (Evernote, Sr. Engineering Manager) and was titled “Climbing the Mountain of Leadership Productivity”. For me, this talk seemed to center around communication. Building effective teams requires you to learn a lot about the individuals on your team. You need to learn about their strengths and weaknesses; their mission and motivators; what success looks like for them, and where the core of their problems lies. There is also much you need to communicate to your team members. To help them improve, you need to illuminate their blind spots. When changing direction, you need to be able to set expectations and convince them that it is important. To alleviate stress, you need to demonstrate calm as your team will look to you as a role model. For feedback on how you are performing as a manager, Jordan gave a couple of suggestions. You can ask your manager to have skip level 1:1s with your direct reports to ask for feedback on your performance. During 1:1s with your direct reports, you can ask them questions such as “What frustrates you?” During your 1:1s, you can also ask for each of you to rate the quality of the 1:1 and then share your rationales for that rating. One last point I drew from this talk was about planning. When planning, he suggested taking a tiered approach and knowing what form the worst, okay, and best acceptable versions of your plan may take; this gives you some flexibility and helps you to prepare for different scenarios that may take place along the way.

Next, Shivani Sharma (Slack, Sr. Engineering Manager) gave a talk on “Navigating Difficult Conversations”, inspired by Douglas Stone and Bruce Patton’s Difficult Conversations. In her talk, she recommends being direct when having difficult conversations, though before having these conversations, it’s important to establish mutual respect with this person, to be able to empathize with them, and to be able to maintain an equanimous composure throughout these conversations. Once this foundation has been established, she outlined a five step process to have these difficult conversations. First, you need to prepare for these conversations. Second, you need to practice this conversation with another manager or employee, and perhaps ask for the observations of a silent observer. Third, you need to have the difficult conversation. Fourth, you need to problem solve with this person to address the feedback delivered. Fifth, you need to reflect on how the conversation went and how you can improve in the future.

Jill Wetzler (Lyft, Director of Engineering) gave the next talk, “The Inclusive Leader: Tips for Developing Diverse Teams”. My interpretation of her talk focused around trust, as framed around inclusivity. She stated that we must grant trust to those we lead, but at the same time, we must assume that we haven’t yet earned their trust. She walked us through three ways to earn trust: safety, feedback, and advocacy. To ensure people feel safe, ask personal questions to show that you care about them as people. If you screw up or offend someone, apologize but stop there; research what you did wrong and learn how you can do better–don’t try to excuse or explain your past behaviour. She also suggests that if someone suffers harm, you should allow them to determine the response; personally, I think I’d need to hear more about this before I agree with it myself. To build trust through feedback, she mentioned that we need to stop fearing human emotion; if someone responds negatively to feedback, ask if they’re okay, but ultimately your job is to give feedback even when it’s difficult. When giving feedback, she suggested structuring it to supply a concrete observation, the impact it had, what the expectation was given their relative level, and an offer to assist them in addressing this feedback (taking an active role in their improvement). Additionally, she suggested looking for biases when giving feedback: would you give the same feedback to someone of a different gender/race/etc? Are you asking someone to be inauthentic? Is your feedback making a statement about their behaviour or about their person? When receiving feedback, she suggested asking for specifics or concrete observations, acknowledging the feedback publicly and expressing your gratitude that it was surfaced, work to improve on the feedback, and follow-up with them to show that you take their feedback seriously. Finally, when it comes to advocacy, she recommends that you ensure stretch assignments are allocated fairly and that you don’t make people prove themselves repeatedly. Also, she recommends considering sponsorship of disadvantaged employees, such as those who may be overlooked or those who may not have the courage to speak up for themselves. By sponsorship, she encourages behaviours such as fighting for their promotions, volunteering them for stretch assignments, sharing their interests with influential people, frequently mentioning their name in relevant conversations, etc. in effort to help reduce those relative disadvantages.

Next, Rod Begbie (Dropbox, Engineering Manager) gave a talk on “Engineering Management Anti-Patterns”, in which he listed the following common anti-patterns:

  • The Cloner (assuming everyone learns the same way you do)
  • The Decider (making decisions on behalf of the team; not communicating the rationale behind decisions)
  • The Buddy (failing to deliver difficult feedback)
  • The Asshole (giving ineffective feedback in an unprofessional manner)
  • The Joker (often making jokes and/or sarcastic comments around the team without realizing not everyone takes these comments as may be intended)
  • The Wolf-Crier (blowing problems out of proportion, or tackling problems based on complaints without first validating with your own data)
  • The Shit Umbrella (sheltering your team from all feedback and noise, preventing them from making informed decisions)

Michael Ruggiero (Sr. Engineering Manager) from Twilio delivered the next talk, “Daydream Believer”, which, for me, as I recall it, focused around performance management. Ruggiero suggests finding out what motivates people by asking them about where they see themselves 5, 10, and 30 years from now, as well as 10 things they really want to do that don’t involve their current role. He moves on to say that people need feedback more than they want advice, and suggests using the SBI feedback model (which illustrates the specific situation, describes the observed behaviour, and determines the impact that behaviour had). When a performance issue arises, he suggested against using personal improvement plans. Instead, he advocated for giving them a non-critical, non-trivial project while being transparent about the growth you would like to see from them with the project; it’s also crucial that you give them relevant, regular, and direct feedback throughout this project. Before firing anyone, he suggests checking three things. First, have they received adequate feedback and been given the opportunity to improve on that feedback? Second, is their performance negatively impacting the rest of the team? Third, have you gotten a second opinion on their performance?

“The Art of the Pre-Meeting” was the next talk as presented by Karen Catlin (Adobe, Former VP of Engineering). This talk was about influencing decisions when you lack authority. The art of the pre-meeting refers to socializing an idea to key stakeholders to build support before a decision meeting. Attend related meetings and ask stakeholders for feedback on how to improve your idea. Finally, she recommends huddling/revisiting with each of these key stakeholders before the decision meeting to review with them the game plan to advance your idea.

Nick Caldwell (Reddit, VP of Engineering) gave a talk titled “Tripling Down Without Losing Control”, which focused on scaling an engineering department. As the department scales, he mentioned the need to build trust through methods such as leadership offsites, delegation of work, etc. He also mentioned the need to trust, but verify; one shouldn’t simply be handing things off and abdicating responsibility. There is an increased need for definition and specialization in roles and responsibilities as the department scales. Also, there is an increased need for process at scale. This process can take the form of managers, tools, etc. But one needs to be cautious of process junkies–the priority should always be delivering value to your customers. Furthermore, having minimal process ensures that it will become part of the department culture over time. He also mentioned the need to build a sense of urgency. To do so, he recommended against artificial deadlines. He suggested clear communication on why projects are important. He also suggested connecting engineers with their users, and ensuring that they understand how their work benefits these users.

The final speaker of the day was Marcy Swenson (Startup Happiness, Executive Coach), who gave a talk on “Winning at Growth Conversations”. She echoed several of the other speakers in mentioning the importance of being curious about where/how people want to grow. She said it’s important that when talking about promotions, it’s important for people to understand that a promotion is a recognition of someone who is creating more business value; in fact, she mentioned that realization of this fact is key to career success. When it comes to growth conversations, Swenson points out that the three most common skills to be coached include clear communication (which can be coached through role playing), empathy (which can be coached through discussions on why in a specific, real situation, a person said what they did, and how they may have been feeling at the time), and productivity (ie. prioritization and time management). Finally, when it comes to sorting people into management versus individual contributor paths, she had some questions to provide guidance. Do they see the world through code or through people? What types of books do they enjoy reading in their spare time? Do they usually describe colleagues through proficiencies or motivations? Through skills or beliefs?

And that brings me to the end of my summary of the event. I learned a lot, and hopefully through this post, there are some useful tidbits here for you as well 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *