When solving problems, it’s not always just about getting down to them and solving them. Very often, one gets down to a task just to find themselves being stuck. The initially proposed solution seems no longer valid and the infinite number of other approaches makes one confused about the task only more and more.
Possible solutions vary in all terms: complexity, risk of introducing breaking changes, matching current team practices and, last but not least, the time it would take to solve the problem when taking a given approach.
Not rarely does a person end up observing: a proper solution would involve bigger changes; possibly some alterations to the existing system, rearranging its’ architecture, starting a new part of it.
Now multiple questions emerge in one’s head:
- Should I go with the bigger change? How exactly would it look?
- Is it worthwhile for the team and the product to take the long way around the problem?
- Am I not overengineering things?
- When drawing the “proper” solution, didn't I forget about something?
- What if after all, these two solutions will be equal in effect? Which one will be more future-proof?
- How can I ensure that other people in the future will make the same decision about such problems?
These are all difficult questions. In a perfect world, a person assigned to a task tackles them one by one and eventually comes up with “the best possible solution”...
… unfortunately, that very often isn’t the case.
First of all, in a large system, it might be simply impossible for a single person to answer all the questions.
Secondly, they might be a person that is new to the company. They might not be familiar with all the parts of the system yet.
Thirdly, even if they were the mighty full-stack 10x engineer, would you want to trust an important decision about your system to be made by a single person?
Copious research and articles about working in a group, pairing, “rubber duck debugging” state clearly: it is beneficial to speak to other people about your ideas. Even if you’re quite sure that you already know what “the best possible solution” is, saying it out loud to somebody else most probably will improve your conclusions and make your thinking clearer and more concise. Asking for help Given the above facts, let’s say you’re an engineer that has received a difficult problem to solve, and you’ve decided that it would be worth consulting it with others.
How to do it?
1. Ask your team
If you’re a part of a small agile team, which is familiar with your day-to-day work, consulting your problems with them is very often the best first thing you can do. Try telling them about your problem during daily standup and what ideas you have for solving it.
Perhaps your teammates will have some ideas on their own? Maybe they’ll know who’s a good person from other teams that you should talk to?
It never hurts to ask your team. In the worst case scenario, you’ll take one or two minutes of just three, four other peoples’ time. It’s not that bad.
2. Ask publicly
If your team doesn’t have the knowledge you need, try going beyond.
Don’t go straight to your CEO or the #general slack channel yet, though. Think what the best group of people to ask about your problem will be.
You have a question about graphic design? Ask the graphic designers. A question how analytics work? Ask people from analytics. Or the devs that have been developing the analytics integration.
3. Prefer asynchronous communication whenever possible
Don’t create a meeting with all the graphic designers yet just to ask them about some button color. Even if your problem is complex and might involve having a discussion and a general agreement amongst all the designers, try explaining your problem first by starting a conversation on a Slack channel that includes all the graphic designers.
Let them think/respond to your problem asynchronously via chat. Maybe the problem will be solved with just a few messages sent back and forth. No need then for calling a meeting.
4. When at a meeting, move the conversation to a smaller group as soon as possible
If you find it easier to talk through your problem in a synchronous meeting, fine, do so. If you have a weekly recurring meeting involving all the designers to discuss some issues, it might after all be a good place for discussing your design problem.
I’m not a big fan of it, though. The larger the meeting group is, the bigger the chance is that you’ll be wasting somebody else’s time. Some people might have nothing to add, nor will they be interested in your problem at all. If your case takes 15 min to discuss and there are four people in the room that aren’t interested in it, nor have anything to add to the conversation, that’s in total somebody’s one full hour of work spent on literally nothing.
Thus, if you decide to talk about your problem in person in a large meeting group, make sure it is a proper time and place to do it.
Also, try sidelining the conversation to a separate smaller meeting group as soon as possible.
One way to do it: in a larger group, describe your problem very briefly, and ask for a quick input who might help you with it. Then, arrange a separate meeting with them. (Perhaps just after the large meeting ends.)
5. Be concise. Define your problem clearly
If you have a complex problem to solve, to which you need somebody else’s input - it is your job to make sure the problem is defined clearly prior to asking for feedback.
Helpful questions for defining your problem: What is the current and the expected state of things? Why is the change important? (and ask this using the 5 Whys method) What are the possible solutions and their pros and cons? What is your current bottleneck in finding the best possible solution? What is your current idea to fix the above bottleneck? What research has been done already or is planned to be done?
Do not keep answers to the above questions in your head. Write them down - wherever it is the best place for it in your company, e.g. Notion, Google Docs, Confluence, Clickup, Jira. Share them with your teammates while asking for feedback. Make sure they’re familiar with the problem before you start asking questions.
If it is your task to solve the problem, it is your job to make it easier for others to help you solve it.
6. Ask specific people
Problem with asking a group of people for help is that the larger the group is, the higher the chance is that nobody will actually help you. That’s generally known as diffusion of responsibility.
As a solution to that phenomenon, at first aid workshops, it is a common exercise to choose a random, yet specific person, and tell them explicitly - “Hey, miss in the yellow shirt! Could you call the emergency please!” instead of saying to strangers “Call the emergency please!”
Analogically try a similar approach in getting feedback from others. Have you found yourself in a situation where your problem is complex, when you’ve already defined it clearly, asked specific people for help, but all that you get from them is just 🤔 👍 emojis on Slack? Well, that definitely might mean that your problem is non-trivial, but it also might mean you’re hitting the “diffusion of responsibility” moment.
As a solution, try to guess who could be a good person to help you. If there’s a few of them, pick randomly one or two. Then name them explicitly or ask them in private.
For example, let’s say you’re touching code important to analytics. In such a case, find the last person that has touched the code relying on it. Find the person that has been designing that part. Find the lead of the analytics team. Find any random person from the analytics team that you haven’t spoken to in a long time, and would like to meet them. And ask them in person if they could help you.
7. Give them time to answer you
Whether you're asking somebody for help, give them time.
After all, they might have their own important problems at this minute. Assuming they’ve seen your message and follow basic savoir vivre rules (i.e. they do respond to private messages), they should respond to you in a day or two max.
To prevent yourself from being blocked by waiting for answers, try to predict upfront that you’ll need somebody else’s help, and ask them about it in advance. If somebody else is more experienced in the subject you’ve been given, their one minute of help might save you 30 minutes of trouble. The sooner you consult them, the better.
8. Be nice
Minimize the pressure you’re putting on others with your problem. Instead of forcing them to answer you, try asking for guidance. If they’re busy, when would there be a good time for them to help you? If not soon, do they know anybody who could be another good person to help? If they do not have any fruitful ideas for your problem, is there anything you could do that could help them provide you with more useful feedback? For example, if you researched some specific part of your problem more deeply, would that help them in giving you an answer?
Be nice also when you’re on the other side of the problem. If anybody’s asking you specifically for help - please, do not respond with silence. You don’t have to answer right away. But do so in a reasonable time. Or say when eventually you’ll be able to help. Then, set up a reminder for yourself about it. (On Slack it's as easy as clicking “Remind me about this in … hours”.)
If you don’t have enough knowledge or experience on the matter to help - say it, don’t be shy. At least the problem owner will know that they’re not the only ones here being confused, and that they perhaps need to find somebody else or some other way to move forward with their case.
Always over-communicate, never under-communicate.
9. Simplify the problem
Sometimes even after asking people both in private and in public, no best possible solution emerges yet. You might still not get useful feedback (“I don’t know this part, sorry” “I know as much as you do” “Both options have their pros and cons.”).
If so, double down with your research. Divide and conquer your problem to smaller ones and make decisions on them separately. Bring down the possible solutions to simple pros and cons. Try to choose already which one will be the best. When doing so, remember to explain why option A will be better than option B.
Whenever you come to new conclusions with your problem, remember to inform the necessary people. However, if you’re at the end of your research, now instead of asking “what should I do?”, say “ok, so I’ve thought this through, and this is what probably I’ll do: …”. Plus, give them time to react - with important decisions, a few days is best.
10. Act
If you asked for help from anybody that could help you, gave them reasonable time to react, you researched the problem in a detailed manner, and came to some good-or-almost-great conclusions - bravo, you’ve done all you could.
If nobody brought objections to your thinking after a few days, you can safely assume that the company as a whole has no better ideas on solving the problem than the one you drew in your conclusion.
So now, even if you still feel puzzled about your solution, the best thing to do is to act. Go forward with the decision and implement it.
One has to make the decision at some point. Time is limited. Given infinite time, yes, one could continue with research for weeks to find some better solution. But we don’t have infinite time.
Thus, it might be more worth it to choose a suboptimal decision and implement it quickly, rather than to do thorough research for weeks and take everybody’s precious time at meetings to achieve consensus.
When is it worth it to keep doing more research, and when not? Of course, it depends. What I like to do from time to time, is to look at the problem every few days with a fresh look and a thought “Should I continue with the research? How long would it take? Are we good enough yet to make a decision that we won’t be regretting later?”.
In summary
Follow this workflow and any complex problem will feel much easier:
- Do not solve complex problems alone. Seek feedback from others.
- Ask your team first.
- If that fails, ask other people in public.
- If that fails, ask other people in person.
- Prefer asynchronous chats to synchronous meetings.
- Keep your problem well documented.
- Predict bottlenecks of your problem and tackle them as soon as possible.
- Be nice to others. Don’t be too demanding. Be helpful as well.
- Decide when to act if you ended up in a dead spot with the problem analysis.
Also remember: these pieces of advice don’t apply to just the engineering problems. The same approach for gathering feedback and solving complex issues might be used by anyone: designers (how should a website be designed?), product people (how should the system work?), stakeholders (what projects should be planned for the next quarter?).
In Appunite, we’re experimenting with this workflow on a regular basis, not just during software engineering, but generally, in all parts of our day-to-day job. Such an approach lets us share problems across teams. This helps us avoid the situation of reinventing the wheel, when one team repeats the problem analysis done already by another team in the past.
We believe that such an approach, focused on teamwork and close cooperation with our partners, is the right one to create sustainable teams building useful products. For more information, read more about our perspective on software development.
Do you follow a similar approach in problem solving across teams? Would you add/change anything in it? If so, please tweet about it.
