An essay by Peter Johann · October 2026
How to Work
in a Team
Bring your experience. Listen carefully. Question constructively. Follow through on what we decide together.
My perspective on contributing to a team: combining independent thinking with respect, clear responsibilities, and dependable work.
A useful question is: “What am I missing?”
Start with a shared purpose
A team begins with an understanding of what we want to accomplish together. Putting people in the same room or on the same organization chart does not create that understanding.
What result are we responsible for? Who depends on it? How will we know that the work is complete and useful? These questions deserve clear answers before everyone becomes busy with individual tasks.
For me, good teamwork means making my contribution useful to the people around me. My part is complete when it meets the agreed requirements and the next person can build on it.
Understand before proposing a solution
Technical experience helps us recognize familiar problems. It can also tempt us to decide too quickly that we already know the answer.
I want to understand what the people closest to the work are seeing. An operator may know when a machine behaves differently. A maintenance technician may recognize a recurring weakness. A colleague in purchasing may understand why the replacement part never arrives when it is needed.
Listening means more than waiting for my turn to speak. It means asking questions, checking that I understood the answer, and allowing new information to change my view. A useful question is: “What am I missing?”
Bring expertise without making it a contest
A team benefits from people who know different things. Nobody needs to be the expert on every subject.
My responsibility is to make my knowledge available in a way others can use. That may mean explaining a technical constraint, documenting a procedure, or helping a colleague evaluate an option. It also means recognizing when someone else has the better answer.
Independent thinking belongs in a team. So does the willingness to revise an idea. I would rather help the group reach a sound decision than defend a proposal simply because it was mine.
Disagree with care and substance
Agreement is comfortable, but sometimes a concern needs to be raised. A design may have an overlooked weakness. A schedule may depend on resources that are unavailable. Silence would leave the team exposed to a problem it could still prevent.
The way we raise that concern matters. Describe the issue, explain the evidence, and make the consequence clear. If possible, bring an alternative. “I am concerned that this delivery date leaves no time for testing; can we move the installation or arrange testing earlier?” gives the team something to work with.
I want colleagues to question my proposals in the same way. A disagreement should help us examine the work while preserving respect for the people involved.
When a conversation becomes personal, it helps to return to the shared result: what are we trying to achieve, and what information would help us decide?
Support the decision and follow through
Discussion needs a path to a decision. The team should know who decides, who needs to contribute, and when an issue must be resolved.
Once a decision has been made, I believe in helping carry it out—even when my preferred approach was different. Reopening the same debate at every step makes it difficult for anyone to deliver.
That commitment does not mean ignoring new evidence. If circumstances change or a serious concern remains unresolved, bring it back promptly through the appropriate channel. Explain what is different and why it matters. Safety concerns and misconduct need a clear route for escalation.
Reliable support means both doing the agreed work and keeping the team informed when the basis for the decision changes.
Make responsibilities and handoffs clear
Many problems occur between tasks. One person believes the work has been handed over; the next does not know that it is ready, lacks important information, or assumes someone else is responsible.
A useful handoff identifies the deliverable, its status, the receiving person, and any outstanding questions. For technical work, it may also include drawings, settings, test results, or operating instructions.
Clear ownership makes cooperation easier. It tells people where they can act independently and where coordination is needed. When responsibility is unclear, clarify it early rather than waiting for a missed deadline to expose the gap.
Be dependable—and honest about capacity
A team needs to know that commitments mean something. If I agree to deliver a result, others may arrange their work around it.
Being dependable includes speaking up early when a commitment is at risk. A late part, an unexpected failure, or competing priorities may require a different plan. The team has more choices when it learns about the problem while there is still time to respond.
Offering help also matters. Sometimes a colleague needs another pair of hands; sometimes they need a short explanation or someone to check an assumption. Ask what would help, and coordinate changes so that assistance does not create confusion over ownership.
Teamwork should not depend on the same people quietly absorbing every overload. Persistent overload is a problem for the team to address openly.
Make it possible to report a mistake
Mistakes need attention, and people need to be able to report them honestly. If every unwelcome result leads immediately to blame, the team may learn to hide the information it most needs.
My first questions would be: what happened, what is the immediate consequence, and what do we need to do now? After containing the problem, examine how it occurred and what should change.
Accountability includes correcting the work and learning from it. It also requires distinguishing an ordinary error from deliberate concealment or repeated disregard of an agreed procedure. Treating every situation identically is neither fair nor useful.
The goal is an environment where people can ask for help early and expect a serious, constructive response.
Share the knowledge and the credit
A successful project usually contains contributions that are easy to overlook. Someone prepared the information, noticed an error, arranged a delivery, maintained the equipment, or kept daily operations running while the project advanced.
Recognizing those contributions helps people understand how the result was achieved. It also makes recognition more credible.
Knowledge should move through the team. Explain what you learned, leave useful records, and help someone else become capable of doing the work. An operation becomes stronger when understanding is shared and people can support one another.
Keep improving how we work together
At the end of a project—or at a useful point during longer work—the team should take time to examine its own process. What helped? Where did information arrive too late? Which decision waited unnecessarily? What should we do differently next time?
Choose a few practical improvements and give them owners. A review becomes valuable when the next piece of work benefits from it.
The same curiosity that helps me understand a technical system belongs in teamwork: observe carefully, ask questions, test assumptions, and pay attention to consequences.
I want to bring experience and independent thought to a team, while remaining someone others can work with, question, and depend on. The result we build together is the measure that matters to me.
© Peter Johann 2026. All rights reserved.