Share failures. Earn real trust.

Remote team leadership is about building trust and visibility when physical proximity is no longer available. Without the informal contact of shared office space, team leaders serve as the bridge between their team and management, actively communicating both achievements and failures. Transparency, regular one-on-one time, and written updates replace hallway conversations and keep distributed teams connected.

Key Takeaways

• Hybrid work is still remote work: when team members visit the office on different days, the same remote leadership practices apply without exception.
• A team leader’s primary job in remote settings is making the team’s work visible to management, because the informal kitchen-conversation no longer exists to carry that signal upward.
• Communicating failures transparently, without blame, is more effective than reporting successes alone, because it opens the door for management to offer resources and unblock stalled initiatives.
• Technical people hold a critical advantage over management when evaluating AI tools, because they can distinguish a genuine capability from a paid wrapper around a public model API.
• Encouraging team members to experiment with AI positions them as people who are enhanced by the technology, which is a stronger defense against role reduction than avoiding the topic.

Hybrid is still remote

When team members alternate between office days, the work stays remote. Michał Buczko makes this point against the common belief that returning to a hybrid model solves the problems of distributed work. If one person sits at home while another is in the office, you still lead across distance, and the same practices apply.

The shift came abruptly for many leaders. In Poland, remote work barely existed before the COVID pandemic. Managers were moved to remote setups overnight and told to figure it out. The methods that worked in the office did not transfer on their own.

Michał names “managing by walking” as the practice that broke. In UK-based companies he had learned to visit team members at their desks, look at their monitors, and start a conversation from what he saw there. Remote work removes that. The casual proximity that built familiarity is gone, and you have to rebuild it deliberately.

Why trust is harder to build at a distance

Trust does not form on its own when you cannot sit next to someone. That is the central challenge of leading remote teams, and it runs in both directions: the leader needs the team’s trust, and the management above needs to trust the leader.

The calendar makes the problem worse. In the office, meetings were limited by room availability and working hours. Remotely, any free slot in a calendar becomes an invitation to book a meeting. A leader who spends thirty-six hours a week in meetings has no time left for the team. The team accumulates dozens of topics and never finds a moment to raise them.

To counter this, Michał reserves meeting slots in his calendar that belong to individual team members. He arrives and asks one question: how can I help you? The team member sets the agenda. They can cancel the meeting, talk about something unrelated to work, or raise a side experiment they want advice on. The structure keeps the channel open rather than filling it with the leader’s own topics.

Trust is what makes career honesty possible

A team member who trusts you will tell you when they want to leave their role. Without that trust, they simply leave. Michał frames career conversations as a direct payoff of the relationship he builds in those one-to-one slots.

If someone says they are thinking about switching paths, he can act on it. Inside the company, he can connect them with a mentor. In parallel, he can reach out to leadership: this person is considering a change, is there an opportunity on our side? If there is, the move can happen internally. If there is not, at least the risk of losing the person is visible early.

The alternative is silence followed by a resignation. “I’m switching to a scrum master next year, and I don’t care if there will still be scrum masters in our company.” That is what you hear when trust was never there, and by then it is too late to respond.

How a remote leader makes the team’s work visible

The team leader is the bridge between the management and the team, and in remote work that bridge is the only path to visibility. Michał builds his entire case for advocacy on this point.

In the office, recognition happened by accident. You met your boss or higher management at the coffee table and mentioned what you had done. Remote work removes the kitchen conversation. Nobody upstairs sees the work unless someone surfaces it on purpose.

His mechanism is a half-yearly email to management listing what the team achieved. He does not expect every leader to read it. The value shows up later: when someone notices a result and assumes a different team produced it, the email proves who actually did the work.

He gives a concrete case. One component reduced its open defects by 80 percent. Management credited the component owner for changing priorities. In fact, a quality manager on Michał’s team had asked the component teams to focus more on maintenance and convinced the owner to shift priority away from features. The improvement came from the outside, not from the component owner’s own initiative. The email named Mateusz from his team, and three or four people in leadership recognized that a different team had driven the outcome.

Why email beats chat for management communication

Email works for advocacy because it is asynchronous and it persists. Michał chooses it deliberately over a messaging tool like Slack.

A Slack message creates pressure. The recipient feels they have to respond, and the message cannot wait a month. An email carries no such weight, so it can sit until management has time. When a thank-you arrives half a year later, that reply is proof the person read it, and the leader can take that proof back to the team. A Slack message gives no such confirmation.

There is also the practical hurdle of reaching managers where they are. Not every manager is on the chat tool. Email remains the common ground.

Make failures visible, not just wins

Transparent communication means reporting what failed alongside what succeeded. Michał does not limit his updates to achievements. He states plainly: we tried this, and we failed.

He does not lead with reasons or blame. If someone asks why, the discussion can follow. The point is that management sees the work, not only the results. Effort spent on an attempt that did not land still counts as evidence of what the team took on during the period.

Naming a failure can also unlock help. An initiative that stalled may draw interest from management, and that interest can come with resources.

His own example: a manager tasked him with reviewing the software development process of the R&D department, but the department never produced the process. For up to three years it was postponed. When he reported that he had repeatedly asked when the process would be available and received no clear answer, a department leader offered a way forward: build workgroups to design the process if Michał would coordinate them. He now coordinates five workgroups across a different department, and the work is around 90 percent finished. Had he hidden the two-year stall as a personal failure, nobody would have given it priority or freed up the teams.

The discipline that makes this work is the absence of blame. State that an element failed without saying it was because of them or because of me. Transparent, not accusatory. Then anyone who can help will step in, and the attempt can be retried in the next half year.

Where AI fits into remote and hybrid work

AI tools belong to the same category of remote collaboration tools, and they raise the same coordination questions. Michał treats AI as a remote instrument, sometimes shared by multiple team members who add to a single prompt and have to coordinate their work across distance.

His own company restricts AI use heavily. Running on a Google office stack, the team is approved to use Gemini, mostly tied to documents. Alongside that, Michał and two team members run side experiments on private machines, testing different models to learn what is and is not possible.

One experiment builds a mobile application end to end with AI: development, testing, and project management all handled by AI agents. The infrastructure runs around twenty agent personas, each with its own scope of responsibility. He plans to present the full setup and results at Testing United in Milan.

The pace of change shapes the experiment itself. The call for papers for that conference went out about half a year before the event, and he has already written seven versions of his presentation. A new model is expected at the end of October, the conference is around mid-November, and a large enough new model would push him to start the presentation from scratch with different results.

How to trust AI output without reading every line

Trusting AI at the level Michał describes took months to reach, and he built it through prototypes rather than line-by-line review. He gives the model full trust within a defined loop.

The loop runs like this:

• Ask the AI to design a prototype, then implement it. He does not read or review the code.
• Test the prototype as a human user.
• If the prototype works, ask the AI to take it to production level.
• If it does not, tell the agents to build a new prototype, not produce an instruction document, and repeat until a working version exists.
• Once satisfied, ask the AI to document the prototype he approved.

The speed is real. Sitting in the speakers’ room at the conference, he asked a model to solve a single blocker from his project. It returned a hundred-page instruction set in two minutes, targeted at his agent infrastructure, with an estimated delivery time of four hours.

Testers as the critical filter on AI tools

The job of technical people in the AI shift is to enhance their own work and to judge tools critically, not to defend their roles against automation. Michał draws a sharp line between the optimism of management and the scrutiny engineers can apply.

He wants every tester or developer to carry AI like a tool on their belt. The framing matters: AI that enhances the person, not AI that replaces the person. The value to promote is the work you create and have AI implement, with you reviewing the outcome.

Critical judgment is where technical people earn their keep. Michał reviewed AI test automation tools and found, behind a polished UI, a direct API call to a model. The same output can be produced by prompting the model directly, without paying half a million for the wrapper. Management often lacks the critical lens to see this. Engineers can tell whether a tool replaces real work or just dresses up a model call.

The risk is concrete. He points to a case where OpenAI announced a change that closed off direct API access used by startups as a microservice, with the company stating openly that the move would end a large number of startups but was needed to make OpenAI profitable. A tool bought for half a million can become useless when the underlying API closes. The only defense is to have technical people examine the tool before purchase, rather than acting on a sales pitch.

If I’m saying don’t buy this test automation tool, it’s not like I’m defending myself to keep the job. I’m feeling like this tool is not a solution for us. And that’s the trust that we need to have from the management. Michał Buczko

This closes the loop back to trust. When a leader advises against a tool, management has to trust that the judgment is technical, not self-protective. Without that trust, organizations adopt tools their own engineers warned against, and that is a recipe for disaster.