Presenting work, saying no, and professional development for design teams. Book Review: Liftoff! (Part 5)

In this article, I will reflect on chapters 11 to 13 of the book “Liftoff! Practical Design Leadership to Elevate Your Team, Your Organization, and You”. If you’re looking for a shorter and condensed review you can check out my TL;DR review. Are you interested in getting the book? Buy it via Rosenfeld Media’s website.

Chapter 11: Presenting Work

The eleventh chapter starts off with some useful guidance on how to prepare for your presentations. The topic of “prewiring” comes up pretty soon, which describes the act of getting people’s buy-in even before the meeting ever happened. This is a classic and effective technique to prepare for important decision-making meetings in any organization. Why would you ever hedge your bets, when you can simply stake the odds in your favor from the get-go? ;)

There is one piece of advice about sending out your materials for your meetings upfront as often as you can. This is something I disagree with, as I think you should carefully consider this for each meeting and decide based on your desired outcome for each presentation. I can easily recount various examples where I intentionally didn’t share my slides in advance to get more people to show up in the meeting. It’s not about “the great reveal”, but about the way people in your organizations usually behave. If you know that many people will skip a meeting because they’ve “read the report already” and you need them in the room, then you might want to give my suggestion a try.

There are a few bits about critiques to be found in this chapter too. Most of these points were fine, but one part didn’t really resonate with me. “It’s about the design, not the designer” is quite popular guidance, but to me draws too big of a separation between our directs’ behaviors and the work they are producing. Especially when somebody presents their work, I would strongly encourage you to give feedback on their behaviors and not just their output. The way one presents is a key skill for any effective leader or designer. Why wouldn’t you want to challenge your folks directly about their work, which also includes their behaviors, spoken words, and body language? Then again, this point was probably meant to separate the work from the person, which isn’t necessarily bad guidance either.

What follows is a list of pointers on posture, appearance, speed, and more. These are all sound pieces of advice. When reading this part I was inspired to also use this as an opportunity for feedback. “When you started your pitch with these words, your enthusiasm didn’t shine through.”, could be a very standard piece of feedback to give to one of your directs. I’m personally a big fan of the “parking lot” technique for meetings, so I’d like to give the authors bonus points for mentioning it.

I was surprised to read about how to handle meeting disruptors and how confrontational some of the advice was. The authors appeared quite timid to me throughout the book, but definitely had some direct and assertive ways to deal with such incidents. I can’t remember a meeting when someone was asked to leave the room due to being a disruptor. I certainly think in most organizations this is your very last resort and might induce long-term damage to your relationship with others.

Overall, this was a useful chapter, but lacked a few resources for further reading. What was missing for me was the topic of videotaping your presentations to practice and improve. In my experience, this can really help to boost your public speaking skills and easily makes you aware of your flaws while presenting. This might feel over-the-top or uncomfortable to some, but it helped me to get my body language under control much faster than any other technique I’ve read about in this book.

Chapter 12: Saying No

I would like to say that I didn’t need to read this chapter, but that would be a big lie. Saying no is something that sounds trivial, but for some of us is something that we don’t feel comfortable doing. We’re here to help our team, peers, and boss, aren’t we? The authors share why saying no matters, how to do it, and what prevents some of us from being able to say it in a concise and professional way.

After reading this chapter you might think that “no” should be something you can rely on all the time. Unfortunately, this is not true. In most cases, especially to your boss, you are expected to say yes. Your own manager expects you to take on work even if your desk is full and find a way to get the most important things done. Additionally, nobody likes “naysayers”, especially when you’re the only one who can’t seem to find a way to support a key project for your organization.

The authors’ framework for saying no should always be in your back pocket in case a senior manager or executive might attempt a good old “swoop ‘n poop”. This is sadly all too common when high ranking managers feel the need to share their personal opinion in the form of feedback, without understanding the context and history of a design. This is exactly the time when you can shine by doing your homework and prevent a design effort from going sideways while you’re losing credibility in front of your team members. I also like to go back to other resources that might help in finding a way to say no to a project or request.

Chapter 13: Developing Designers

Helping your team achieve their professional development goals and learning new skills is your key responsibility. Recently I’ve been dipping my feet into the topic of assessing designers. I started off by reading Jason Mesut’s series on shaping designers. This was helpful, but not 100% actionable for me due to the lack of explanations for the skill levels.

I then completed a practical exercise for myself and one lucky designer in my team (if you’re reading this, reach out and I’ll buy you lunch :)). Our first attempt was quite fruitful, but didn’t happen without any confusions. These were mainly due to the fact that the descriptions for the competencies seemed quite dated and potentially incomplete for today’s designers. Following the framework from Dr. David Travis from his userfocus blog proved to be a good start nevertheless, as it gave us a great base to complete the assessments swiftly within a few hours. This sparked a long and open discussion on how we’d like to grow professionally. This then allowed me to support my team member’s growth with a better understanding and idea where her journey might lead.

Going back to Liftoff! I immediately noticed that the authors suggest doing assessments while giving designers the freedom to choose their own skill categories. This isn’t something I’d start with because it makes the process messier than it already is. Going through such an exercise isn’t as trivial as it might sound, since grading yourself or others might be uncomfortable if your relationship isn’t good enough. I missed a clear rating scale in the book, since this was very helpful during the grading activity and reflection I experienced with said team member. Overall, this chapter still gives a good overview of skill assessments, but I wouldn’t say the guidance is significantly better than what you can find online.

The authors continue with a popular topic: career ladders. What follows is a good overview of popular examples, what to look out for, and how to create one yourself. In my opinion, a critical point of information is missing though: compensation and top-level support. If you don’t tie the different levels and titles to compensation, then this whole system won’t be useful. You might think that this is obvious, but it’s very easy to create such a ladder in isolation compared to getting HR onboard, who might have their own compensation and job title projects on their desk. They might even feel threatened that you’re creating something that they might see as their responsibility. I would suggest finding allies and offering your help instead of creating something while demanding your HR partners to comply. Even if they’re on board, you will most likely need your management board to sponsor your efforts too.

The “meaty” thirteenth chapter proceeds with a segment about autonomy, which could be summarized in a much briefer fashion. Leaders should share what they expect from their team and why, not how a task should be done. During such an “autonomous execution” staying engaged can be easily achieved by asking open questions and listening attentively. Nothing too surprising, right?

Developing Designers comes to an end by touching a lot of professional development topics in a very shallow fashion. Ironically, I’ll end this review by providing rapid-fire impressions myself for a change. :)

  • Delegation: Very shallow chapter. So how do you delegate properly? I recommend Manager Tools guidance on this topic. By the way, delegating isn’t the same as assigning work, which isn’t mentioned.
  • Goal setting: Short and sweet. This is not about OKRs, but about setting goals for your employees. Few examples, but good ones.
  • Performance reviews: Absolutely basic and short. So much so, that I doubt this is useful to anyone. Again, I’d like to point you to the legendary performance review podcasts of Manager Tools on how to prepare and deliver them.
  • Feedback: One more big offender in terms of shallowness in this book. Not even two pages about giving feedback? I know there was a chapter on critique, but feedback is a key tool to talk about anything, not just WIP designs. Get Radical Candor or The Effective Manager instead.
  • Coach / Mentor / Sponsor: Interesting description of these different roles, but very unhelpful if you’re looking for actionable guidance on mentoring or coaching others.
  • Developing Managers: Short, but offers actually helpful points on how to develop your team members to become effective managers themselves. Definitely not sufficient though.
  • Developing Yourself: Less so about growing your skills than about always preparing for your next offer/role. There are a few good tips anyway, but don’t expect a “killer guide” on growing as a person or leader.

Phew, that was fun! There is one more article coming up on the remaining chapters. I know that only a few people have followed this series somewhat, so if you’re reading this: thank you!

Head of Product Design @ adidas Runtastic | A/B testing specialist | UX strategist & designer | User research practitioner | Lean & agile advocate