A team can ship software while spending time on unclear requests, uncertain responsibilities or changes communicated too late. These problems can stay hidden if you only look at completed tasks. The people doing the work see their effects: they have to ask for confirmation, interrupt a task or explain a feature to a customer when they have only just discovered it themselves.
For a manager, knowing where to intervene takes listening and investigation. I use the term team problem discovery for this process: gathering signals, reconstructing incidents, comparing perspectives and deciding what to change. The intended outcome is a set of clearly understood problems, with actions that someone can actually carry out.
In my work, I have built this process through individual conversations, retrospectives and discussions across departments. Here I explain how to organize it and follow through on what emerges, including situations where the solution goes beyond the team manager’s authority.
Listen before proposing a change
When you take responsibility for a group, its members know parts of its history that you still need to learn. They know what has already been tried, where communication breaks down and which difficulties keep recurring. A proposal that looks reasonable on paper can overlook these details.
My first step was to get to know the people, let them get to know me and arrange individual meetings. At first, open conversations took more time; trust grew through our daily working relationships.
A useful starting point is to ask someone to walk you through a recent incident: a task that took more steps than expected, a decision left unresolved or information that arrived too late. The incident helps you understand what happened before deciding who should have acted differently.
“We communicate poorly” leaves room for many interpretations. “I found out about the release while showing the product to a customer” already identifies a moment, a person involved and a consequence. From there, you can ask what information was missing, when it was needed and who could have provided it.
This attention to facts also matters when someone gives feedback about a colleague. Their perspective is information to investigate: understand the context and, where necessary, hear from the other person before reaching a conclusion.
Give one-to-ones their own space
One-to-ones are individual meetings between a manager and a team member. I hold them once a month with each person, partly to maintain regular contact in a fully remote working environment.
To use them for problem discovery, leave room for whatever is making the person’s work difficult. If the list of tickets fills the whole meeting, it becomes hard to discuss unclear expectations, working relationships or decisions they are unsure they can make independently.
These questions can provide a starting point:
- In which recent task did you get stuck, and what did you need to move forward?
- Is there a decision where you are unsure whether you can act independently or need confirmation?
- Which part of our way of working wastes your time?
- Is there anything I do as your manager that makes your work harder?
Use the questions to start a conversation. Follow the answer and ask for an example, without turning the meeting into a questionnaire to complete.
Uncertainty about someone’s role is a useful example. A person may need to know which decisions are theirs, when to involve their manager and where their autonomy ends. In one such situation, I clarified responsibilities and boundaries in writing through an individual working agreement, discussed with the person and with the involvement of company leadership.
This helps determine where to address a problem. A personal difficulty may need a private conversation; a step in the workflow that blocks several people may belong in a retrospective. Before bringing information from an individual conversation to the group, agree with the person what is appropriate to share.
Prepare a retrospective that helps you understand the problems
A retrospective is a meeting where a group examines a period of work and decides what to keep or improve. For the first one I organized, I asked the team to look back over the previous six or seven months. I needed to understand a history I had only partly been involved in.
The team works remotely, but we held that meeting at our first opportunity to gather in person. We used a whiteboard and sticky notes. The same work can take place on a shared online board: the tool needs to let everyone write, read and connect contributions.
Before the meeting, it helps to communicate the period you will examine, the questions and the intended outcome. People can then arrive with incidents to discuss. For an initial broad review, I set aside roughly half a day, with this approximate allocation:
| Phase | Approximate time | Intended outcome |
|---|---|---|
| What went well | One hour | Useful practices to keep and the reasons they worked |
| What went badly | One hour | Problems described through examples and grouped by theme |
| How we can improve | Two hours | Proposals connected to problems, to consider for the action plan |
This allocation protects time for proposals. If discussing problems takes up the whole meeting, decisions get postponed or rushed. Adjust the duration to the number of people and the period being examined: four hours is the format I use for this discussion, not a requirement for every retrospective.
Start with what worked
People write down what went well and explain why. Did an early announcement prevent interruptions? Did a rule clarify who should decide? Did a technical change make the work easier?
This phase helps identify practices worth keeping. A later process change should account for what the team already finds useful; otherwise, it can remove a working solution along with the problem it aims to fix.
Understand the problems before discussing solutions
In the format I use, everyone adds their sticky notes during the second phase and explains them. As facilitator, I ask each person what they mean, which incident they have in mind and what consequences they observed.
It helps to stay with the problem long enough to understand it. When someone says “we have problems with releases,” the first proposal might be another meeting. Looking closer might reveal that the release had been announced, but people lacked an accessible environment or time to try the feature. That calls for different actions.
We then group the notes into broad themes, such as communication across departments, release management and code complexity. Grouping connects similar incidents while retaining the details that make them understandable. A column called “communication” still does not tell you where to intervene.
Everyone needs room to contribute. The facilitator should pay attention both to people who tend to speak less and to those who might dominate the discussion.
Before using a format where contributions are attributed, consider whether people feel able to speak openly. The Atlassian retrospective guide recommends clarifying how the information will be used and allows for anonymous contributions. In a small team, however, the details of an incident may reveal who reported it.
If someone fears consequences, offer a private conversation with a person they trust and agree on what to bring back to the group. If the problem involves their manager, that trusted person may need to be someone else. Avoid requiring a public explanation or promising anonymity you cannot guarantee. Silence alone does not tell you that there are no difficulties.
Ask for proposals tied to a problem
In the third phase, people add ideas for solutions, keeping them connected to the problems already gathered. We discuss the proposals one at a time.
In my first retrospective, most proposals came from the team: they knew the work and its constraints better than I did. My job was to organize the discussion and explore their contributions. Over time, I began contributing proposals too, as I gained a more direct understanding of the context.
A simple question can help assess an idea: what behavior should change if we apply it? “Improve communication” is still too broad. “Make the new feature available internally before showing it to customers” gives you something concrete to discuss: access, timing and responsibilities.
Not every proposal needs to become a rule. Some call for a technical change, others for clarification between two people, and others for an agreement across departments.
Set priorities and make follow-up visible
After the retrospective, I prepare a recap and a possible action plan. Everyone contributes to identifying the problems; as manager, I prioritize the follow-up actions and track their progress.
My assessment was qualitative, based on how much a problem could affect the company’s work. I gave priority to problems involving several departments before moving into the details of the team and individual needs. In my context, it made sense to address difficulties whose effects extended beyond development first.
To apply this criterion, make the reasoning explicit: who is affected, how often the problem occurs, what work it blocks and who needs to help resolve it. An urgent individual problem may need immediate attention; the number of departments involved cannot determine priority on its own.
The plan should also explain what is being deferred and why. Otherwise, a contribution that does not appear among the first actions may seem forgotten.
You can use a record like the one below to track follow-up. This is a suggested template for the reader, filled in with an illustrative release example:
| Field | Example entry |
|---|---|
| Observed problem | The person presenting the product discovers a new feature during a demonstration |
| Desired change | Have the people involved ready before the feature becomes publicly available |
| Proposed action | Agree on an internal trial before the next release |
| Coordinator | Development manager, together with a contact from the department presenting the product |
| Dependency to resolve | Access to the environment and time available for the trial |
| Capacity to agree on | Development and training time to reserve with the relevant managers; work to defer if necessary |
| Review point | Before the agreed public release date |
| Evidence to gather | Trial completed, questions raised and problems still open |
| Outcome and next step | At the review, record what remains unresolved and agree whether to close the action, adjust it or involve another manager |
In the actual plan, roles need to correspond to named people, and the review point needs an agreed date. If there is no time to carry out the action, that also needs a decision.
Follow-up should check both what was done and its effect on the problem. You can verify that a message was sent, but that does not tell you whether its recipient was able to prepare. For a release, you need to know whether the person had access to the feature, tried it and can present it.
Match each problem to an appropriate response
The discussion can reveal very different problems. Applying the same organizational solution to all of them can easily produce meetings and rules that leave the actual difficulty untouched.
Feature requests without a shared assessment
One example is a request that reaches the team and immediately turns into development work. Before committing people’s time, consider the need it addresses, the effort it requires and how it relates to company goals.
I introduced guidelines for new feature requests and asked for them to come through me. The team, the company’s managing director and I assess them against the direction set for the year. The team contributes its assessment of the work, and the decision brings feasibility and goals together.
This step has helped me reduce unfocused work. A request can be interesting without being a priority at that moment: shared criteria make it easier to explain why it is accepted, deferred or rejected.
If you apply this approach, make the decision visible to the person who made the request. A single entry point works when it produces an understandable assessment; otherwise, it can simply become another bottleneck.
Onboarding difficulties rooted in the code
Another problem concerned new developers joining the team. When the difficulty lies in reading and maintaining the code, the changes need to address the code itself. In our case, we started a structured refactoring effort to make it easier to understand, including for junior developers.
If an explanation is missing, documentation may help. If the code’s structure makes it hard to understand, adding only an onboarding procedure leaves part of the problem in place.
Releases that surprise the people working with customers
To give other departments time to prepare, I introduced advance communications, internal availability before public release, a test environment and feature flags. Feature flags let you control whether a feature is enabled, for example by making it available to an internal group first, as Pete Hodgson explains in Feature Toggles.
The process gives people a chance to try the feature, assess it and learn how it works before an agreed public release date. This connects a technical choice to an organizational need: the time when code is available and the time when everyone can use the feature do not have to coincide.
Address problems across departments
For retrospectives across departments, I use the same three phases. What changes is who can make decisions and which commitments need coordination.
The development manager can prepare an environment, announce a change and organize a demonstration. If another department cannot find time to prepare, that constraint needs to be discussed with whoever manages its priorities.
Alongside retrospectives, I introduced discussions with other managers and the managing director. These provide a way to raise difficulties and coordinate actions that the development team cannot complete alone.
Bring the problem to that level in a form that supports a decision. For a release, for example, explain what preparation is missing and how that affects the planned date. Options might include reserving time, reducing what needs to be prepared or changing the date. The people responsible for the work involved need to agree on the choice.
Completing your part of a procedure still leaves the problem open if the outcome depends on several departments. Follow-up needs to make that dependency visible.
Any resulting rules should also be discussed before becoming official. My process is to gather information, prepare a draft, reread it and discuss it with the people involved. Feedback helps resolve ambiguity and check that the expected behavior is clear. That involvement is part of the work needed to make a policy usable.
Surface problems between retrospectives too
A retrospective provides space to examine a period of work as a whole. In day-to-day work, however, I do not want someone to wait months before raising something that is blocking them.
Alongside monthly one-to-ones, I introduced two short team check-ins each week. Retrospectives remain quarterly. Every three months, the whole company also meets to share results, difficulties and direction: I proposed that meeting, while the managing director runs it.
These meetings serve different purposes. Check-ins help catch problems as work progresses; individual conversations give people room to discuss their needs; retrospectives help identify recurring issues and discuss them together. Sharing the company’s direction provides context for understanding priorities.
Over time, I have seen people become more direct and comfortable raising difficulties. Many problems are addressed before the retrospective. I consider that a useful change: discussion becomes part of everyday work, and the quarterly meeting can also focus on problems that need a broader view.
To start applying this approach, choose one problem raised by the team and follow it through to the agreed review. Return to the original incident, check what has changed and listen again to the people affected. If the action was completed but the difficulty remains, revisit the part of the problem you have not yet addressed.
Books that informed my approach
Books that have given me ideas about management and people’s development include An Elegant Puzzle by Will Larson and The Manager’s Path by Camille Fournier. To explore one-to-ones and feedback further, the table of contents of The Manager’s Path points to these topics in the chapters on management fundamentals and managing people. The meeting cadence and retrospective format described here are choices I made for my own context.