Where are the test reports? Who’s responsible for UAT and where can I find the timing? Wait, I thought high-priority issues should be hotfixed immediately - why is this one scheduled for sprint 25/8?
Chaos.
The same questions, over and over. Everyone’s sweating, working hard, but nothing works the way it’s supposed to.
Most project chaos comes down to one root cause: nobody established what everyone needs to know. That’s a communication problem, and it’s fixable. So fix it. I know, I know. Sounds like advice from the most useless coach you’ve ever worked with. But hear me out.
When you’re getting the same basic questions throughout a project, always via Teams or Slack because “it’s just a quick question”, your flow is already ruined. You’re frustrated. You want to send an impulse message. But you’re a nice person. You’re kind to people. So you answer. Nicely. Again.
What if you could write that rude email, but nobody would ask the recurring questions because they already know the answer? For every question that’s been asked before, the answer is already there.
The best solution is what I call the Beacon.
You might call it a dashboard, a charter, a home page, an FAQ, a PID if you’re into PRINCE2. I call it the Beacon because it’s always the first thing you check when you need information. It shows you the way.
Okay, so you create the page. You’re done. Everyone’s happy.
Could be the end of the letter but…
I have more to say.
You have the document, but nobody’s reading it. You even sent an email about it. But we’re busy. Emails that start with “Hi All” or “Dear Colleagues” go straight into the Important folder, to be read when we have time for a deep breath. Spoiler alert: we never have time.
That’s why I prefer a meeting. I try to keep them short and interesting, starting with a big hook for the audience:
“If you pay attention now for 30 minutes, we’ll save critical hours throughout the project.”
I don’t give them the one-pager immediately. I tell them to pay attention. Write their questions in the chat immediately. This way I get attention and instant feedback.
The meeting where we share the Beacon’s light.
Let’s call it a kickoff, because that was the most common name used by companies I worked with. I always default to an actual, synchronous, everyone-in-the-room (or on the call) meeting. Because reading is optional. Showing up is less optional. You send a doc, people skim it, maybe. You get them in a room, they have to at least pretend to pay attention. And more importantly: they can ask questions. They can say “wait, what does that mean?” right there, in the moment, instead of carrying their confusion into week five.
Okay, you’ve got people in the room. Now what do you actually cover?
Where we are and why we’re here. It’s important to say that we’re at the kickoff meeting for the XYZ project, where I’ll show you everything that counts as basic knowledge for this project. You’re here because you’re part of this project and your role involves testing.
Timeline of the project. High-level plan. A quick Gantt, an overview of the main milestones and timeframes. Not the detailed sprint-by-sprint breakdown.
Ownerships and stakeholders. Basically a RACI, but don’t make it too complicated. Business areas, technical teams (in agile setups: POs), architects, testers or lead testers. The list depends on the size of your project or company. Which decisions are made by whom. Who sets priority, severity, delivery dates, expected releases… anything similar.
Common language and the basic bug stuff. What does a bug look like? What’s the flow? Priority and severity levels, with descriptions. What do we mean by “done” or “ready for retest”? What do we mean by “regression”, “critical bug”? Every team has slightly different definitions. Nail them down now. Because three weeks from now, when the dev says “it’s done” and you say “it’s not tested yet,” you’ll want to point back to this moment where you all agreed that “done” includes passing integration tests.
Where stuff lives. Requirements, test cases, bug tracker, CI/CD pipeline, monitoring dashboards, the Slack channel, the Jira board, the Google Drive folder someone created six months ago that has the “really_final_october_revision_final_v3” architecture diagram. All of it. One place. One table of contents. It doesn’t matter if it’s Notion or Confluence or an Excel file. Just make it the single source of truth and tell people “if it’s not here, it doesn’t exist.”
Rules, requirements, communication. As a test lead or manager responsible for testing, you have to say what your requirements are. First check the Beacon, then ask questions. Communication channels, which questions go where, what’s the response time. If you’re only communicating via Jira tickets, make that clear. I usually cover meeting structure here too, because it’s part of communication. Recurring meetings: when they happen, what they mean, why they’re important, what the agenda is.
What is the FAQ? With the Beacon you create a place for the source of truth so why not include a frequently asked questions section? Start with the questions you know people will ask, then grow it as new ones come up. Update it weekly. Bring up the newly added questions during sync meetings. Show this on the kickoff.
And I have one more slide, one more topic at the end. I always clarify the human side of how we work together. I require transparency and honesty, and the team will get my protection. Protection means I’ll be the one in the uncomfortable meeting explaining why we need more time or budget. Protection means when a stakeholder complains about testing delays, I’m the shield, not the team. But this only works if they tell me on Tuesday that something’s wrong, not on Friday when we’re supposed to go live. I want their honesty and transparency because with that, we can do something. So the slide has only a few words, but you talk about it in detail, because you have to share and make the team understand why it’s important, why those few words matter.
Maybe a bunch of this stuff is already in the company documentation, strategy, governance, whatever. I get it, this can feel repetitive. But repetition is kind of the point. You’re creating the map everyone uses, not the hundred-page manual nobody reads.
Here’s where it goes wrong.
The meeting that never happened (or didn’t include the test part). I learned this one the hard way. V-model project, traditional setup. PM scheduled the kickoff meeting. Invited the architect, the BA, the business stakeholders. Forgot the testing team. Completely. I found out two weeks in when someone asked during a coffee break, “they have no info about testing, because no one came from the test team.” So I quickly organized a separate test kickoff. Except now everyone’s annoyed because the PM was nice enough to make the decisions without me about bug handling. Don’t let this happen to your project. Communicate with the PM.
The meeting with no structure and no confidence. If you abuse the trust of their time, you’ll become another person who requires something. You won’t be a partner in their eyes.
The meeting with the wrong amount of info. Too deep and you lose half the people. Too shallow and you’re wasting their time, saying nothing. We want the right amount. Make the meeting about them. Make them interested in what you’re saying. It’s not easy, but if you prepare, and you prepare right, it can be done.
My biggest meeting involved more than 200 people. We finished the project on time, on budget. Of course it wasn’t only because of this meeting. But I didn’t feel like people were hunting me down with questions I’d answered a hundred times. Our meetings were effective even though there were people from business and people from IT (with big differences in knowledge and vocabulary), but they understood each other. The Beacon was updated weekly. At the same time when the implementation started, the UAT test case writing was starting as well. Most problems surfaced early because people asked questions. We had our rules, which we laid down at the beginning, at the kickoff meeting.
My smallest involved only three teams, fewer than 15 people. A really small agile organization developing one application. When I put together the document, they liked the idea immediately, because they had their first point of contact and it was not a person but a 24/7 available document. Some coworkers pushed back that the information wasn’t precise, and they didn’t want to use it because they would rather ask the person responsible. So I made a kickoff meeting. I confronted the skeptics with their own arguments, turned out they wanted to have the “startup feeling” (whatever that is). Ways of working change. People change. We learn. Even in small organizations or teams, if we keep the Beacon lit and maybe even repeat the meeting quarterly or once every six months, it gives value to everyone.
This is the unsexy work. Nobody’s putting “ran a great kickoff meeting” on their LinkedIn. But it’s the work that saves you. There are two big bonuses if you do this right: you’ll be a trusted leader within the team, and the work together will be much more fluid.
So what happens after?
You ran the meeting. Great. Now what? Someone (usually the test lead or PM) takes the notes, the links, the decisions, and puts them somewhere everyone can access. That’s your artifact. Your wiki page, your Confluence doc, your whatever. And here’s the key: it has to stay alive. Especially in agile. Your team wiki isn’t a “set it and forget it” thing. It evolves. Someone joins the team? Update it. A tool changes? Update it. A decision gets reversed? Update it. In traditional projects, you might lock it down after the kickoff and treat it as the baseline. In agile, it’s a living document. Either way, make it clear where the truth lives.
Keep it alive. In traditional projects, you might only revisit this at major milestones. End of a phase, mid-project review, whatever. In agile, it’s more continuous. Every PI planning, every new epic, every time the team composition changes, you’re basically doing mini kickoffs. Not full meetings every time, but at least a “here’s what’s new, here’s what’s changed.” The team that has a well-maintained wiki and checks it regularly is the team that doesn’t waste time asking the same questions twice.
So make the meeting. Build the Beacon. Keep it alive. Your future self, the one who’s not answering the same question for the eighteenth time, will thank you.
I need your help. I’m writing this newsletter for you.
Hit the reply and tell me:
- What’s the thing in testing, quality or process engineering that’s driving you crazy right now?
- Do you prefer deep dives like this, or shorter, tactical emails?
I will read and answer.
Until next time!
Thanks for reading.
Follow up
Last week’s newsletter was too long. I get it. More blog post than email. I’m thinking about this: maybe I send focused emails and save the deep dives for a blog.
For now, here’s a one-pager. Same content, without stories. Think of it as the tl;dr version.
Until next time. Thanks for reading.
