Obvious Adams: The Story of a Successful Businessman may be the most valuable 141 pages you can read. It’s about how the obvious action is so unobvious to many, and how doing so requires you to actually think, which many seem to avoid. And that’s what I want to land with you here.

Adams, an advertising exec, first suggested that when advertising a hat in a magazine, they should use a close-up of the hat being worn, rather than a picture of the full person! A crazy idea back then (the book was published in 1916), but so entirely obvious to us now.

From Obvious Adams

”Well, Mr. Oswald, I have decided that I want to get into the advertising business and that I want to work for you, and I thought the obvious thing to do was to come and tell you so. You don’t seem to think I could make good and so I will have to set out to find some way to prove it to you. I don’t know just how I can do it, but I’ll call on you again when I have found out. Thank you for your time. Good-bye.” And he was gone before I could say a word.”

…

“It all struck me in a heap: How many of us have sense enough to see and do the obvious thing? And how many of us have persistency enough in following out our ideas of what is obvious? The more I thought of it the more convinced I became that in our organization there ought to be some place for a lad who had enough sense to see the obvious thing to do and then to go about it directly, without any fuss or fireworks, and do it!”

The parallels are apparent, or obvious 😉. In business, we forget to ask our users and just guess what they might want. Michael Seibel talks about the early days of Twitch2, where they asked their streamers and immediately got back, “Can you let us stream in higher resolution?” Something so obvious and easy to implement it was embarrassing they hadn’t thought of it (though it would increase their costs). Later, streamers asked, “Can you help us make money?” leading to revenue sharing of advertising, now a huge part of most popular social media platforms.

ChatGPT was obvious. Capable LLMs were around at least a couple of years before ChatGPT, they were just harder to use, being trained to complete text rather than answer questions. But it was only obvious to everyone after it was released.

I realised a lot of my career has been doing the obvious and being confused about why others aren’t. I have been called strange; I have taken people aback, but nearly always, after explaining my reasoning or motive, the action was understood and ultimately very effective.

In a recent project, I made it much easier to run jobs in Spark, while increasing parallelisation and saving money. Big numbers — one pipeline was an 80 percent cost reduction and completes in a fraction of the time. The idea was obvious, but before I built it, the common response was “It feels like there should be a better way” (a good challenge) and “We shouldn’t have to do that” (I agree). But when there wasn’t a better way, and we did have to do it, most shied away instead of doing the obvious thing in front of us.

Another Adams story raises the issue that we expect complexity in ideas.

“The president looked them over and grunted. Plainly he was disappointed. Adams’s heart sank; he was going to fail on his first selling trip, but not without a fight.

The president rocked back and forth in his chair for a few minutes. Young man,” he said, finally, “every good bond paper is made of carefully selected rags”—quoting from the advertisement in his hand; “every good bond paper is made with pure filtered water; every good bond paper is loft-dried; all good papers are hand inspected. I didn’t need to get an advertising man from New York to tell me that. What I wanted was some original ideas. Every one knows these things about bond paper.”

“Why, is that so?” said Adams. “I never knew that! Our agency controls the purchase of many thousands of dollars’ worth of bond papers every year, yet I venture to say that not a single man in our organization knows much about paper-making, excepting that good paper is made of rags. You see, Mr. Merritt, we aren’t any of us paper-makers, and no one has ever told us these things. I know there is nothing clever about these advertisements. They are just simple statements of fact. But I honestly believe that the telling of them in a simple, straightforward way as qualities of your paper, month after month, would in a comparatively short time make people begin to think of yours as something above the ordinary among papers.”

No fancy copy, no clever or abstract ideas. The reaction: “I didn’t need to get an advertising man from New York to tell me that.” Have we all just been burned by the reactions of others when we’ve done the obvious? Do we overcomplicate things because that’s what people expect?

We need to defend and fight for ideas when they are obvious more often than when they are complex. Complexity is somehow more valid, more trusted than simplicity. There must have been more thought and reason put into the complex, surely? But the opposite is true.

I think many end up hiding behind complexity simply because it isn’t questioned. But when you have really taken the time to understand, think, and have a clear course of action, you can defend it, and you can break through.

“Mr. Merritt was evidently impressed by the logic of Adams’s argument, yet he hesitated.

“But we should be the laughing-stock of all the paper-makers in the country if they saw us come out and talk that way about our paper, when all of the good ones make their paper that way.”

The other side is fear. Fear that it must have been tried before and failed. Fear that we are missing something that will make us look stupid if we mention it. Fear of looking stupid is holding so many of us back.

Adams bent forward and looked Mr. Merritt squarely in the eyes. “Mr. Merritt, to whom are you advertising—paper-makers or paper-users?”

That line is a top quote in the book for me because the direct lesson is also so relevant. How often have you had a CEO or executive, far removed from the target market for your product, hold very strong views about a feature or marketing decision simply because it doesn’t appeal to them? They forget it’s not supposed to.

You will finish Obvious Adams in under an hour, but spend far more time in the following days pondering it. The book can be freely obtained, being out of copyright now3.

I leave you with the closing question in Obvious Adams.

“Why don’t more businessmen do the obvious, then?”

“Well,” he said, “since I had that name wished upon me I have given considerable thought to that very question, and I have decided that picking out the obvious thing pre-supposes analysis, and analysis pre-supposes thinking, and I guess Professor Zueblin is right when he says that thinking is the hardest work many people ever have to do, and they don’t like to do any more of it than they can help. They look for a royal road through some short cut in the form of a clever scheme or stunt, which they call the obvious thing to do; but calling it doesn’t make it so. They don’t gather all the facts and then analyze them before deciding what really is the obvious thing, and thereby they overlook the first and most obvious of all business principles.”

Your challenge for the week

Be more like Adams this week.

What’s obvious that you’re not doing?

Follow his process:

• Gather the facts.

  • Throw out that solution that’s already brewing for you.

  • What do you know? Actually know. What is the evidence?

  • What don’t you know? Is there anything you can easily find out? How?

• Analyse (think!).

  • Looping and realising you need more fact gathering or another experiment is normal.

• What’s the obvious conclusion? Do that!

Advanced: When important decisions are being made, or important information is presented that will be used to make decisions, don’t allow people to hide behind complexity and technobabble.

• Ensure you and others understand what’s being said.

• Question more than you do with simple information — complexity needs justification.

• Say the obvious.

Note: This is advanced because there’s nuance, and I’m presupposing that you know how to challenge without coming across as a jerk.

Let me know what you’re going to try, or how you get on, in the comments!

Exceptional teams didn’t start that way. They got better and better, and never stopped getting better even when other teams became complacent with “good.”

Retrospectives (retros) are your way of ensuring this. They are your continuous improvement process. Everything else can change, as long as the retro exists. It is the only process I will insist on when leading a team.

If you hate retros, or disagree already, it’s likely because you’ve only experienced bad ones. I know many who have been there. I explain the anti-patterns later in this post, which I encourage you to read now if this is you.

Otherwise, let’s begin with what they are, how to run them, and how to make them effective AF.

What is a retrospective?

“It took forever to add that endpoint because the test suite is super fragile.”

A retro (retrospective) is where you get together as a team and review the previous cycle (e.g., sprint) with the goal of learning how to make the next cycle better. This often takes the form of “what went well” / “what didn’t,” with discussion on what actions we should take as a result.

Retros encourage your entire team be willing to experiment because they know if something doesn’t work out, it will be reverted or changed. So there is no fighting an idea just because you think you’ll be stuck with it for a quarter (or forever). This means learning fast by trying things to see if they work, instead of endless planning and discussion.

They are a cornerstone of psychological safety, if you let them be. Spaces where team members feel safe raising issues and where you can collaboratively solve problems. As a leader, running them well will massively increase your team's trust in you.

For me, retros removed our daily morning stand-up and replaced it with an async Slack stand-up. We found stand-ups were restricting flexible work, breaking flow states, and not really adding anything useful. Retros also brought stand-ups back (twice a week) when we missed the contact time.

We also identified a painful security requirement that was forcing a manual step in our onboarding process. Through discussion we realised it was not necessary and we were doing the equivalent of soldiers still guarding a wall 30 years after the wet paint sign had fallen off. Onboarding went from a 48-hour turnaround to instant self-service.

Every team that values continuous improvement needs a process to enable it.

Here’s my playbook for making retros genuinely valuable.

Playbook

I’m suggesting two different paths, one for remote teams and one for in-person teams. Both can be used for the other case, but I think these are the strongest for each situation as a starting point.

You can search for and find many other formats. They overlap a lot but can have different focuses that will suit you. For example, some explicitly focus on projects or have different exercises to help you create actions.

For now, it doesn’t really matter, the important thing is you start. I would stay consistent for the first four or so sessions until you get into the flow of them (unless it’s really not working), then start experimenting until you find what works best for you and your team. This can, and should, change over time.

The 4Ls - My recommendation for remote retros

The 4Ls are Loved, Loathed, Longed for, and Learned. There are many wording variations on these. I prefer the ones below (currently 😉)

I use a spreadsheet with four columns:

• Future considerations: Proactivily raise items that arent a major issue now, but may be in future.

• Lessons learned: Any learnings worth sharing with the team.

• Problem areas: Highlight issues needing attention.

• What went well: Celebrate acheivements and highlight what to keep doing.

Download this free template here!

Someone needs to run the meeting as the “MC.” I recommend the team lead, manager or you (as the one who cares enough to read this!) take on this role to start with.

Set aside an hour for the meeting. Allow 5 minutes for reviewing actions, 10 minutes for writing the items, and 45 minutes for questions. Both stages should naturally reduce in length over time; mine normally end up as 30-minute meetings.

Format

1. Go over the actions from last time. Have they been completed? What was the result? If they haven’t been completed, check if they are still valid and mark them with a +1 so you know it’s a carry-over.

2. Everyone writes their items on the board, and moves their cursor to the parked area when done.

   1. Encourage people to +1 items they agree with or that would be duplicates. This can be done by editing the cell in a spreadsheet or using an emoji reaction on Miro.

3. Play music while this is happening. I like to have a designated DJ who will have chosen some songs in a theme (e.g., this quarter could be video game soundtracks).

4. When everyone is done, or the allocated time has run out, choose items to discuss. The writer of the item should explain it and any suggested action. Others can then contribute.

5. Note down any actions as you go, along with the person assigned to do them.

The post-it method - My recommendation for in person

I love being able to leverage the physicality of being in person. There’s just something about it, another dimension you don’t get remotely.

So, bring in post-its and pens (Sharpies). Give everyone a pile and let them write out their issues. You can prompt ideas in the vein of the 4Ls, but I normally keep it freeform.

When everyones done, stick them all on a whiteboard or in the middle of the table. Have a few people read them all and group them into themes. Discuss these themes, having the people who wrote them give the context and any suggestions first.

If there are a lot of items, run a quick vote on the themes. A good way is to give everyone five points, which they can allocate however they want — for example, three on one and one each on two others. Mark them as a tally.

Allocate approximately 10 minutes to each one, but don’t be afraid to cut one off earlier if it becomes circular, and cover another item instead.

Managing the Discussion:

In both cases, your job as facilitator/MC is to ensure discussions stay focused and to convert problems into actionable steps whenever possible. Some tips:

• Avoid extended rants without actionable outcomes or circular discussion. Some venting is fine, but it’s not the goal here.

• Steer discussions towards how can we make this better? What can we try next time?

• Stop any blaming or argumentative behaviour very quickly. Remind everyone this is a safe space focused on learning from our mistakes, trying new things, and making the next cycle better than this one.

• As the MC, you should be listening and enabling a productive discussion primarily. You can offer your perspective, but do this last.

• Look out for those dominating or overriding others. This often isn’t done with malice, but simply by those who are louder. Encourage and ask for input from quieter people, but don’t force them to speak.

• Keep sessions efficient (around 30–45 minutes for smaller teams). If overloaded with topics, quickly vote to prioritise items. It's ok to use your own judgement too based on the “cost” of an issue.

• It will be painful leaving items not discussed. Remember, you are doing these regularly. If something comes up again next time, it’s likely more important to discuss as it’s recurring.

Tips for the first one

It’s your job to show others that this is a safe space where you can be vulnerable and there is no retaliation or blame. You demonstrate this through your actions.

I would share items like (only if genuine):

• A process I don’t think is working well, so we can change it and demonstrate the change process.

• A vulnerability, e.g. it took me forever to do this task because I didn’t clarify a requirement, which resulted in a rewrite.

• A problem, such as we are bad at communicating what we are working on as a team, and it has caused X problem.

Remember you are setting the example of what acceptable items are and the responses to those items.

And send the team this article so they understand what you’re trying to do! 😉

What makes good actions?

Actions should be achievable before the next retro.

The general principle is that we accept there is a problem and want to try something that may fix it. Often, there will be some who aren’t keen, but if this is the best suggestion, then we try it. Next time, we will discuss how it went based on actual experience, not theory.

A common issue is that actions end up skipping the team’s prioritisation. A bad action would be for someone to address a piece of code debt. Better would be for someone to be given the action to add that to the planning session.

Actions can involve some work, for example, briefly investigating something, setting up a meeting, or setting up an app like “donut” to facilitate team chats. Actions should not be excessively time-consuming in themselves. Your tollerance here will vary based on how you plan and prioritise.

Actions should have either one owner or everyone. Multiple owners mean their are no owners. The exception is if the action is for everyone to do something themselves, e.g. everyone must ensure their code is tested this sprint.

Making retros a success over time

You should retro the retro! Retros benefit from changing over time to adapt to your needs and add variety. Initially, you’ll have many issues, and there won’t be enough time to discuss everything. Over time, there should be fewer issues because you’re actively solving them. Here are some tips to keep them effective:

🗓️ Regularity and consistency: Schedule retrospectives regularly. Emphasise that they are experimental, and reinforce that decisions can always be revisited.

🌱Adaptability: Tailor retrospectives to your team’s maturity level. Recognise that teams may also have mixed experiences with retros in the past and adjust accordingly.

✋ Addressing pushback: Teams may resist retrospectives if they’ve had negative experiences, such as feeling dominated by louder voices or having their concerns ignored. You must gently guide and demonstrate the benefits over time.

♻️ Retro the retro: Prompt people to focus some thought on how to make the retro itself better.

🎤 Mix up the MC: Rotate the MC each session or every few sessions. Explicitly allow the MC to change and play with the format. Then discuss the changes!

🌤️ Start the meeting with a vibe check: This could be red, amber, green; a GIF to represent your week; etc.

✍️ Change the prompts: Add new ones or mix up the language, for example:

• What’s pushing us forward? What’s holding us back?

• What are we excited about? What are we worried about?

• Some people enjoy themes, there are many retro templates out there (like pirates arrrr! 🦜)

☕️ Change the venue: When in the office, I liked to run the retro from the kitchen area (if it has a nice seating area) or nearby coffee shops. The informal venue loosened up conversation but also kept things very tame. In most shared office venues, buying the whole team a coffee is cheaper than booking a meeting room!

Mistakes that will kill your retro

Irregular scheduling. If you keep cancelling or holding them infrequently (like quarterly), you can’t make progress, and retros become just discussion and ranting. You won’t build the culture of continual improvement.

No psychological safety, e.g. criticising people for “complaining” or being negative. I’ve had managers treat them as the team complaining about things and give them a big list of things to tackle that they don’t see as important. If you do this, the team won’t raise anything and it doesn’t work.

Being defensive and not acting on the discussion. If you agree on change in the meetings and then don’t do it, then what’s the point? That’s exactly what your team members will think next time.

Anti-patterns of retros — Why I think you hate them

It’s just a pat-on-the-back meeting. Everyone just praises each other, and there’s no culture of continuous improvement.

It’s just a vent meeting without actions or solutions. Venting can be healthy but here you need to focus on what you can try to improve things.

They are dominated by loud individuals who overpower conversations, turning retros into shouting matches. Shut this down quickly.

Actions for problems that aren’t worth solving. An over-focus on actions without considering whether the problem is worth solving or prioritising. Minor or non-recurring issues end up consuming lots of time.

You must have a solution to to raise a problem. Retros are about surfacing problems and finding solutions together. “Bring me solutions not problems” means things get hidden and not solved.

They are too big. They work best at the same sizes optimal teams do. For me, this is normally 3–8 people, but it can be higher depending on your work and culture.

Teams can’t change their own process, so no progress can be made. Team structure and processes can be strongly enforced from above for consistency. But they need to be able to diverge to allow them to work brilliantly together. Each team has different problems, pressures and people. One size does not fit all.

Final Thoughts

Retros are so powerful because they enable change and experimentation. Through consistently getting a little bit better, you become exceptional. By discussing and solving problems, you will improve morale and team cohesion.

If you’re a new leader to a team, you know that everyone hates the person who comes in and immediately starts issuing edicts. But the leader who listens to everyone, proposes and hears solutions to real problems, and then revisits those changes with everyone to review their effectiveness? That person builds trust and support while moving fast.

I have implemented retros on joining a new company in my first week for this reason. It was amazingly effective.

So get started now. You have the playbook, the template and the article to send to your team to get them onboard. Make your first change today — and start compounding improvements from the very next cycle.

Share

And have other ideas or disagree with something? Let me know in the comments.

Some of the worst managers have perfected the art of hiding their incompetence. They have a dysfunctional relationship with work. They feel the world owes them a good job — that they should be able to hold a well-paid, important position without adding value or putting effort in. Their primary skill? Making themselves look good to their superiors.

Left in place, incompetent leaders will:

• Push out your best performers

• Destroy trust and psychological safety so no one take risks

• Waste huge amounts of time and runway on vanity and re-org projects with no chance of success

• Create a “yes person” culture where critical thinking and collaboration stops

Incompetent leaders will undo all your work to empower brilliant people and exceptional teams. So more than any post, I ask you to share this. I want to expose and remove incompetent leaders from positions of power, where they harm everyone.

Most of us have worked with them, some of us for them. But how do they operate? How do they climb the ladder? What’s their playbook?

And, perhaps more importantly, how do we spot them, avoid hiring them, and deal with them?

The Incompetent Leader

Incompetent leaders are completely lacking in the skills and ability necessary to fulfil their role. Once you understand this, their behaviour makes sense. They can’t excel, they can’t solve problems, they can’t have impact. They don’t know how to. Many are now so deep into this that there is no recovery — they have been doing this their whole career.

Notice this is different from just “bad” managers. All incompetent managers are bad, but most bad managers aren’t incompetent.

Their purpose is to survive long enough in this position to be able to use the success of the company (in spite of them) to fail upwards to their next role. This is the cycle.

• They will point to 3x revenue during their tenure, a Series B closed at a 10x valuation.

• They will rewrite history.

• Their LinkedIn will be full of “acquired by X”, “sold to X”.

When you dig in, you will find many of these were at down valuations or happened before or after they joined.

Incompetent leaders wield their titles like an axe. They want compliance, submission, respect. They do nothing to earn it, they don’t build trust — they demand it.

They seriously harm team performance. They reduce productivity, drive away talented individuals, and retain those who remain silent and tolerate dysfunction.

Leaders must multiply, not divide. Removing incompetent managers swiftly prevents the spread of their toxic impact.

The Incompetent Leader’s Playbook

How do incompetent leaders get into important positions? How do they climb the ladder? The playbook is very simple.

1. They join a company already doing well

2. Buy time until they can’t any longer,

3. Fail upwards, claiming the success (in spite of them) as their own.

I first read about this idea in Shreyas Doshi’s Twitter posts on the subject; it’s worth the read!

Six Signs of an Incompetent Leader

There is no excuse for incompetence in high level positions, especially executives. They are at the top of the ladder, you cannot be bad at your job at the top of the game! Yet often, they are given more benefit of the doubt than junior hires.

There is some ramp up needed for new promotions, but these people aren’t bad — they are good at most aspects and are learning others. They don’t exhibit these traits.

Here’s how you can spot incompetent leaders early.

1. Always buying time

They never solve problems directly. Instead, they stall. There are four main things they like to do:

• Make new hires

• Introduce new process

• Blame someone else

• Reorganise the team

They’ll claim the need for new hires and won’t work on the problem until those hires are in place. New hires can easily take three months to recruit, and six months or more to get up to speed — buying nine or more months of time.

They also love introducing new processes. They will constantly add and change processes pulled from blog posts and books. They won’t really know how to implement them — they will have barely even read the source. If you ask detailed questions, you’ll see it’s all surface-level. They will be opinionated, but quick to delegate execution.

When anything fails to get results, they will blame someone or something (see later) and pick another. You can buy three months to roll it out, and another three to see results. It’s very effective. It also tends to land well in executive and board meetings.

Once process and hiring have been milked, it’s time for a reorg! That’s another six to 12 months bought.

2. Unclear communication

Incompetent leaders thrive on unclear communication, key traits are:

• Speaking at length instead of clearly

• Using jargon

• Having prepared speeches, reports or presentations to jump into

When asked to give an update, they will speak at length and say very little, using a lot of words. Many people accept the length of speech as evidence of work (often not consciously). They will use big words and jargon. They don’t want you to follow and understand; they want you to wish for it all to be over, and to move on.

But don’t. After they’ve finished rambling, try to summarise what they said — you will struggle. Repeat it back to them and ensure you have clarity. If something doesn’t make sense, say so. Do not let them blow past it.

They will use the uncomfortable nature of this questioning in a group meeting to their advantage. So, if it heads that way, make a note and follow up one-to-one.

They will not answer direct questions. Like a politician, they’ll drop into a prepared speech on a loosely related topic. They may pull out a slide deck, this makes them look competent and on top of things. Is the deck even relevant? It’s highly unlikely they even wrote it, though they will claim any credit.

Using reports and presentations isn’t bad in itself — but was it relevant? Was it useful? Again, try to summarise it.

3. Taking undue credit

They will:

• Take credit for wins, even those of other teams.

• Blame others for failure.

• Mislead others about their past success.

They quickly claim credit for successes, especially those due to external factors or team efforts, and will rarely acknowledge the team’s role. They will attach their name as a stakeholder to anything they think might be a success. I have even seen them try to put their name on work of other teams.

Wins are the currency of many companies. Gather a few and you’ll be forgiven for future failures. They know this, and have no shame in stealing them.

Ask yourself: where would we be if we had a great hire in this position? Incompetent leaders thrive when compared to having no one in the role.

Their LinkedIn profile probably lists many company exits, fundraises and massive valuation increases. This is often, at best, technically correct and, at worst, dishonest. But even if it’s true, how much effort did they contribute? How much better was the company for having them there? Their last company exiting is not a direct reflection on them.

At interview, question them in depth to find their true contributions.

• Do they speak positively of their team?

• Do they highlight other individuals?

• Do they ascribe everything to themselves?

I have put together some key questions for assessing leadership in an interview here!

4. Blaming: throwing team members under the bus.

When things go wrong, they will blame and undermine anyone they can.

I’ve witnessed them many times in exec meetings throwing their own team under the bus. No! You are responsible for your team; you take that responsibility here, with us. Blaming someone in their team in front of the other execs is a big red flag.

Blaming is not the same as being able to have actual performance discussions — the difference should be apparent.

The closest they will get to taking responsibility is, “John screwed up, but look, I’m the leader so I take responsibility.” They pretend to take responsibility but make sure everyone knows who is at “fault.”

Another trick is to blame while appearing reluctant to do so: “Sarah messed up on this, but I’m working closely with them on it now.”

I’ve even seen them blame a team member for doing something they themselves instructed, that the team member protested against. And when it predictably failed… they were blamed.

5. Isolation & controlling information flow

Controlling information flow is key for them. They:

• Demand everything goes through them

• Discourage open communication with other departments

• Ensure only they control the narrative with the exec team and board

They set things up so their teams can’t run without them — the opposite of what brilliant leaders do, which is trust and empower their teams. Since they can’t be essential through competence, they make themselves essential by controlling information flow.

They insist everything flows solely through them so they remain critical to every conversation and narrative. Projects can’t move forward without them, and to an outside observer, they appear essential.

They discourage open communication with other departments. They don’t want you gossiping or letting news of their incompetence and toxicity spread. When it inevitably does, they lash out.

They control the narrative with the exec team and board. They resist other team members entering these channels so they can maintain control over the flow of information with key people.

6. Retaliation

When incompetent leaders risk exposure, retaliation is common. If a team member speaks up — whether directly to their manager’s superior or to colleagues — the incompetent leader acts decisively:

• Threatening job security

• Gaslighting concerns as disloyalty

• Publicly discrediting, e.g. by creating false narratives about their performance

This aggressive behaviour aims to crush dissent and maintain control. They need to shut it down and discourage any further whistleblowers.

Sometimes this is very underhanded. They may start subtly raising issues about this person in all their conversations with others. They will create false narratives, claiming the whistleblower said something about others, damaging their relationships. To the whistleblower’s face, they may do the same, claiming other people have a problem with them. This leads to false conflict and isolation.

Like a lawyer trying to remove an important witness, they will attempt to destroy the threat by attacking their credibility and reputation so that, no matter what they say in future, they can’t do damage.

You need to protect those brave enough to raise concerns. Do not immediately run to the leader and say, “Mike said this about you.” Retaliation will be swift. Investigate properly and watch closely for any signs of retaliation.

Closing thoughts

I want you to help your teams be exceptional. I want you to empower your people to be brilliant. Incompetent leaders aren’t just a thorn in the side of this — they are a bull in your china shop. Trust is fragile, psychological safety is fragile.

If they just made your team ineffective, that would be one (terrible) thing. But they also destroy strategy. They damage your business. At a startup, this is fatal. Nine to 12 months of lost runway can be game over.

I want this article to be something that helps you deal with incompetent leaders — something you can send to your manager to help them understand the problem.

So please, share it with them.

I’ll be following up this post with how to spot incompetent leaders in hiring, and how to deal with them if they’re already here. Subscribe to see this when it lands.

And finally, let me know — what have I missed? Where am I wrong?

Let me know your thoughts in the comments. I’ll update this post over time.

Data leadership is my background. When I first started creating content, it’s what I thought I would write about.

But instead, I found myself speaking about how to build exceptional teams and grow the brilliance within the people in them. In mentoring sessions, I helped other leaders find what makes them brilliant and work through the complex and hard parts of leadership.

So here we are — I am now writing about Brilliant People, Exceptional Teams.

Tomorrow, I’ll drop my article on “Incompetent Leaders” — those who disrupt and destroy everything we try to accomplish here.

Following that, I’m going to focus on providing practical frameworks for building high-morale, high-agency teams. Think: diagnostic tools for team dysfunction, systematic approaches to 1:1s, and processes for turning individual contributors into collaborative powerhouses.

Here’s a taster of future posts:

• Performance growth, not management

• Supercharging your team by keeping everyone in their creates-energy zones

• How to increase your impact and influence

• Why retrospectives are the most important growth process for your team — and how to run them

• How to excel in your first 90 days in a new role

• Giving your team clarity — and how not to do OKRs

• Questions to ask when you ‘interview’ your next company

• Ways to show your brilliance in a cover letter and CV

I’m also setting up conversations with people I think are brilliant, and sharing how they drive large impact at their companies. I think you will love it, and we will both get to learn a lot from them.

Thanks for being here through Data Leadership. There’s much more to come, and I hope you stick around for this next chapter.

Let me know what you think and what you’re looking forward to! You can respond to this email, it will reach me 😉

I am a big detractor of take-home tests. I think they test available free time, not actual ability. They always take longer than expected and are easily cheated by using more time or getting help from a friend or now, AI.

Instead, I test competency in three ways:

• Thorough questioning - asking questions but going deep to test understanding and not just surface knowledge

• Case study - going through a real recently solved project to see how they think

• Pairing interview - pair with them to solve a real problem

Thorough questioning can be used for most hires. The case study better suits data science and product hires. Pairing better suits engineers. Data engineers can go either way.

Let's go through them.

Thorough Questioning

I have two main go-tos here: first, asking about a previous project, and second, about a technology they have used I'd like to know more about.

What project are you most proud of and why?

Ask, “What project are you most proud of and why?” Then (very) importantly, dig into the details. Inquire about their data and decision-making process: Why MongoDB? Why a random forest? What features did you choose, and why? Did you consider alternatives? Which features were most impactful, and how do you know? What would you do next to enhance the results?

There’s no set script here; it’s about exploring something they should know intimately. If candidates can’t answer these questions, it suggests they either mindlessly followed a process or are taking credit for work they weren’t very involved in.

Not every decision requires exhaustive analysis (most don't), but thoughtful responses like, “I chose a random forest because it performs well on our data with minimal tuning” or “Doing that would add complexity but only affect 4% of users, which wasn’t worth the effort” indicate genuine engagement with the project.

The goal is to unearth the nuanced decisions that only a hands-on contributor would know and understand how they make decisions. If someone struggles to explain a project they claim to be proud of, that’s a significant red flag.

I have been asked how to use a scorecard for this question. I may share one in future. But briefly, the types of things you may have are: communication, understanding of what they did, evidence of good reasoning, evidence of product thinking, and tying their decisions to user value.

Ask deeply about technologies they claim expertise in

If you met the candidate at a conference, what questions would you ask them to learn from their experience? Treat candidates as experts in the technologies and frameworks they list on their CV.

For example:

• You've used MongoDB a lot? When have you found it to be a better choice over SQL? Some of our older infrastructure is on Mongo, and we've had to recreate a lot of relational logic in the application code.

• Have you faced query optimisation issues with GraphQL? We love the flexibility but have heard users can end up running suboptimal queries that can be really tough to fix.

• You say you have deployed LLM-based features? How did you handle ensuring safety and avoiding hallucinations? How did you evaluate how it was performing?

These questions work best when they're genuine – when the candidate should be better versed on the subject than you, but you know enough to ask good questions. You can quickly gauge someone's real-world experience by how well they can teach you the nuances of using it.

They might not always know the solution to your specific problem, but if they have real experience, it should lead to an insightful conversation. It’s a red flag when a candidate has only surface knowledge about the things they have highlighted in their CV.

As an aside for candidates – don't put things on your CV that you don't want to talk about in an interview!

Case study

Pick a project you have recently solved, then present the goal, data and other relevant information, and work with them to solve it. Try and remember what you uncovered and present the information you knew at the start of the project, not the end. You can reveal more as the candidate asks relevant questions or as you move the interview along.

A recent project you worked on is key, as you will be able to deal with questions or approaches you weren't expecting. Forget creating artificial exercises with deliberate traps; they are hard to engineer and don’t reflect the messiness of real projects.

As you start, remember that the candidate is not a domain expert in your company. So you need to give them context and may need to give some prompts or jump in if they have the wrong idea about something.

I like to use Miro or similar to capture ideas and write down any extra information I give them as they navigate the problem. It also helps it feel more collaborative.

Through the exercise, you’ll see how they think and approach problems. Are they asking the right questions? Can they modify their approach when they get new information? You should be looking for the qualities your team values.

Everyone will likely get stuck at some point and need some hints or extra information. But if you have to hand-hold them through the whole exercise, it's not a good sign.

You should have an idea of the types of things you expect a candidate to discover through questioning. What good solutions to a project look like. And how much prompting and help from you is expected to be needed. This can all form parts of the scorecard.

Pairing interview

Choose a task from your backlog or one from the past you can turn into a regular exercise if doing that a lot. Pair with the candidate to get it done.

Choosing a real but previous task will allow you to use the same task for all hires and reduce the noise in your process – though this can be time-consuming to create and a less genuine experience. You will have to choose what's most important to you.

Ideally, they will be driving, but you may help out more if they aren't familiar with your stack. Here you will get an idea about their problem-solving and how they work in a real scenario.

Importantly, versus a take-home test, the candidate gets the same information from you! Do they want to work here? It’s mutually beneficial and naturally respects their time as you need to put in the same hours as them.

Bonus for platform hires

Provide a diagram of your current infrastructure, deployment process etc. It can be simplified, but you want to leave in the bits that aren't great or need work. Ask a candidate to review it, ask questions, and give their thoughts for improvements.

Wrap up

So please, try to avoid take-home tests. They don't test what you think they do.

An exception may be made for graduates, but in that case, I consider a simple and short low bar of “can they actually code?”. Generally, I would do these on a time-controlled platform so you can see them develop an answer, and any copy-pasting and available time isn't an issue.

Try these out and let me know your feedback. If you are looking for more questions you can ask in an interview, check out my recent update to the Data Leaders Handbook.

Want feedback but are met with silence when you ask? Or promises to think about it? Or told that everything is good?

Changing how we word and ask questions can make a world of difference and get you real feedback right there in the moment.

❌ "Have you got any feedback for me?"
✅ “Is there anything I do, or my process, that makes a part of your job harder than it otherwise would be?”

What makes a good question?

You need to think about what you want to know and then how you can help someone think of an answer. Questions work well if they are focused to narrow the scope, softened to remove any nervousness in answering, and are anchored to something that helps them recall events.

For example, let's say that you want to know if you are doing anything that's annoying or frustrating your team. Many people will struggle to tell their manager they are being annoying (If you feel like you can, you probably have a great manager!). They will worry about being petty. The fear of being petty or “wrong” blocks a lot of people from sharing valuable feedback. Instead:

✅ Is there anything I do, or my process, that makes a part of your job harder than it otherwise would be?

• Focused on actions or processes instead of “you”

• Anchored on “your job harder” to help them think

• By being less personal, it’s also softened

• Additionally softened with “harder than it otherwise would be” instead of "annoying"

This is immediately easier to answer. They may now be able to raise that the time tracking you are asking them to do is frustrating and time-consuming, that you ask for things at very short notice and it can be hard to stay in the zone, or that the strict enforcement of mypy you imposed is really slowing down work.

Receiving the feedback

It's really important that you don't get defensive. If you slip into that mindset, you will make them regret answering, and next time they will just tell you everything's good. Be very aware of your emotions in this moment.

The answer is likely to fall into a handful of categories which are best summed up as either you changing or explaining.

1. You didn't realise and are happy to stop.

Great, tell them that and thank them for raising it.

2. You know a change you can make to address that problem but still get the value.

For example, you actually only require a small part of that document people need to fill in — “Let me delete the extra columns. Is that better?”. It still helps to explain the value of the rest of it.

3. You know it’s annoying but can't change it (e.g. it’s enforced by your manager or has sufficient value).

Provide some context. Maybe you are working on removing it, or it's required for SOC II which is essential for your customers, or you know it's annoying but it genuinely adds a lot of value to you.

If it is the case that it's valuable, it helps to ask if there’s a way you can still get this value with less of a burden on them. They may have a solution that works for you both, or they will at least have a better understanding. Try asking them to raise it in the next retrospective to see if others have ideas — or raise it yourself.

4. You are surprised and don't know what to say.

Ask questions — you don't need to commit to anything right now. “Oh, I didn't know that, that’s really useful to know. Are you having to do that a lot?”. Find out a bit more. You can ask for ideas on how to improve it.

Ultimately, if you’re unsure how to act, you can close it out with “Thanks for telling me, I’ll think more about that and get back to you next time”.

But you need to follow through! This is what separates good and bad leaders. If you don't change anything and never mention it again, it's going to destroy your ability to get answers in future. Following through is where you build trust and credibility — not by just asking the questions. Generally, this is going to mean one of the other response types once you have had time to process.

Should you provide questions in advance?

I tend to ask these questions in the moment. I know some people like to provide them in advance — it allows someone time to think and can yield better information. But answers can also be less candid and more manufactured.

I do think feedback questions can be really good in advance, but I personally value feedback both in 1:1s this way and as a regular process where people do have time to think — but more on that in a future post.

My other favourite feedback questions

One of my favourite questions is:

✅ What did a former manager do that you valued, which I haven't adopted yet?

It's anchored in a former manager’s actions and softened in that you’re interested in trying to adopt something. You now get to learn from managers you've never met!

For getting company feedback try:

✅ When have you been disappointed with a decision or the direction that the company has gone in the past quarter?

You can see the same structure, not “have you”, not “if”, but “when”. It strongly suggests that it’s normal and expected to have an answer, and not an empty question. “past quarter” just limits the period their brain is searching through, making it easier.

Data Leaders Handbook

You can find lots more of my 1:1 questions in my recently published Data Leaders Handbook that you can access right now for free. I have lots more similar resources to share that I think will help you become a great leader in data. The best way to get notified of updates is to subscribe here.

Subscribe now

What are your favourite 1:1 questions? let me know in the comments or on LinkedIn.

Thank you to everyone who attended my talk on asynchronous programming in Python at PyData Global 2024.

• The slides from the talk are available here.

• The code from the talk, including the little service we made, is available here.

• The video is available now! See below.

I wrote a local test server you can run, which somewhat replicates the behaviour of the real server I used in the talk—though there are some differences.

The service runs asynchronously. The red (first column) is retrieving the video metadata, the blue is retrieving the transcript, the green is running the model, and the yellow is saving the result to the database.

Update the video is now available, let me know your feedback and help me make this better next time!