Tag Archives: management

Delivering a Tough Message

1 Reply

A colleague of mine was recently disillusioned with a significant change that had affected them. They’d had a 1:1 meeting with their manager, chatted amicably about work for 25 minutes, and then the manager had dropped the bombshell in the last 5 minutes of the meeting. There wasn’t enough time to discuss the change, the person felt betrayed, and the meeting ended on time and with many questions unanswered.

Many people avoid the tough topics, dislike conflict, and don’t want to deliver tough messages. Unfortunately, it’s part of professional life — and here’s what I’ve learnt about how to do it.

Open with the Facts

If you’ve got something important to share, start by sharing it. Anything else you say before it will be ignored, seem trivial in hindsight, and you may even look rude for not getting started with the important topic. Take a deep breath, say “I’ve got something important to share with you”, and launch into the punchline: outline the conclusion or outcome you want to share.

Be very clear about the facts. For example, “Thanks for meeting me today, Bob. Unfortunately, you were not successful in getting the manager role: I’ve decided to promote Jenny into the role of team manager, I’ve let her know, and we will be announcing it tomorrow”. Here’s another example: “Sammy, we will not be launching your team’s Wizzle product. As a leadership team, we have decided to cancel the project, and reassign you and your team to the Zazzle initiative”.

Don’t get interrupted during the initial discussion. Politely tell the person you’re talking to that you’d like to finish. You owe it to them to share the complete outcome before they get a chance to have a conversation about it. If you want to explain how you got to the conclusion, do it after you’ve shared the conclusion — it’s a huge mistake to walk through the blow-by-blow account of the decision making process while holding back what decision you’ve made until later.

Minimize the Surprises

If you can, don’t surprise people. Lay the foundations for an important conversation by discussing what you’re thinking in the weeks or months that lead up to the decision. If you’re canceling the Wizzle product, hopefully you’ve spent weeks with the team talking about how it isn’t going well, sharing your concerns, and being clear that it isn’t meeting expectations. It’ll then be less of a shock when you make a change.

Sometimes, you have to surprise people. If you’re telling your boss you’re leaving the company, you probably haven’t been talking about it to them for months. That’s ok.

Don’t hide behind others

If you made the decision, own it. Don’t say “we” when it’s actually “I”. Don’t blame others, and don’t bring others unnecessarily into the conversation. Have the courage to own what you decided — you might not be loved for what you’ve decided, but you’ll be respected for having the courage and conviction to own your decisions.

Managers often have problems owning performance discussions. I’ve heard the story many times of a manager saying to an employee “I wanted to give you a 4.0 but my boss decided to give you a 3.0, I’m really sorry”. In 95% of cases, the manager really did drive the outcome — they didn’t put the person at the top of their list, they didn’t unreservedly advocate for the employee, and they were honest about one or more performance issues. So, own it: “When I got together with the leadership team and discussed your performance, I decided your performance was what was expected of someone at your grade and I’ve given you a 3.0. We have an amazing team, and you’ll need to work on three things to be a 4.0 at the next review”.

Conclude clearly

Make sure the conversation has been clearly understood. If you can get the person to play it back to you, you’ll be sure that it’s been understood. If you’re worried that it hasn’t been understood, you should follow it up with a written communication (an email is perfect) soon after the meeting. Indeed, this is often a good idea — I do this when I’m worried there’s room for misinterpretation, or that the decision or actions won’t stick how I want them to.

Above all, be courageous

You’re got past the initial discussion, you’ve conveyed the tough information you decided to share. Don’t change your mind. Don’t be intimidated. Don’t lose your cool. Nothing good ever comes of reversing a tough message in the heat of the moment.

Be calm. Courage doesn’t imply sternness or (worse still) yelling or anger. Be serious, but be rational, empathetic, and fair. Make sure you listen and be respectful. Do unto others what you would have them do unto you.

Good luck. See you next week.

Writing a Performance Review: Part Two

2 Replies

I blogged recently on the topic of annual employee performance reviews. This post continues the story and discusses what I’ve learnt about writing performance reviews.

The Basics of a Review

As I discussed last time, the reviews I deliver typically include a few elements:

  • Sharing company-specific performance ratings
  • Explaining what went well
  • Explaining what didn’t go well
  • Sharing expectations of the employee as the manager

Structuring a Review

I write reviews in paragraph form and hand over a printed copy. I follow up with an electronic copy.

I’ve experimented with several different approaches, and have settled on the following general structure:

  • One paragraph summary of the review: I thank the person for their contributions, communicate the company performance rating, and outline the structure of the document. It’s a good idea to disclose the rating early in the document, it gets key information out of the way and allows the person to focus on really reading the rest of the document
  • A section that describes “what went well”: A series of paragraphs that explain the person’s contributions, why they were valuable, and any suggestions you might have as to how they could be even better. I’m typically reflecting on the goals we agreed when I’m writing this section, as well as reflecting on what I’ve seen, heard, and feedback I’ve received; I discussed last time the topic of how to solicit feedback
  • A section that describes “what didn’t go well”: Same deal, but this time focusing on where there are problems, why they are problems, and what you’d like to see done differently
  • A section that describes “areas for focus”: A few, specific things you’d like to see that are areas for growth. I’m often writing things about future challenges I see in the person’s career, and new skills or competencies that need to developed
  • A one paragraph summary and conclusion

I strive to be balanced. I work hard to ensure that neither the “what went well” or the “what didn’t go well” sections dominate. It doesn’t matter whether the overall performance was outstanding or below expectations, there are always constructive, useful things you can say about performance. My observation is that most people want to hear where they can improve and what they can do better.

My typical reviews are around two pages in length. I’ve received much shorter reviews that were valuable and longer ones that weren’t. I’m not sure length matters — but substance does.

Reviews are important. They’re often tied to financial rewards, they’re written (and so they have gravitas), and they’re usually part of a formal process. It’s therefore important to write down honest, important, business relevant feedback.

Many managers struggle with being transparently honest in reviews. It’s hard to be critical, it’s hard to confront performance issues, and it’s hard to tell someone great that they can be better. As a manager, it’s your obligation. It’s a topic for another time, but this process becomes much easier if you’re honest in every 1:1 about how you see the performance of your employees — the review should never be a surprise.

An Example Summary

Here’s an example of the opening section that I might write:

Sam, thank you for contributions in 2012. I have rated you as <performance rating>.
You made positive contributions to building our next generation platform, hiring and leading the enablement team, and developing your skills in software engineering management. Well done! You did not deliver the new enablement engine on time, have not partnered successfully as we need to with the product team, and you need to continue to grow your presentation skills.

That’s it. A short, to-the-point summary of the document. It doesn’t have to include everything you discuss later — just the key points that you want to highlight, and those that were critical to your decision on the performance rating.

An Example What Went Well Section

I start my “What Went Well” section, imaginatively, with the heading: What Went Well.

I write a few paragraphs, at least as many as the highlights I’ve picked out in the summary section I discussed above. Each of the paragraphs explains what I think and why, and likely includes quotes from others (that I gathered through the feedback process) that support what I want to say. When I’m writing this section, I’m looking at the feedback I gathered from the person’s peers, reports, and other key people that the person interacts with. I’m also thinking about goals and results.

Here’s an example:

Project Alpha exceeded its goal of increasing the business by 3.5% in Europe. Several folks commented on this including examples such as “Thanks Sam for driving the European business, it’s been a pleasure partnering with you” and “You’ve really turned around the story in Portugal, you should feel proud”. It was exciting to see you delivering for Europe, particularly given the language complexities. In particular, it was good to see the successes in translation and price normalization. You also shipped some great work in North America (but missed the goal, that’s discussed later in this review).

Here’s another example:

You’ve made excellent progress on communication and meeting skills. We talked in our review last year about being more concise, letting others communicate, and letting others drive meetings. I can see great progress here – thanks for taking this feedback and working on it. People are noticing too: “I enjoyed working with Sam this year, he’s really developed into a solid communicator”.

An Example What Didn’t Go Well Section

Call me imaginative: I start this section with the heading “What Didn’t Go Well”. It’s ok to call a spade a spade, but you could also use a euphemism if you like such as “Opportunities for Improvement”.

I use the same structure and format as the “What Went Well” section. Paragraphs. One per major point. At least as many as the summary points I made in the introduction.

Here’s an example:

We have had great discussions last year about updating the headcount spreadsheets in a timely fashion, and you reflected in your self-assessment that you’re not doing this. I’d suggest you focus on time management and prioritization — I will support you in developing these skills, including helping you find the right courses you can take. I expect that this is the last year we’ll be having this discussion, and that we will have solved this problem before our next review.

And one more:

I saw development in your ability to think strategically this year, but you can continue to grow in this area. A few people reflected in their feedback to me that you could have taken on more strategic initiatives, or ran with some of the more challenging problems that you saw.  In many of the meetings you’re in, you seeing technical problems that remain unsolved and that you could play a part in driving. You should focus on driving one or two strategic, significant changes this year.

Both of these examples end with a clear call to action and clear expectations. Be clear about what it is you want to see happen.

Areas of Focus

My areas of focus section (titled “Areas of Focus” in my reviews) lists things that I think the person should focus on. They’re not necessarily weaknesses, they’re more often areas where I think the person will need to develop or focus for the future. It’s my advice section.

Here’s an example:

  • Continue to focus on presenting material at the right level for the right audience
  • Many folks worry about your work/life balance (and the example it sets for others)
  • Hire folks who complement your skills

The conclusion

I keep this short. I emphasize the key points, and wrap up with best wishes for the next year. Here’s an example:

You will have a challenging year in 2013, Sam. But I am confident you will do great in the new team, new role, and with your new challenges. Stay focused on strategic thinking! Good luck!

See you next week!

Writing a Performance Review: Part One

3 Replies

Many companies formally review the performance of employees, and most include a written performance review. This post is the first of two posts where I discuss what I’ve learnt about writing performance reviews and offer a few tips.

The Basics of a Review

Reviews typically include a few elements:

  • Sharing company-specific performance ratings
  • Explaining what went well
  • Explaining what didn’t go well
  • Sharing expectations of the employee as the manager

A manager should at least annually deliver a written review and talk it through in a 1:1 meeting that’s focused only on the review. Some managers send the review, say, an hour before the meeting to give the employee time to read it before the discussion. Other managers print and hand out the review at the beginning of the meeting, and give the employee time to read before the discussion begins. I personally prefer the latter approach — it allows me to react in real time to questions and gauge what’s important for the subsequent discussion. The former approach has the advantage that it gives the employee time and space to read the review.

Gathering Data

Before I write a review, I gather content. There’s a few places I go:

  • Notes, recollections, and emails that reflect on the employee’s performance against their agreed goals. I have regular, weekly or bi-weekly 1:1s with my direct reports, and in these we often discuss performance
  • Reflections from the person I’m reviewing. You’ll find it very helpful to ask your direct report to write down their reflections of their performance and send them to you
  • Reflections on the person I’m reviewing from others. I ask all of the person’s direct reports, peers, and selected other people who they interact with to give me their reflections

Start, Stop, and Continue

Here’s how I go about gathering feedback on the person I’m reviewing. I send an email like this to their reports, peers, and selected other folks they interact with:

Hello,
I have found that gathering feedback on the performance of my direct reports is one of the best ways to assess how they are doing. Please provide your candid feedback, which I will summarize and share anonymously.

To keep it simple, I am asking you to email me three things each that <name of person> should:

  • start
  • stop
  • continue doing

I will take all of the feedback and synthesize it into the review so your comments will be kept confidential.

Please provide your feedback by <date I need it> to <my email address>.

Thanks, Hugh.

Synthesizing the Content

Once I’ve got the replies, I look for consistent themes, great anonymizable examples, and points that help me reinforce the messages I want to share and those that align with the personal reflections of the person. I often include near-direct quotes from the responses, I’ve found they are powerful ways to convey messages. I frequently rewrite or rephrase the quotes so that language styles and quirks don’t give away who contributed the feedback.

By the way, it’s also useful to ask the person you’re reviewing to write their reflections in the Start, Stop, Continue model.

Next in the Series

In this follow up post, I share what I do next — how I put together a review and share it with the person I’m reviewing.

6 secrets for successful small teams

3 Replies

Managing small engineering teams is fun. You’re close to the technology, close to team that’s writing code, and solving problems hands-on. Don’t get me wrong: it’s satisfying, rewarding, and impactful to manage large teams, but there’s nothing like being in the details and seeing a product come together. You lead a small team, by being an example that folks can follow; in contrast, you manage a large team. It’s different.

Here’s six things I’ve learnt along the way about leading small teams. This post was inspired by Greg Brockman’s 6 secrets for building a super team — Greg explained how to hire a small super team, and this is my sequel on how to make it world class.

1. Lead by Example

I’ve seen newly-minted leaders of small teams fail. One of the common reasons is they stop doing what they’re good at: being technical. And when they stop, engineers stop following them. Engineers want their leaders to be driving engineering, working on the hardest problems, and setting an example.

Great leaders of small teams are at least 50% technical, they spend more than half of their time writing code, creating designs, proposing architectures, doing code reviews, solving technical problems, or otherwise getting deep in the details. They know everything that’s going on in their team — they’ve got the right people working on the right problems, they’re driving the people at the right pace, they’ve holding people accountable for doing everything the right way, and they know the teams’ designs and code like they know their own. In the other 50% or less of their time, they’re passionate and focused on process, people, teams, and leadership — they have just the right amount of process to keep the team on track and happy, they’re managing their dependencies, and they’re spending time growing their people and team.

2. Set clear, simple goals, with clear, measurable metrics

You won’t be successful if you don’t know what success is. It’s surprising how many teams build a product without a way of measuring whether they’ve been successful, deciding when they need to be successful, or even without knowing where they’re headed. You should always start with goals and metrics.

Let’s suppose you’re leading the home page team at a major web company. You’re charged with leading a team of seven engineers, who together build all of the components on the page, and deliver everything from the platform pieces through to the pixels. You know who your competitors are, and you’ve got some great ideas on how to build a better home page than they’ve got. You’ve thought about this — you know that owning the home page means you’re the front door to the store, it’s your job to get the customers inside so that they can use all the products and features that the other teams have built.

I’m a fan of having two or three clear goals and objective ways of measuring them. You might decide that success is having the acknowledged leading home page on the web. How might you measure that? Here’s two or three ideas: first, you have lower abandonment than your competitors (lowest percentage of visitors who don’t click anything); second, you win a head-to-head taste test against your competitors at least 2/3rds of the time; and, third, your page is faster to load that your competitor’s. These are all criteria you can measure on a daily or weekly basis, and you can track them and share with the team.

If you want to create drive, fever, and passion in your team, consider setting a Bold Hairy Audacious Goal (BHAG) date. Decide that you’re going to have the best homepage by January 1. Put a graph up on the wall with the months on the x-axis and your objective, measurable success criteria on the y-axis. Every week, update the points for you and your competitors. Huddle the team around the graph, and work together to make success happen. You’ll be surprised how effective this can be in firing up your team, and getting creative ideas into the product.

3. Balance the portfolio

Small successful teams spread their bets. They have many small projects going on, and a couple of large ones. Importantly, the vast majority of the projects are impactful — they’re projects that are pushing the team towards their measurable goals. Good teams avoid doing work that doesn’t matter.

Why are small projects important? Well, first, they mitigate the risk if a large project gets delayed or doesn’t hit paydirt. Second, they give the team a real rhythm: every week there’s something new going out that moves the needle, and the team stays fired up and on track to their goals. Doing only large projects can be a death march — and it’s hard to keep teams fired up on one of those.

4. Meet the team

You have to know your team to be a successful leader. You need to understand the people who work for you, and customize your style to get the most from them. Some folks will need more advice, others will need to be pushed, some will rebel if you push, and some just need to know the goals and be given plenty of space. There’ll always be some conflict brewing, and everyone will have something on their mind that they want you to know — and the only way to find it out is to meet them regularly, really get to know them, build trust, and help them be successful.

I recommend a weekly 1:1 that’s at least 30 minutes, and not focused on the day-to-day. Ask questions in a 1:1, and leave plenty of white space in the conversation for the person you’re meeting to talk to you. Listen to what they say, and ask more questions that explore what they’re saying. Most importantly, be open and honest — say what you think, and it’ll likely work both ways. Conversation is key to being a successful leader.

5. Keep it simple

When the team’s small, you don’t need onerous process, too many meetings, or too much email. I’d recommend a daily stand-up meeting as the basic tool to stay in touch: go around in a circle, and ask each person to say what they did yesterday, what they’re planning on doing today, and anything that’s blocking them from succeeding. Buy some hour glass timers, and make sure everyone stays under two minutes. Don’t allow point-to-point conversation, the meeting is strictly for broadcasting information (the 1:1 or 2:1 conversations can happen after the meeting). Tell the team you will buy them coffee and food if the meeting goes over 20 minutes, and work hard to keep it under 15. Keeping it tight on time and high on information content will ensure you get good attendance and participation.

My hour glass timers. A large one tracks meeting time (20 minutes), and the two smaller ones are for individual speakers (2 minutes each) — one for the current speaker, and one for the next speaker.

When it comes to tracking a project, I recommend simple (and so do most of the people I work with). If it’s six to eight people, you can track projects with sticky notes, a whiteboard, and a camera for recording key information. I’ve also used a simple spreadsheet, where engineers can record the list of tasks that they’re working on and the time they will take, and the sheet automatically burns down the time remaining and computes completion dates. All the engineer has to do is keep the list of tasks in the sheet accurate, and the time estimates up to date, and the rest takes care of itself. In either case, simple is the key — very low overhead for the engineers, and pretty simple for the leader.

6. Keep it small

What I’ve shared applies to teams of 4 to 8 people that work for one leader. Beyond that, the team isn’t small anymore — you’ll find it nearly impossible to be more than 50% technical, and still get in the 1:1s and run an effective team. I’ve met a few people who can do it, but they’re usually super experienced or have super experienced teams.

We’ve all heard the stories of small startups with a few employees doing amazing things (think instagram or pinterest). It’s often because they’re lead by technologists, who’ve set crisp goals, spread their bets, kept it simple, and know their teams well. If you get your small team leadership right, your small team can change the world — and small teams do regularly change the world. Good luck.