Slack is buzzing, meetings take over your calendar, bugs appear in production out of nowhere. And yet, you are expected to keep things under control.
Hi, I’m Olga, a QA engineer with 4+ years of experience. Today I want to share how I keep chaos in a startup environment manageable and what actually helped me stay sane.
⸻
So, what are these startup-ish issues? How did I get here?
Being a QA is like being a bottleneck sometimes. You are needed in almost every discussion. A bug that was not present on the dev stand somehow slipped into production, everything is on fire, and on top of that you are expected to find time for self-improvement and learning new technologies.
Otherwise, you risk becoming irrelevant. Hopefully, I am joking about the last one.
As a result, QA feels overwhelmed and makes mistakes that lead back to production bugs. The circle closes.
⸻
My steps are not exclusive. You probably already know them. But knowing and applying are two different things.
When you are overwhelmed, it is not that obvious to implement them. But with a small reminder and a bit of grounding, things can start to feel more manageable.
⸻
Basically, my problems boil down to the following:
• Too much incoming information
• It is unclear for the team what QA is actually doing throughout the day
• No time for work, too many calls
• I Am Documentation
• I Am the Infrastructure Gatekeeper
⸻
I. Too much incoming information (and how I filter it)
Slack chirps every five minutes. Incoming emails burst your inbox and you have no idea where to begin.
As for email, I suggest creating filters for the most relevant topics where your review is needed immediately.
For instance, in my company, if a task is promoted to the “Testing in prod” stage on release day, it is implied that you have to drop everything and start testing in production.
What did I do?
I created a folder called URGENT PROD TESTING. Any email where the status is “Ready for QA (prod)” goes there.
I personally check my email every 45 minutes. But I don’t check everything. I focus only on relevant folders.
If I see a number next to the URGENT PROD TESTING folder, it means that something important came up since the last time I checked, and it requires my attention.
The same goes for messages where I am mentioned by name. I created a separate folder for those as well.
⸻
Meeting reschedules also go into a separate folder. In a startup, plans change quickly, and you don’t want to miss updates among dozens of meetings.
If I see a new message there, I immediately check my calendar in case something was scheduled in the next 15 minutes.
⸻
On the other hand, I created folders for less relevant emails, such as weekly Confluence digests.
It is not that I don’t read them, but there is a lot of higher-priority information that needs attention first.
⸻
As for Slack, I muted all channels where QA is not the main focus, like design, content, HR, and others.
I read them during the last hour of the working day to stay in touch with the team. If someone mentions me by name, I still receive a notification.
The same goes for our QA group channel. Whenever someone mentions “qa-team”, we either leave a comment like “Started working on it” or tag the person whose attention is needed.
I also added a keyword notification for “Olga” in case someone forgets to tag me.
⸻
As for Jira notifications, I receive updates on tasks created by my junior QA (just in case, you know…).
Sometimes I ask her to do exploratory testing and create bugs, but it is my responsibility to review them. Since this is not urgent, I usually leave it for the end of the day.
⸻
II. It is unclear what QA is doing throughout the day
This one is easier.
Prepare your daily update in advance. Ideally, do it the evening before, when you are wrapping up your work.
Summarize what you did, add a few details, and describe how you handled obstacles.
It is important to document things while you still remember them clearly. Otherwise, everything turns into “I found a bug and created a report”.
⸻
Also, try to keep your communication visible to management.
I found that writing in the main thread and then following up with a direct message works best. This way, your work is visible, and no one asks why QA threads are silent.
If you had a call with a developer or analyst, take one or two minutes to summarize the outcome in the thread. This makes your work visible and structured.
⸻
Imagine there is a task on fire right before release.
All you have time for is basic critical path testing. There is no time for proper documentation.
In this case, I leave a comment like this:
Critical path testing has been conducted due to strict timelines. Thorough testing will be performed later, and documentation will be created. See Jira task […]
Then I leave the task in “Ready for start”, add it to the next sprint, and plan time for it.
This significantly reduces questions about what you are doing.
⸻
III. No time for work, too many calls
I am still struggling with this.
I tried blocking focus time in my calendar, but during rush periods, no one checks it.
I also tried introducing meeting-free Fridays, but it does not work in my team due to release schedules.
So instead of trying to change everything, I changed my approach.
⸻
When I schedule meetings, I always prepare an agenda. I attach Confluence pages, Jira tasks, and relevant materials.
This allows others to prepare in advance if they want to.
After the meeting, I send a short summary email so that everyone stays aligned.
I also record meetings, especially when discussing new functionality or training junior colleagues. This helps reduce repeated explanations later.
⸻
IV. I Am Documentation
I used to think: “This will take too much time, and I will probably never need it again.”
But every time I skipped documentation, I had to repeat the same steps later.
Now, whenever something is not obvious, I create a short how-to note.
It has saved me many times in urgent situations.
⸻
V. Infrastructure Gatekeeper
One of the strangest bottlenecks I experienced was being the only person with access to a system via OTP codes.
Everything worked fine until I went on vacation.
I suddenly received multiple OTP messages and had no way to respond. That was the moment I realized: this is not a person problem, this is an infrastructure problem.
After that, I stopped apologizing for being unavailable.
Instead, before going on leave, I clearly communicate access dependencies in advance.
⸻
Final thoughts
These practices are not perfect, but they significantly reduced the noise in my work. I now miss fewer important messages, react faster to production issues, and feel less anxious during releases.
And one last thing.
Whenever something at work annoys me, I write it down. It helps clear my mind, and over time these notes become a source of ideas for improvements.
We adapt quickly to problems.
But if you don’t track what drains you, it will eventually define how you feel about your work.
Top comments (1)
Please write what you think on the matter, I’ll willingly respond