Solving problems in projects is not always easy. The initial solution we wanted to apply may turn out to be insufficient. Often, many possible solutions differ in complexity, labor consumption, and risk.
We may have many questions:
- which solution will be the best?
- haven’t I forgotten anything?
- am I doing overengineering trying to solve the problem?
- how will it behave in the future?
- doesn’t the team have other solutions I didn’t come up with myself?
All these questions can cause us to self-doubt. However, large and complex projects are just complicated.
You don’t need to know the entire system
A large system can have many components that you don’t know well. One person can’t be able to answer all of the above questions in the context of each module you have in the project.
Understandably, you don’t know too much if you are a new team member. Even if you are a super-mega-1000x-developer, there are probably components that are not well known to you. It is worth not to decide by one person. If the team is involved, you reduce the risk of losing knowledge in a situation where this one person decides to leave the company.
Additionally, based on the rubber duck method, it is worth talking about our problems and ideas with others. They may pay attention to something initially unimportant or completely unknown to you. In the worst case, it turns out that your team does not have the necessary knowledge, and you have to look for it in other teams. Maybe it is something completely new, and you need to get more people involved to think about the problem.
Prefer asynchronous communication
Meetings are great, but you are unlikely to solve the problem if you spend half your working time with them. I mean cases requiring code changes, of course. Even if your problem is very complex, a well-asked question on the corporate messenger chat can result in a reply in minutes instead of spending hours in meetings.
Try to provide as much helpful information as possible. Indicate what you have already tested, what you had a problem with, and what your other ideas were. Let the team reflect, and they may be able to explain everything.
If a meeting is necessary, limit the number of participants. Don’t waste the time of completely unaffected people. Also, try to stay focused on a given topic and avoid side topics. There is no point in extending the meeting any longer than necessary. If the problem has been resolved after half the scheduled meeting time, thank everyone and end the meeting.
However, if it is longer than expected, try to summarize it and postpone the discussion. Try to choose asynchronous communication later. Sometimes it is enough to clarify a few issues, and you do not need to involve the entire team.
Be precise
If you have a complex problem to solve, start by verifying yourself. Make sure you understand all the requirements well. Also, ensure the problem is well-defined before proceeding with the action.
If you encounter an obstacle you cannot overcome, think about who can help you. Summarize all the attempts you have made. You will be able to discard what you have already checked yourself.
Present the possible solutions and point out the advantages and disadvantages of each of them. But don’t do it in your head. It would help if you wrote it down so the others can use it.
Avoid any distraction of responsibility
I have already referred to it in the topic of meetings. Try to keep the group you ask for suggestions and help as small as possible. The problem with asking everyone is that nobody feels involved. Everyone expects others to get involved and explain the problem. It is what is generally known as the diffusion of responsibility. If you have any idea who might have the necessary domain knowledge, start with that person.
Git can be very useful here. If you are modifying something, start with the person who changed it before you. It is possible that they had similar doubts as you.
Try to be helpful to others
When you expect help from others, remember that it works both ways. If someone has a problem and you know the solution or can help in any way, try to do it. People will more often try to help people who helped them earlier.
Don’t be afraid to admit that you don’t know something. You may not have yet come into contact with a particular part of the system. For the other party, however, it will be clear information that at least you wanted to help. Over-communication is better than being silent.
Act!
If you did not receive help despite your requests, you must select the best solution. Make a decision and implement it. You have a limited time. Perhaps it will not be the optimal solution today. However, you have a chance that you will make me move forward a bit. It is possible that in the future, someone will improve what you presented.
Don’t be afraid that something will go wrong. At most, you will change it again. Failure isn’t fatal, but failure to change might be.