According to a study done by Schultz and Schwartz, work-related changes are one of many top stressful events that could happen in our life. Anything from, finding new occupations, hiring and onboarding processes, or starting a new software development process are in this bucket.
If you are like me when starting a new project, imposter syndrome and overthinking kick in. Am I the right fit for this job? Can I provide value to the team? Do I have the skills to fulfill my role?
But there is another thing you might feel in this situation. It is exciting to learn, try and experiment with new things. Also to challenge and prove yourself in a new environment.
In the past everyone knew what you did, what are your strong sides and what can you bring to the table. Now, it does not matter what were your past achievements for a new project, you are a blank slate and you need to prove yourself to the new team, and stakeholders and build rapport and your reputation in this “local” environment as a reliable and valuable member of a team.
Doing so will produce 2 major outcomes,
– will ease up at some level of the imposter syndrome and stress along the way.
– will give you the ability to introduce change and improve processes and behaviors inside your team (a new challenge that will bring new value to the project).
So without further ado, below you can find a few tips that I have used and refined when I start a new project. I will try to make them as ambiguous as possible to be relatable in different contexts no matter how good or bad the onboarding process, what role you are filling in, or the business side of your project.
I have divided these tips into 3 categories.
- Where to start
- Work attitude and balance
- Feedback (recommended only for people in leadership roles)
Where to start
Let’s take it back to basics
You are getting into a new ecosystem. Feel the room and just go with the flow of what the project has to offer.
During that time, find out
- What is the organization chart?
- Who are your coworkers?
- Who is your manager/lead?
- Who can you ask for help?
- What processes are happening in the team
- What are they?
- Who is the owner?
- What are the deliverables?
- What is the product
- What kind of product is it?
- Who uses it?
- Why do they use it (What problem it tries to solve)?
- What are things that people dislike in it?
- What do you need to test it?
- What tools do you need for your job?
- What tools are forbidden to use (if any)?
- From whom you can get them?
Remember also that everyone in the project (especially if it has been existing for a while) is doing their work based on a context that you may not be aware of. There is always a bigger picture to it.
That is ok and remember to not assume and judge their work.
Observe, question, and understand why things are the way they are.
Notes notes notes!
During your first days there will be a lot of overwhelming information coming through. Trust me, your brain won’t store even a quarter of it.
That is why one of my best friends during this period will be the notes that I’ve taken.
And regarding them, I think about the availability, shareability, and structure of my notes.
There are many tools you can use for note-taking. First, establish the needs. For me, handwriting is not an option, so I need something that:
- I can use it digitally, preferably on some mobile app.
- I can draw in it
- I could later easily put in a proper structure
- I can share it with other teammates (so at least my notes can be a starting point for any missing documentation).
For me, Evernote and Google docs work perfectly for this.
Regarding the structure of notes, there is nothing fancy about it. Proper headers, for titles and side topics related within the note plus color headlines with legend.
But there are a lot of other ways you can store your notes from graphs, bullet journalling, mind maps, and more. For more information, I will leave links in the resources section.
But one thing is certain – Note-taking is a must, even if You will do it scribbling on a piece of paper is better than nothing.
Learn the dependencies within the product
The product under development does not exist in the void. The functionalities that were and will be developed are based on a certain context. The decisions of what and how things must be done are not made on a whim. That is why (and here my inner overthinker is coming to play) think about other dependencies that are coming into play during software development.
Whenever I need to test something, there are a few questions that come into play:
- How does the new thing connect to the overall product from a technical view?
- How does the new thing serve the business needs of customers or stakeholders?
- How does the new thing connect to the quality criteria that we follow?
- What are the risks associated with the change?
- Is there something more that I need to know?
Let these things influence the approach to how you will conduct your work.
Another thing that I observe during working on a project is looking upon things that “slow the team down”.
It could be anything from the ways we develop software, through processes related to it, to working with collecting data, or the effectiveness of meetings. Every team has its own story.
If you are in a testing role, you can in my opinion be a perfect person to test these things. My reason is that you can use the same skills that you are using to test the product to test these project-related topics.
For what to look upon? Is there something:
- That can be done easier?
- Fewer steps? Different process but the outcome would be the same?
- What takes more time than it should?
- In the process that can be automated/scripted?
- What annoys your teammates?
- What could improve any feedback loop channels?
- What could improve the time to market?
Learn from other sources
Following the Pareto rule, more than 80% of software is nothing new in the market. Why not take advantage of it? First, ask if anybody knows who your competitors are on the market. Then research what they have to offer to the public.
Verify and compare what are the differences between the competition and your product in terms of functionality, and user experience to any user guides or social media posts. You can even sometimes sign up and request a demo!
Don’t stop there!
Your prior experience or even any case study that you get from your peers or any conference speakers can be an additional source of knowledge that can give you new ideas on how to solve existing or future problems for your team.
Onboarding? hijack it!
Onboardings can be messy and a lot of things can go wrong. There is a chance that there is not enough time for a proper onboarding process. Maybe the person responsible for a crucial area of expertise is gone. Or the process was not a priority for a long time and is neglected and therefore outdated. Or simply there are far more important things that the team needs to solve right now.
Yet, even when things are going according to plan, you can and should take initiative and ownership.
In the link below, you can find a project “Handover checklist’ and what is cool about it is that the onboarding is just a project handover on a smaller scale.
https://docs.google.com/spreadsheets/d/1L9xGy1gxXvVbGKvAwYJrwbfppvPJsfyg_FYqpvDq0ao/edit?usp=sharing
How can you use this checklist? Present it to someone from the new project – senior or onboarding owner – and together adjust it to reflect the onboarding requirements.
This will give you a scope of knowledge that you need to acquire during your onboarding (or at least have a comparison if the onboarding plan is missing something). With the added benefit of traceability of where You are in the process of onboarding – to answer the nagging question “Are You done yet?”.
Second of all, it can serve as a future improvement list in terms of what could be documented and transferred to future team members.
Map the product
Regarding mind maps. Map everything along the way. Mainly for not getting lost (remember the overwhelming information from the previous point) and reminding yourself about important areas, blockades, or set next places to charter.
Mind maps help to visualize, group, or communicate information in the project. Upon which, we can set our goals.
Ok, so what can be mapped?
Anything that is concerning our product that we need to learn about:
- Product coverage outline – It is a set of product factors that we want to observe in our testing session to create new test ideas.
- Quality criteria – This is a more fancy way of asking, what is the definition of “good enough” for our client, so things we need to focus the most effort on.
- Feature specification – a map with all information from the business and tech side regarding the feature. That can be later shown in the meeting and a brainstorming session about it.
- Risks – things that could severely endanger our product.
Project-related items, to find information or identify bottlenecks:
- Organizational Chart – to know who is who in the project and what are the communication channels
- Processes existing in the project and the state of it
- Oracles – things or people that can tell us how something should look or work like
- Any documents used by the team
- Ideas that are floating during meetings that would be nice to elaborate on later.
In the resources section, you will find examples of how to start your mapping journey.
Work attitude and balance
Fight the Flinch
As I wrote before, starting a new project equals being a blank slate. You need to prove yourself in front of new challenges no matter the role. Which overall will lead us to go out of our comfort zone.
It is easier to work on the same task over and over again and be accustomed to it and take it hand on all the time without breaking a sweat. But when the bigger challenge comes, we are not always facing it head-on like before.
Our fight or flight system takes command of your body, and we… just… flinch.
Flinch is about a moment when we shrink up before a big moment.
It is with us before any difficult conversation, speaking to the client, or doing a presentation.
We are anxious about something that did not happen yet, or would barely hurt at all.
When trying something new, we are not keen to move out of our comfort zone because of fearing failure. And that zone of fear could be a huge leap to go through.
At that moment, we start to rationalize our choices. We start to bargain. Saying that this is stupid or pointless. We are just giving up to flinch.
That is why it is important to train and build a habit of seeing flinch as it is and going forward through it.
This way we can slowly but surely increase our comfort level even further.
In the book “The Flinch” by Julien Smith, he writes about a method of confronting this feeling He encourages the reader to try to do something simple, yet daring. Just to take a cold shower every day to see how your body and mind would react.
I can honestly say, It sucks like hell in the beginning, but after a while, your body is adjusting, and you realize that it is not so bad. And in the end, if you survived this, think about what worse could happen during your work that day.
Be efficient with your time
It is easy to over-commit your time to a task. We want to be perceived as someone that has a keen eye for details, especially in a testing role, or there can be another side of the coin, and you want to be a perfectionist. Here is a hard pill to swallow. Most of the time “good enough is perfect”.
In my work, if we want to aim for perfection, it will consume a lot of time. And there will be cases in which most people won’t even notice the difference. For these reasons, 2 things keep me on track.
- Pomodoro method or session-based work – In which, I set up a goal that I want to achieve in specific time boundaries (from 30 to 60 min sessions), and then without any external interference I focus on it.
- Ask for feedback – Especially when I am chartering to unknown territory, I give myself checkpoints to verify that what was done already is ok and that I should go further. It lets me know if I am going in the right direction or if it is good enough. Additionally, Discuss any points that could be ambiguous and provide rough estimations (or ask for more time) when a given task can be delivered.
- Overestimate – remember that You are in the learning process. Leave the space for the unexpected!
Be consistent
Before moving any further, please let me know what you can observe about the below melody.
If your answer is, that the melody is getting louder. What you can experience is a Shepard tone. An auditory illusion of a tone that seems to continually ascend or descend in pitch, yet ultimately gets no higher or lower.
A fun phenomenon, but what has anything to do with working on a project?
From my experience, my work was acknowledged, not when I pushed myself to the limit and overdid myself, but when I constantly stayed at the same pace. Just like in Shepard’s tone, the tone is consistent.
I am not saying that we cannot take an extra step from time to time when the project is requiring it, but when this “extra step” becomes a rule, and it is something that is required, then sooner or later you are going to reach someone’s unfulfilled expectations.
On top of that, your rest schedule and well-being will be hitting lower and lower points.
That is why I recommend first of all finding your own pace of work that you can maintain every day. When we push ourselves above and beyond our limits (have too high a pace), we need a lot more time to recuperate from the effort taken, and overall, our progress is growing slower.
How to find your pace? I am using simple metrics from the book “Effortless” by Greg McKeown.
“Don’t do more today that you can completely recover from by tomorrow”.
The benefits of that are
- Brain capacity reduction. When your brain is at full capacity, everything feels harder to do.
- When your brain is full of outdated assumptions, negative emotions, and toxic thought patterns you have less mental energy available to perform what is most essential.
- When you are physically rested, emotionally unburdened, and mentally energized. You are completely attentive, present, and focused on what is important at that moment. You can do what matters most with ease.
Don’t overdo it, be consistent!
Done for the day list
How is your to-do list? From time to time mine looks like a proper product backlog.
Create a “Done for the day list”. Instead of having a “to-do” list that gets longer. Have a list limited only to items that would constitute meaningful progress. In other words, what needs to be done is that you will be satisfied by the end of the day.
This has two benefits.
- No over hours to finish another item from a neverending to-do list.
- You will have a hard cap to remind yourself that you are done for today and that what is left is rest, which is necessary to be productive.
Project feedback session
This section I would only recommend this for those that feel confident in their skills and are not at the beginning of their career.
After some period, it could be whenever I feel confident about my understanding of the state of the project and product and how you can help with it. I am conducting a meeting with the management of the project regarding the topics that can be improved with ideas that how it can be achieved.
The big thing not to do is not be “that person” that whines about every single wrong detail about the project. It never leads to something productive. The threat is more like a feedback session for the people involved in which you do a reality check of current smaller or larger issues and bring some ideas to the table on how to resolve them.
Hope we are clear on that.
The whole process is divided into 3 steps:
- Find the perfect https://slidesgo.com/ presentation template. They provide professional-looking templates, and most of them are free to use (just remember to leave the license page).
- Create a simple presentation structure that will contain
- Information on what was done till now
- Any work you have done in your role
- Preview of your mind maps
- What was not yet delivered or is planned to be done next
- Product/Project related topics
- What is the risk that could affect the project?
- What are the bottlenecks in the project?
- Information on how things could be improved
- How and what you can help with?
- Next steps
- Information on what was done till now
- Conduct a 0,5-1h feedback session involvement in the project and your insights.
Thanks to this approach, you are doing something that is
- Unique
- Takes people off, guard.
- Low effort – most work you are already doing during your learning period in the project
- And most importantly it builds your reputation in the project as someone that goes above and beyond their role.
Summary
Congrats on reaching this point.
During your time here, I will showcase topics from learning, knowledge acquisition, and some tools that can help you along the way, through topics related to work attitude and balance and finishing with topics related to project feedback and going above your role.
I hope that these points will help or at least broaden the perspective of what to look at during your first days on a new project. And I wish you all the best and good luck in your new project journey.
Resources
Introduction to Product mapping
- Product Coverage Outline by Huib Schoots
- https://www.youtube.com/watch?v=NUojNfDjIjw
- Mind, Map, and Strategy with Fiona Charles – https://www.youtube.com/watch?v=W2eqfcX7Swg
- Test Coverage: How A Mind Map Can Help by Prashant https://huddle.eurostarsoftwaretesting.com/mindmapping-killer-way-increase-test-coverage/
Books:
- “The Flinch” by Julien Smith
- “Effortless” by Greg McKeown
Survey
- Schultz and Schwartz http://userpage.fu-berlin.de/health/materials/lifeevents.pdf
Handover/Onboarding checklist By Patryk Oleksyk https://docs.google.com/spreadsheets/d/1L9xGy1gxXvVbGKvAwYJrwbfppvPJsfyg_FYqpvDq0ao/edit?usp=sharing
Connect with Patryk:
