When starting a new job, we commonly experience some difficulties. Sometimes, this is because the team needs to provide us with more information or because it is a startup with no documented processes.
The desire to show proactivity and productivity will quickly fade if nothing changes the situation. Here are some tips that, in my humble experience, have helped me deal with these circumstances:
It would help if you clarified your doubts, even when you think it is a silly question. Asking is something that people genuinely value, contrary to what we tend to believe!
I’ve found that saying an affirmation followed by a confirmation is an effective trick: “The idea is that developers can generate a token that does not have an expiration date, right?”
Mind your manners
When you’re “the new one,” you want to build up trust and demonstrate the productivity, but the more challenging part is figuring out how to do so in a friendly way with your new coworkers.
Remember that imposing things or ideas when new to the team is sometimes a good idea. You should pick the right time and words.
A good way could be: “I’ve been researching our process a bit, and I think that by making some modifications, we could obtain even better results. Would you like me to do a proof of concept and analyze the results with the team?”
A wrong way: “The process we have is not working. In the last company where I worked, we did it differently and had better results.”
Propose meetings to understand the goals better
If the onboarding (if it exists) was insufficient, or if you are curious, suggest to the product manager or leader to block some time on the agenda to discuss the project and company. Not in a technical way, but to understand the goals, the behavior of the consumers, etc.
The future ideas or solutions will be more accurate the more domain knowledge you have. This will align you with the team’s goals and the company’s Mission and Vision.
Sessions to facilitate knowledge sharing
It’s prevalent in teams that one person concentrates a lot of knowledge, and that’s not the best scenario to work in. Documenting the code properly or describing how processes work is essential.
Better than complaining is continuously proposing new alternatives. You must identify the proper time and approach to suggest them. Here are three things we can do to fix this kind of problem.
Deep dive into <topic>
It is a session to treat, understand or refresh specific topics. For example: “Transaction Ingestion.”
Teams can repeat this activity every two weeks. During the week that the session is not held, the following topic and who is most suited to lead the session can be chosen by voting.
Remember to add visual support, whether a presentation or a conceptual network, because this significantly increases the value of the session.
This activity is suitable for all audiences/areas and can be pretty fun. Like deep dives, it can be done twice a week by choosing a topic the week before.
The session uses a convenient whiteboard/wall/window, sticky notes, and markers. Doing it virtually, Google Jamboard, Miro, etc., works well.
A sticky note containing each participant’s name is placed on the right side of the board, vertically and one below the other. This will be the order of the turns they go to the board. The first sticky note usually has the name of the person leading the session.
The activity consists of participants in their turn placing a sticky note indicating the step that follows the previous one. This way, the chosen process/topic will be described step by step in chronological order until it ends.
It is understandable to be unsure of the next step or make a mistake. It’s part of the game.
Each step has to be as atomic as possible.
Wrong: A sticky note saying, “Transaction is processed.”
Right: Three sticky notes saying: “The server consumes an event from AWS SQS,” “The event schema is validated,” and “Depending on the type of event, X function is executed.”
Only the next person can correct a sticky note containing an error. If, after three turns, the error persists, any participant can fix it.
The name of the game comes from the fact that, just like in golf, we are closer to finishing the game or describing the entire flow diagram of the process in question with each turn or stroke we make.
This is not an activity 100% focused on knowledge sharing, but rather to prevent the same people from always answering doubts and questions about issues related to engineering or team processes.
It not only de-stresses people who are frequently more active (typically the oldest in the role), but it also encourages the person in charge that week to explore responsibly if the answer is unclear.
The goalie rotation can be weekly, bi-weekly, or by sprint, depending on what is most practical. Ideally, the selected person should be responsible for a different period of driving any of the activities mentioned above.
I hope that some of these tips have been interesting for you and that you can put them into practice sometimes. Remember that it is essential to raise your voice.
And if you know of any other good ideas or have any experience that can help others, please tell us in the comments.
Thanks for reading!