I’ve spent a lot of my time helping people to get things done. I’ve done this in university teaching, in start-ups, in long term industrially focused research, and in a large technology organisation. Reflecting on this work, I find there are three distinct modes in which I can help people. I’ll describe them here, using analogy based on lifting weights as a guide. As with many things, there’s no right answer – it’s contextual – which means that part of your work as a helper is to understand what will work in the context you find yourself in.

Firstly, you can actually directly help. You can see what someone is trying to achieve, and you can do it for them. Write that complex bit of concurrent code which improves the system reliability. Write the suite of missing tests which enables the refactoring necessary to improve the legacy system. Understand how to use a rich API to deliver value in a novel way, producing the prototype that lights the way.

I call this “lifting the weights”. You can see someone who can’t lift a heavy weight. Your experience has made you stronger, and you can lift the weight for them.

This mode often gets downplayed – “give a person a fish vs teach a person to fish” as the proverb goes. However, in my experience there are still many cases where direct help is a great boon – the other person may not be ready to learn, they may be off the beaten track, they may be time poor, there might be an inflection point of significant value just around the corner. Don’t rule out making a direct contribution to a project on the proverb alone – even if it is “skill easy but time costly” for you – it may still be the right way to help people and unlock value.

The second way, often adopted by more experienced people, is to mentor at a high level and low but stable frequency. Gain a high level understanding, which is necessarily abstracted from details due to time constraints, and then use your experience to recognize patterns and offer general solutions that you have seen work before. Point people at books with good descriptions of standard solutions and their trade-offs. Show them frameworks which help them structure a solution to their problem. Introduce them to a technique which is novel to them, and that you have a hunch might help them.

This is “being the coach”. You’ve lifted other weights before. You can tell them what you would try and why, and you are likely to be right about it working. At the very least, you are likely to be more right than average, and thus you can tip the scale in their favour.

This is the most common way I see very experienced people helping. It can scale extremely efficiently – one person can coach many others. You can create long-lasting “momentum change” for people by guiding them at a high level. It can be productively blended with direct help – once you identify the part of the problem space which is sufficiently different to the general cases you have seen before, you are well-placed to dive deep and contribute directly. Of course, direct contribution will also increase the necessary time commitment.

The third way, and one I think I use more and more in long term mentor relationships, is to have the person describe their solution (or partial solution) and then pick holes in it. They will probably have fixes for the holes, or they may explain why certain things can’t happen. You can use your experience to identify failure modes, or cross-cutting concerns, that they may not have accounted for.

I call this “being the weight”. You are intentionally providing a tailored level of resistance to help the person you are working with to improve their technique. You don’t necessarily need to have the solution, you need to understand the characteristics that good solutions have.

This technique can be an effective way to bring your problem-solving ability to a domain where you are not the expert. Similar concerns arise in many different places, and ideas from one domain can often be transplanted. Even if the person explains why an idea can’t work, or a failure won’t occur, in their scenario, I’ve found it can be valuable to dig into the details of this. It is not uncommon to find other problems when checking the details. I’ve also seen people have their new, great ideas in the course of trying to explain why a naive idea won’t work.

You do need to be careful to understand that the other person is the expert. You need to present your ideas expecting them to get pushed back on. Your goal is not to seed ideas (as a coach would), nor tell them what to do (and lift their weight). Your goal is to guide them to refining and improving their solution, by using your expertise to identify its rough surfaces and sharp edges.

As described above, I’ve applied it when there’s a proposed solution in play. This isn’t necessary – simplifying a problem to help someone find a starting point can be a way to teach less experienced folk how to get traction on a problem. It’s also an effective technique even for quite experienced collaborators – an active form of the more passive technique usually referred to as “rubber ducking”.

There are two additional, indirect and yet valuable, outcomes of this approach.

Firstly, you will help the person get better at explaining to an intelligent non-expert why their idea will work. This is an important skill, and quite distinct from refining a good idea, or executing on a good plan. It’s also vital in an environment where many ideas, good and bad, are competing for investment.

Secondly, the other person will probably learn about problem-solving and thinking deeply by watching you do it. These skills are difficult to teach and acquire. Giving a learner the opportunity to watch you problem-solve in a context where they have the depth for understanding what you are trying to do can give the learner informative insights into the problem-solving process itself.