Monthly Archives: April 2021

Book Notes: Good Strategy Bad Strategy

Good Strategy Bad Strategy: The Difference and Why It Matters by Richard P. Rumelt
My rating: 4 of 5 stars

A strategy is a pathway to substantially higher performance.

  • The first advantage of a good strategy is that others fail to have a strategy
  • Good strategy tends to come from insight into an organisations strengths and weakness
  • Bad strategy
    • Fluff – the illusion of thinking. True expertise and insight is making a complex subject understandable.
    • Failure to face the challenge – you need to identify the challenge or opportunities, analyse obstacles/bottlenecks to overcoming this then formulate a plan to overcome them. Good strategies are not quick – e.g. “improve underperformance” is not a challenge – underperformance is an outcome, the true challenge is the reason for the under performance. Good strategy is choosing which challenges are both worthy of pursuing and capable of being accomplished – if you don’t have a competitive advantage, don’t compete.
    • Mistaking goals for strategy – many strategies are a statement of desires rather than a series of actions or policies to overcome obstacles. Business is not simply a battle of strength and will, but also competition on insight and competencies.
    • Bad strategic objectives (subgoals) – effective senior leaders don’t choose arbitrary goals, they critically decide which goals are worthy of pursuing. Goals being overall desires and objectives being specific operational targets.
  • The kernel of good strategy
    • A diagnostic of the challenge – taking the complexity of the situation and identifying the critical aspects. Understanding “What’s going on here?”. Growth is not a strategy – growth by itself does not create value, growth is the outcome of growing demand for special, expanded or extended capabilities, the outcome of superior products or skills, reward for successful innovation, cleverness, efficiency and creativity.
    • A guiding policy – how to cope with or overcome the diagnosed challenge, using the specific sources of power:
      • Leverage
        • Anticipation – others expected behaviors, especially rivals – this is not some “high, medium, low” forecast but understanding what others would do in these situations e.g. if the price is high then others will try to enter the market
        • Pivot points – a natural or created imbalance e.g. pent up demand or competence in one field which can be applied to another
        • Concentration – rising from constraints and threshold effects e.g. the constraint on advertising budget and the threshold effect of TV advertising meaning that a small amount continuously is much less valuable than a lot in a short time.
      • Proximate objectives – a target that the organisation can reasonably hit. This resolves ambiguity, where the situation is volatile the objective must be more proximate to achieve it.
      • Chain-link systems – strengthening any link but the weakest will not strengthen the chain as a whole
      • Using design
        • Premeditation – a plan in advance, “winging it” is not a strategy
        • Anticipation – a judgement of others thoughts and behaviours
        • Design of Coordinated action – a strategy is designed with capabilities, not just making a decision. This design should provide powers derived from interacting and overlapping effects focused against a target.
      • Competitive advantage –
        • If you can produce at a lower cost than competitors or deliver more perceived value (or a mix of the two).
        • Subtlety arrives because costs vary with product and application, buyers differ in their locations, knowledge, tastes, and other characteristics – so an advantage only goes so far.
        • It must be hard for others to replicate to stay isolated.
        • Competitive advantage does not mean financial gain. An interesting advantage is one where you can increase its value on your own.
          • deepening the advantages – increase value to buyers or reduce cost (or both)
          • broadening the extent of advantages – taking the advantage to new fields
          • creating higher demand for advantaged products or services – either though more buyers or more demand from each buyer
          • strengthening the isolating mechanisms that block easy replication and imitation by competitors
      • Changes in the environment
        • Rising fixed costs – might cause the industry to consolidate
        • Deregulation – incumbents find it hard to adapt to the new world
        • Predictable bias – people tend to think there is infinite growth, but there is a peak and this is important to identify
        • Incumbent response – they are resistant and slow to change because of inertia and entropy.
          • Inertia of routine, culture and proxy (as in their current customers what what you currently sell so there is no desire to cannibalise yourself)
          • Entropy (gradual decline into disorder) e.g. product line bloat, keeping unprofitable stores etc
        • Attractor states – what is the direction of the market, you might not like it but resisting will be worse
    • A set of coherent actions – steps which together will accomplish the guiding policy

Book Notes: Product Management in Practice

Product Management in Practice by Matt Lemay
My rating: 4 of 5 stars

The practice of product management

  • Don’t become upset if your day-to-day work is not visionary and important-seeming, so long as it is contributing to the goals of your team.
  • Find ways to align, motivate, and inspire your team that do not require formal organisational authority.
  • Be proactive about seeking out ways that you can help contribute to the success of your product and your team.
  • Be a connector between teams and roles.
  • Get out ahead of potential miscommunications and misalignments, no matter how inconsequential they might seem in the moment.
  • Don’t get too hung up on the “typical profile” of a successful product manager. Successful product managers can come from anywhere.
  • Don’t let insecurity turn you into the caricature of a bad product manager! Resist the urge to defensively show off your knowledge or skills.

The core connective skills of product management

  • Embrace the uniqueness of the product manager role.
  • Pursue clarity over comfort to build your communication skills.
  • Seek out opportunities to solve organisational problems on the systemic level rather than the individual level. If the rules aren’t working, change them, don’t break them.
  • Don’t let the day-to-day organisational conflicts of your work pull you out of your user’s reality. Remember that what your company cares about and what your users care about are different things, and be a relentless advocate for the latter.
  • Remember that there is no work beneath you, and no work above you. Be willing to do whatever it takes to help your team and your organisation succeed.
  • Even if you don’t self-identify as a “technical” person, avoid saying things like “I’m not a technical person, so I could never understand that!” Trust in your own ability to learn and grow.

Showing up curious

  • Reach to people before you need them and say, “I’m curious to learn more about the work that you do.”
  • Be just as vigilant about getting to know people outside of your immediate team, and take the time to understand their goals and motivations before you need something from them.
  • Cultivate a “growth mindset” and open yourself up to learning from people whose skills and knowledge exceed your own.
  • Resist the urge to avoid situations that test the limits of your abilities or knowledge.
  • Embrace “the gift of being wrong” by choosing the plan that best meets your organization’s goals, even if it is not your plan.
  • Shake up the work that people are doing and cross-pollinate knowledge and skills to keep your team curious and actively learning.
  • Model the value of curiosity for your team and organisation.
  • Avoid saying “I’m too busy to deal with that right now” and other things that might implicitly discourage your team from asking open and curious questions that don’t have an immediate transactional value.
  • Encourage your colleagues to learn from one another, and pair up folks who want to learn about one another’s skills.
  • Organise “demo days” and other opportunities for product teams to share and discuss their work with the organization at large.

The worst thing about “Best Practices”

  • Approach best practices as a place to start, not a prescriptive one-size-fits-all solution.
  • Ask yourself how a particular best practice might help your team deliver user value, instead of just how it will change the way you work.
  • If you’re curious about how a particular company approaches product management, try to find some people who have actually worked there and ask them.
  • When you are bringing a best practice from one organization into another organisation, acknowledge and appreciate that every organization is different.
  • Take the time to truly understand the goals and needs of your organization before rushing to implement any specific practices.
  • Use a “slow and steady” approach to implementing best practices, so that you can test and measure the impact of every incremental change.
  • Avoid the temptation to solve the problems that seem the most familiar to you, as opposed to the problems that are having the most impact on your users.
  • Utilise the “organisational halo” effect of best practices to get buy-in toward trying new things, but be prepared to continuously adjust course based on what is working and what is not working.

The art of egregious overcommunication

  • Err on the side of overcommunication. When you aren’t sure whether something is worth mentioning, mention it.
  • Don’t be afraid to ask “the obvious.” In fact, the more obvious something seems, the more insistent you should be about making sure everybody is in fact on the same page.
  • Create a document like “Good Product Manager, Bad Product Manager” that clearly lays out the behavioral expectations for product managers in your organisation.
  • Avoid the temptation of being a “meeting-hater.” Don’t apologise when you’re asking for somebody, but make sure that their time is well spent.
  • Ask your teammates about the most valuable and well-run meetings they’ve ever attended, and work with them to set a clear vision for what a “good” meeting should look like in your organisation.
  • Make sure that people are given a chance to voice their opinions in meetings by using “disagree and commit” or any other approach that achieves similar goals within your organisation.
    • The goal of a meeting should not be to get consensus, but rather to get commitment
    • Encourage people to share dissenting and complicating information that might prove critical in deciding upon a path forward.
    • Avoid consensus-driven compromise solutions that placate meeting participants but fail to meet underlying goals.
    • Force a clear decision, and create shared accountability around that decision.
    • Allow participants to pick their battles by committing quickly to low-stakes decisions that are often prone to disagreement (i.e., “What’s for lunch?”)
    • Interpret silence as disagreement, ask for affirmative commitment
    • Don’t completely misinterpret the entire point of this and say, “Well, it doesn’t matter if you agree because we’re doing disagree and commit!
  • Create and protect space for informal communication in your organisation, like team lunches and coffee breaks.
  • Acknowledge that distributed and remote work is simply not the same thing as colocated work, and cannot be transformed into an exact proxy for colocated work through tools and technologies.
  • Remember that people have different communication styles. Don’t write somebody off as a “bad communicator” or assume that they have bad intentions if they are not as open and extensive a communicator as you are.
  • Avoid starting sentences with phrases like “It would be great if…” or “Do you think it might be possible to…” that deflect responsibility. If you are asking for something, ask for it—and be clear about why you are asking for it.
  • Level up tactical conversations about things like design choices or development timelines to strategic conversations about goals and user needs.

Working with senior stakeholders

  • When working with senior stakeholders, don’t set out to “win.” Help empower them to make great decisions, and demonstrate that you can be a valuable and supportive thought partner.
  • Push upward for clarity around company strategy and vision, no matter how challenging it is. In the absence of this clarity, you cannot succeed.
  • Don’t try to “protect” your team from senior stakeholders by talking about how ignorant, arrogant, or out of touch these senior stakeholders are. Instead, bring your concerns directly to these senior stakeholders and help walk them through making the trade-offs that will best serve your company’s overall goals.
  • Never surprise a senior stakeholder with a big idea in an important meeting. Socialise ideas slowly and deliberately in one-on-one meetings.
  • Don’t let company politics drown out the needs of your user. Let user needs guide your decision-making, and bring the user’s perspective to life in meetings with senior leaders.
  • Make sure that business goals and user needs are not seen as at odds with each other, but are instead aligned with each other, both for specific product initiatives and within the organization’s overall vision and strategy.
  • When senior stakeholders ask you questions like, “Can this be done by Tuesday?” take their questions at face value. Let them participate in making tactical trade-offs, rather than rushing to make yourself the Product Martyr.
  • When confronted with a swoop-and-poop, don’t try to litigate the details of past conversations. Look for opportunities to diagnose and address the underlying issues so that that the swooper/pooper does not feel out of the loop moving forward.
  • If a senior stakeholder suddenly wants your team to work on something different, find out why. There might have been an important high-level conversation of which you were not aware.

Talking to users

  • Talk to your users!
  • Accept and acknowledge that talking to users is a real skill that takes time to develop.
  • Remember that talking to users and working with stakeholders are different things, and require different approaches.
  • Don’t try to impress users with your knowledge or expertise. Create as much space as you can for them to explain their reality to you, even if it feels like “playing dumb.”
  • If there are user researchers in your organisation, reach out to them and ask for their help walking you through the tools and approaches that they use.
  • When talking to users about their experiences, ask about specific instances rather than broad generalisations.
  • Don’t ask users to do your job for you! Do everything you can to understand their needs, and then think about the specific products and features that might best address those needs.
  • Use “leveling up” questions and prompts to get to core goals and motivations without an accusatory “why.”
  • Let your users lead you to what they think is important, rather than making that assumption for them with lots of detailed “zooming in” questions.


  • Recognise that a data-driven approach still means that you will have to set priorities and make decisions.
  • Avoid using the word data to generalise specific information. Say what that information is and how it was gathered.
  • Rather than hiding or erasing the assumptions that go into working with data, document those assumptions so that you and your team can address them together.
  • Have a clear and strong point of view about what metrics matter and why.
  • As a thought exercise, ask yourself to decide on the “One Metric That Matters.” If you’re having trouble focusing in, go back to your high-level goals and see if you can make them more specific and actionable.
  • Think through how you will measure a product’s success before you launch it, to avoid having to go back and add instrumentation after a product is already released.
  • Be just as curious and active about understanding metrics moving “the right way” as you are about metrics moving “the wrong way.”
  • Rather than being accountable for a number hitting a target, seek to be accountable for knowing why that number is moving toward or away from that target and having a plan for addressing whatever underlying issues are within your control.
  • Resist the siren call of scores and numbers that purport to tell you “everything that you need to know” about anything. Take the time to understand how these quantitative proxies are developed, and do the work of figuring out what specific questions they can and cannot answer based on your goals and priorities.
  • No matter how complex the data systems you’re working with, resist the pull of jargon. Keep conversations about technical decisions rooted in high-level goals that can be understood by everyone in the organization to make as much room as possible for collaboration.

Realistic roadmaps and painless prioritisation

  • Give up on being the person who “owns” the roadmap. Instead, look to facilitate the way that your entire organisation uses roadmaps.
  • Don’t make assumptions about how your organisation uses roadmaps. Ask lots of questions, and create a clear and well-documented understanding of how roadmaps are to be used within your organisation.
  • Open up the roadmap. It should be a conversation starter and a tool for alignment, not something to be closely guarded and manipulated under cover of darkness.
  • Give your colleagues the opportunity to suggest ideas for the product roadmap, but don’t let it turn into a free-for-all.
    • Product idea
    • Suggested by
    • Which of our users (current or prospective) this is for
    • How this idea will improve their experience
    • How this idea will help our business
    • How we will measure success
  • Advocate just as fiercely for ideas that are not your own, if not more so. Don’t get hung up on wanting to be the “idea person.”
  • Don’t spend so long on product specifications that you close off avenues for true collaboration.
  • If you are using a formal practice for writing product and feature specifications such as “user stories,” remember that a formally correct spec is not necessarily a good spec.
  • Make sure that everything on your roadmap is tied back to a “why” so that if that “why” changes, you can adjust the roadmap accordingly.
  • Be prepared for short-term prioritisation to be much more challenging than creating a long-term roadmap.
  • Dealing with emergencies
    • What is the issue?
    • Who reported this issue?
    • How many users is it affecting?
    • Is there revenue directly tied to this issue?
    • If so, how much?
    • What would happen if this issue were not addressed in the next two weeks?
    • What would happen if this issue were not addressed in the next six months?
    • Who is the contact person for further discussing/resolving this issue?
  • Do everything in your power to make sure that the goals against which you are prioritising are clear, well understood and actionable.
  • If you can, take your goals for a “test drive” with the senior leaders who are setting the company vision and strategy. See if the goals can serve as a stand-in for their vision, and change your goals if they aren’t giving you the guidance you need.
  • If your team is excited to build something new and shiny, don’t reflexively shoot it down for “not meeting our goals.” Find out why your team is so excited, and see what you can do to direct that excitement toward whatever solution will deliver the most value to your users and your business.
  • Remember that learning, testing, and experimenting is still valuable work, and should be treated as such. Prioritise tasks like creating prototypes and researching implementation approaches alongside the work of actually building your product.


  • Avoid ambiguous and misleading jargon around Agile—say exactly what you intend to do and why you intend to do it.
  • Understand the core values and principles of Agile before evaluating any specific practices or frameworks. If you just start implementing process without purpose, then you have no way to evaluate whether the process is working or not.
  • Socialise a North Star vision around Agile values and principles, so that everybody on your team knows why they are “doing Agile” in the first place.
  • Start with an off-the-shelf Agile methodology so that you have an impartial “referee” to resolve any specific questions about whether you’re “doing it right”—and then be fearless about changing that methodology if it is not helping you reach your North Star vision.
  • Create and protect time for your team to evaluate Agile practices against the goals you’ve set. Document process changes along with their intended goals, so that there is clarity around what people are doing and why.
  • Don’t let the operational details of doing Agile distract you from higher-level organisational goals. Remember that if you are executing against a product roadmap that delivers no value to your users or your business, it doesn’t matter how Agile your execution is—your product is still going to fail.
  • Don’t let user-centric Agile rituals serve as a stand-in for actually talking to your users.
  • Communicate the goals and rhythms of your Agile practices to people outside of your immediate team, so that they know what to expect and how to work with you.
  • Understand that “no process” is still a process, and take the time to really understand how your organization is currently building products.
  • If you feel that your organization is becoming too zealous about Agile, feel free to print out a whole bunch of blog posts by people who actually wrote the Agile Manifesto, describing how Agile zealotry and ornamentation have derailed the movement they started.

Day to day

  • Be wary of your organisation and team falling into autopilot. Actively bring new ideas and challenging perspectives to your team at all times.
  • Use time-boxed prototypes to explore alternate product directions, even when there is no immediate or obvious pressure to change course.
  • Remember that a good product organisation is not one free of conflict, but rather one in which conflict is handled openly and without personal attacks.
  • Try to bring the energy and enthusiasm from your best and most exciting moments as a product manager to every day of your work.
  • If you begin to feel like you are the only person keeping your team or your organisation from falling apart, take a step back. Make a list of the things you can’t control, delegate impactful work to your colleagues, and make sure you are protecting your team’s most valued routines and rituals.
  • Understand that the connectedness of your role carries great responsibility, but also great opportunity. Do everything in your power to protect and embody the very best things about your team and your organisation.

Book Notes: The Advantage

The Advantage: Why Organizational Health Trumps Everything Else in Business by Patrick Lencioni
My rating: 4 of 5 stars

The three biases:

  1. Sophistication – people think that solutions need to be complex, but in reality the solution is simple
  2. Adrenaline – people like to rush, instead you need to slow down and deal with important but not urgent issues
  3. Qualification – overly analytical leaders feel they need to quantify everything, where as the reality is that success is the compound of many small things multiplied up

Smart and Healthy

Good at:
and technology
Minimal policies,
low confusion,
high moral,
strong productivity
and low turn over amongst good employees

Being smart is permission to play, a healthy organisation will get smarter over time.

The four disciplines:

  1. Building a cohesive leadership team – the people at the top are not behaving cohesively in the five fundamental ways
  2. Create clarity – leaders must be intellectually aligned and committed to the same six critical questions
  3. Overcommunicate clarity – communicate clearly, repeatedly, enthusiastically and repeatedly
  4. Reinforce clarity – every policy, program, activity etc should be designed to reinforce what is important

Building a cohesive leadership team

  • A small group of people, over 8 is problematic and never over 12.
    • Larger groups advocate for their own case
    • Advocating is common but dangerous
    • Inquiring is rarer and more important
  • A team has collective responsibility – selflessness and shared sacrifices
  • Common Objectives – most measures should be collective
  • Behaviours
    • Building vulnerability-based trust – being completely comfortable being transparent, honest and naked with one another. Happy to say “I screwed up”, “I need help”, “your idea is better than mine”
    • Mastering conflict – when there is trust conflict becomes nothing but the pursuit of truth, an attempt to find the best answer. Conflict will be uncomfortable, and it must be leaned into to the point of constructive conflict but not beyond.
    • Achieving commitment – when leadership teams wait for consensus before taking action, they usually end up with decisions that are made too late and are mildly disagreeable to everyone. This is a recipe for mediocrity and frustration. Teams must have the discipline to review their commitments and clarify anything which is not crystal clear.
    • Embrace accountability – peer accountability is the primary and most effective source of accountability on a leadership team. Leaders need to confront difficult situations and hold people accountable so others follow suit. To hold someone accountable is to care about them enough to risk having them blame you for pointing out their deficiencies. This is especially important for behaviours.
    • Focusing on results – an organisation must meet it’s results to be a good team. To do this the team needs one score and that should be more important than individual scores.

Create Clarity

  • Why do we exist?
    • Customer – to directly serve the needs of an organisation’s customer or primary constituent.
    • Industry – to be immersed in a given industry
    • Greater cause – the company plays a role in a greater purpose
    • Community – to make a specific area better or group of people supported
    • Employees – to be a great place for people to work
    • Wealth – to make the owner wealthy
    • Two similar companies can act very differently if their reason to exist are different
  • How do we behave?
    • Core values – a very small number of traits that are fundamental and long held by the company
      • Is this trait inherent and natural for us and has it been present for a long time?
      • Would our organisation be able to credibly claim that we are more committed to this value than 99% of companies in our industry?
    • Aspirational values – characteristics the company wishes they already had
    • Permission-to-Play values – the minimum standards that are required in the organisation and usually common in the industry
    • Accidental values – these are evident but not not intentional
  • What do we do?
  • How will we succeed?
    • The company should make an exhaustive list of everything related to the bussiness. Then search for patterns within everything.
    • These need to be reviewed but the cadence is situation specific – where barriers are high and innovation low the they will last a long time, but where barriers are low and innovation is high these will likely not last very long and need regular review.
  • What is most important, right now?
    • One priority
    • Thematic Goal
      • One thing
      • Qualitative
      • Temporary
      • Shared across the leadership team
    • Defining objectives
      • These are the general categories of activities to achieve the thematic goal
    • Standard operating objectives
      • The day to day measures which people should be following
    • All the above on one page
  • Who must do what?
  • With all of the above – capture it but keep is short – one page, two at most. Then keep it to hand.

Overcommunicate clarity

  • Tell true rumours – it is the best way to get the word out
  • Consistent message
  • Timeliness of delivery, does not need to be the same time but within 24 hours
  • Live/real-time communication, not email as this is less effective
  • Ask the question “What are we going to tell our people?” to align on the key points of a message, not a wordsmithed to death script
  • Don’t get feedback if it is not going to be used.
  • Great organisations are never run by democracy.
  • Communication silos will exist as long as people want them to – how you communicate is irrelevant

Reinforce Clarity

  • An organisation has to institutionalise it’s culture without bureaucratising it
  • Your people are your culture so structured hiring is key
  • Onboarding is a memorable and impactful part of an employees life – make it count
  • Performance management, compensation and rewards – against the companies values
  • Recognition by authentic and specific expressions of appreciation
  • Keeping a relatively strong performer who is not a cultural fit sends a loud and clear message to employees that the organisation isn’t all that serious about what it says it believes

The Centrality of Great Meetings

  • “If someone were to offer me one single piece of evidence to evaluate the health of an organisation, I would want to observe the leadership team during a meeting.”
  • One meeting to cover everything – does not work. The human brain can not jump between things like this. There needs to be greater clarity and focus.
AdministrativeDaily Check-In5-10 minutes most days
TacticalWeekly Staff45-90 minutes weekly
StrategicAdhoc Topical2-4 hours as needed
DevelopmentalOff-Site Review1-2 days quarterly
  • Tactical
    • Real-Time Agenda – deciding at the start what are the pressing topics
    • How are we doing against the things we said are most important?
  • Off-Site Review
    • Step back from the bussiness to get a fresh perspective
    • Review the organisation’s strategic anchors and thematic goal
    • Assessing the performance of key employees
    • Discuss industry changes and competitive threats
    • Review the team members in regards to cohesiveness

Book Notes: It’s The Manager

It’s the Manager by Jim Clifton and Jim Harter
My rating: 4 of 5 stars

70% of the variance in team engagement is determined solely by the manager

The workforce is changing and businesses need to evolve to get the most out of their people.

My PaycheckMy Purpose
My SatisfactionMy Development
My BossMy Coach
My Annual ReviewMy Ongoing Conversations
My WeaknessesMy Strengths
My JobMy Life

Why is change so hard? Humans are hard wired to distrust outsiders. This distrust can result in teams working against each other, and as such against the best interests of the company.

Leader need to bringing multiple teams together. It is easy for a leader to blame someone else – another team or manager, how connected managers feel will impact their safety and cooperation with other leaders.

Making great decisions. Know your limits, don’t have the ego to think you know it all realise you don’t and pull in other expertise to cover areas you don’t know. Apply critical thinking, identify risks and blind spots to prevent confirmation bias and groupthink. Use analytics-driven evidence, analytics when done right overrule hierarchy, politics and bias.

Culture – what is your mission, purpose and brand? Do these align with policies, programs and communications? Build culture through coaching by line managers.

Hiring stars – Hiring managers must reduce bias to choose the best people for the role.

  • Glare factors. Disproportionate weight to visual characteristics e.g. a candidates look
  • Experience fallacy. Assume everyone the same company or university will be successful
  • Confirmation bias. Only hearing comments that confirm beliefs about a candidate
  • Overconfidence bias. Hiring managers having special ability to select applicants
  • Similarity bias. Choosing people similar to yourself
  • Stereotype bias. Unconscious stereotypes of gender, race, sexuality, ethnicity and age
  • Availability bias. Relying on memory of an interview rather than a complete perspective
  • Sunk cost fallacy. Continuing with a candidate because so much time already invested
  • Escalation of pressure. Pressured to a candidate because its taken a long time to fill a role

How to hire

  • Prior experiences & achievements. What have they already done which aligns with the role
  • Innate tendencies. Evaluate on
    • Drive for achievement (motivation)
    • Getting work done (workstyle)
    • Taking action and inspiring others to succeed (initiation)
    • Building quality partnerships (collaboration)
    • Solving problems with assimilating new information (thought process)
  • Multiple interviews. Input from multiple interviews will reduce the potential bias.
  • On-the-job observation. Internship or scenarios as close to real life to see how they act.

Seven expectations that are necessary for success in any role:

  • Build relationships. Build trust, share ideas and accomplish work
  • Develop people. Grow others through strengths, expectations and coaching
  • Lead change. Embrace change, set goals that align with a stated vision
  • Inspire others. Positivity, vision, confidence, challenges and recognition
  • Think critically. Gather and evaluate information that leads to smart decisions
  • Communicate clearly. Share information regularly and concisely
  • Create accountability. Hold yourself and others responsible for performance

When people leave – make sure they feel heard, they feel proud of what they did and are brand ambassadors

Coaching conversations

  • Role and Relationship Orientation. Get to know each individual and their strengths and align to the organization’s overall objectives. Define success and co-worker expectations.
  • Quick Connect. Ongoing conversations for employees to feel heard and to raise issues for awareness and resolution.
  • Check-In. Regular review of successes, barriers and priorities.
  • Developmental Coaching. Most effective when the manager knows the employee well. To give the employee direction, support and advice when they are exploring career, aspirational or developmental opportunities.
  • Progress Reviews. Review purpose, goals, metrics, development, strategy, teams and wellbeing

Pay – Criteria should be transparent and not political lobbying. Don’t use forced rankings. People want autonomy/performance related pay but great care needs to be taken. Financial wellbeing is an organisational responsibility.

Performance rating bias

  • Personal or idiosyncratic bias. Higher rating for people who would do things the same way as the manager
  • Halo effect. When doing things the manager views as important well can result in the manger rating other aspects more favourably
  • Spill over effect. Once managers has made a choice for an employee they need a compelling reason to modify their prior judgment in subsequent reviews.
  • The middle default. Struggle to distinguish performance among workers
  • Leniency and strictness biases. Some have a bias toward the extremes.
    • Leniency bias giving positive ratings even though employees have notable room for improvement.
    • Strictness bias when a manager is overly critical

Performance rating solution

  • Individual achievement – performance metrics, subjective manager observation and individual goals
  • Collaboration
  • Customer value

Team’s engagement

  • Connectedness to the rest of the organisation
  • Composition of team strengths
  • Experience working together
  • Team size