How to build an amazing project team

There are teams you work on, and then there are teams that leave a mark, the kind you carry with you long after the last meeting ends.

In early 2025, the project I was on came to an end. 

Our CDC client had nothing but positive things to say about our team and the work we had done. We had genuinely enjoyed the work, and we all felt that what we had built together as a team was something special. Our project team was kind of like capturing lightning in a bottle.

It got me thinking: was our team just the right people together at the right time? Or was it more than that? I decided to have conversations with a number of my former teammates to see if there were any common threads in what made the team so great to be a part of. Many things came out of those conversations. 

Months later, I had the opportunity to discuss similar themes with some engineering leaders from outside Flexion, and many of the same points came up in those discussions.

Why does this matter?

Everyone dreams of being part of an amazing project team; however, it is seldom experienced. Why doesn’t this happen more often? Is there some set of specific circumstances that allows it to occur? What gets in the way?

No matter what industry you work in, everyone wants to be part of a team where they feel good about the work they do and feel good working with their teammates. No one wants to feel like their work doesn’t matter, or dread going to work each day because the work atmosphere is awful. Everyone deserves a positive experience.

The outcome of all of those conversations has informed much of this article, where we’ll look at the things that contributed to our amazing team experience, and that can contribute to yours. 

At Flexion, we experiment within our project teams to figure out what works and what doesn’t, knowing that happy team members produce higher-quality work and better solutions. None of these items is specific to the tech industry, and there’s nothing here about coding or IT systems; that’s deliberate. These ideas go beyond daily tasks and apply to any team in any industry. Let’s take a closer look.

Team building foundations

While talking with my former teammates, the theme of having core foundational values and expectations stood out as important. These values create the base from which all other team dynamics grow, naturally leading to how roles and expectations shape daily collaboration.

Establishing shared working values

Building a team is tough. Building a high-performing team, even more so. Rarely can we specifically choose the members of a development team in order to assure a good outcome. A team is most often put together out of people who are currently available or newly hired. At Flexion, we try to set ourselves up for success by hiring people who are a strong cultural and collaborative fit, which means a working agreement has a better chance of becoming a genuine way of working rather than a list of rules people pay lip service to.

However, throwing a bunch of people together can still be a recipe for disaster. We can set the stage for success early on by creating a set of shared core working values. This is also known as a team working agreement. One of the first essential things a team does together is to create this agreement. It gives the team a solid core of rules to start from.

Team working agreements can contain anything the team wants. In our case, the agreement covered both practical logistics and team culture. On the practical side: no team-wide meetings before 11:30 am ET to respect those on the West Coast, and questions discussed openly in team channels rather than direct messages so everyone could benefit from the answers. 

On the cultural side: a goal of spending 50–75% of our time collaborating, a reminder to use PTO because work/life balance matters, and an explicit statement that psychological safety is paramount. As long as everyone agrees to abide by the items outlined in the working agreement, all is good.

What happens if team members don’t adhere to these agreed-upon items? That’s entirely up to the team itself. The beauty of a team working agreement is that all team members need to uphold and enforce the agreement. It simply will not work if the team is not willing to do this. Enforcement can be tricky, and the items in the ‘Interpersonal relationships’ section help to achieve this.

Defining shared role expectations

Software engineering teams are constantly asked to do more and more with fewer people. To counteract this, and to create well-rounded teams, we find that teams with generalists can help tremendously. Instead of each team member having a specialty role, each member takes a share of multiple traditional roles. How does a team member understand what is expected of them with this type of team organization?

One thing that helps is to develop a set of role expectations specific to the team. These are not the same as company-wide job descriptions, which define roles in general terms. Team role expectations, by contrast, are developed collaboratively and reflect how this particular team works together. 

Our engineering expectations, for example, covered five areas of expertise and defined what was expected at Junior, Staff, and Senior levels. Engineers weren’t just expected to know the core application code. They were also expected to understand the cloud infrastructure, the CI/CD pipeline, and how our work fit into the broader ecosystem. Each engineer was expected to meet the bar for the level they were hired at, giving everyone a clear, shared understanding of what was expected of them from day one.

These expectations serve two purposes: they help new team members understand what they’re stepping into, and they give existing members a clear picture of what growth looks like. 

No team member should be surprised as to what is expected of them during the course of the project. An existing team member will always be able to understand where they measure up to the expectations. A prospective team member can understand ahead of time what they are getting into.

Interpersonal relationships

An amazing project team communicates well with each other. My former teammates all pointed to psychological safety, giving and receiving feedback, and having fun together as what really cemented our working relationships.

Building psychological safety, trust, and transparency

One of the most important things for any team is that everyone is able to trust and be transparent with each other. Psychological safety is crucial. If team members don’t feel psychologically safe, they won’t take chances, won’t experiment, and may not create as high-quality a product as they could have otherwise.

Psychological safety doesn’t happen just because someone declares it important. It has to be modeled. 

Scott Fradkin

Senior Delivery Manager, Flexion

On our team, the people in leadership roles understood this. They showed humility, admitted when they didn’t have answers, and were openly vulnerable. When people see this modeled by their leaders, it gives everyone else permission to do the same. Our working agreement even included an explicit commitment to assume positive intent in all interactions. It sounds like a small thing, but it proved powerful in practice.

When a team first gets together, it is very important to set the expectation right away that psychological safety is paramount to the team’s functioning. 

The goal is for everyone on the team to trust one another implicitly and – 

1. Trust that the work will get done 
2. That all team members give 100% effort; 
3. All team members are treated appropriately and fairly. 
4. Everyone on the team can speak up about anything. 
5. Team members know that it’s acceptable to praise each other, and they can give each other constructive feedback. 
6. Decisions can be questioned. 
7. Team members can have disagreements, but still respect each other’s positions and opinions. 
8. Positive conflict is a good thing to have.

This is some of the toughest work for a team to take on. But it’s very important. Without psychological safety, it is tough to implement any of the items later on in this article.

Developing a feedback culture and open communication

A high level of psychological safety doesn’t just appear out of the blue. A team must work to attain it. To get to that point, a team must practice communication. 

Team members need to talk to each other. In particular, team members must regularly give each other feedback. 

It can be tough to give feedback to someone that you enjoy working with on a daily basis. Teams can practice giving feedback by frequently giving positive feedback. Everyone likes to hear about the good things they are doing. 

This helps with the tougher task of providing critical feedback. Even though it is harder to provide, it’s necessary to give a team member critical feedback to fuel personal improvement. Everyone strives to improve themselves, and this is one mechanism to ensure this happens.

We made feedback a structured part of how we worked. Every retrospective ended with a few minutes set aside for teammates to give each other positive feedback. 

Each quarter, we gave each other direct feedback, drawing on personal user manuals we each maintained to describe our working styles and preferences. We also made a point to recognize each other publicly in shared channels, a simple habit that went a long way toward building trust.

All these practices increase the psychological safety within the team and make it more amazing.

Fostering camaraderie, fun, and a welcoming culture

Everything we have discussed to this point has centered around interpersonal relationships and working together. Having fun together is a natural extension of that. 

Building on a foundation of open communication, we also learned to encourage each other to go easy on ourselves sometimes. We worked hard together, but we also needed an outlet from time to time to avoid drudgery and potential burnout. 

Keeping a positive attitude can be tough at times. We built regular breaks into our work: a weekly social hour, virtual coffees, and the occasional game session. 

We also leaned on a virtual office tool, Gather, which gave us a shared environment to work in together. Being able to casually pop into a teammate’s virtual space, or meet up in a shared room, replicated the kind of spontaneous interactions that remote teams often miss. Tools like Gather can make a real difference in how connected a distributed team feels day to day.

Even more important is to set a good example right from the start that the team is welcoming to everyone. We were deliberate about this: every new teammate was properly introduced to the group, and we even kept the door open for former teammates to join our social events.

Over the course of a project, the team will have members leave, and new members join. Joining a team in the middle of a project is a tough prospect at the best of times. But when the team is welcoming and takes regular breaks to have fun, the transition is smoother and working together becomes more enjoyable.

How a team works is also extremely important. The processes a team uses can make or break a project, and heavily factor into whether or not team members feel the team is great.

Remote team operations

Some other important themes that came up in my conversations with former teammates encompass autonomy and how important it is for a team to be trusted to solve their own problems and determine for themselves how they work best.

Using effective collaboration tools

Consistent communication remains one of the most effective strategies for managing remote teams as well as on-site teams. When a team is co-located, team members can more easily riff off of each other because they can see each other. The subtleties of body language and non-verbal cues are missing for a team that is remote. To counteract this, good collaboration tools are necessary.

Ideally, team members will work in small ensembles of three to five people. That is a good size to ensure everyone can contribute while maintaining the kind of closeness needed to produce high-quality work. As our working agreement reflected, we kept cameras on whenever possible to preserve the non-verbal cues that matter so much when working remotely.

The right combination of tools makes all of this possible: videoconferencing, tools that enable collaborative control of coding environments, collaborative diagramming, and virtual office environments like Gather that give a distributed team a shared space to work in together. It may take some time for a team to find the right mix, but the effort to experiment and find what works is well worth it.

Owning work (autonomy, self-organization)

Hierarchical team organization is common. The problem with a hierarchical arrangement is that the team members at the bottom of that hierarchy are typically the ones doing the bulk of the implementation work for whatever the team is working on.

They may rely on the individuals higher in the hierarchy to develop the guidelines for what needs to be done, and then they work on what they are told. This may work fine, and those at the bottom of the hierarchy will get the work done well. But perhaps there’s a better way to approach this.

Instead of a team being a hierarchy of people, the team acts as a flat organization in which each person has their own set of accountabilities. These accountabilities may be role-based, but they don’t need to be. Everyone on the team is equal to each other, yet in practice, leadership naturally emerges. When someone demonstrates deep expertise or clarity in a given area, others gravitate toward them. Direction isn’t imposed from above; it’s earned through trust and capability.

On our teams, the expectation is that everyone on the team takes ownership of the work they are doing and self-organizes in order to complete the work. It’s worth distinguishing here between accountability and responsibility: accountability means being answerable for an outcome, while responsibility means doing the actual work to achieve it. One of the team members will typically be accountable for delivery, but the entire team is responsible for the work and for determining how to get there.

On our team, this wasn’t just a philosophy. It was baked into how we operated. Our working agreement committed us to making decisions bottom-up, not top-down. Teammates were empowered to pick up work, pivot, champion new ideas, and even lead retrospectives, not because they were assigned to, but because the team trusted everyone to take initiative. It is a very positive thing to watch a team take a common starting point and turn it into their own mechanism to do the work.

Autonomy is also a huge piece of the puzzle. Each team deserves the autonomy to make the decisions it needs to make without unnecessary interference. The freedom to experiment, adjust processes, and choose how problems are solved is a major part of what makes the work energizing. Autonomy isn’t just permission. It is trust.

Slicing work small

Much of the success of any team comes in the process of doing the work. Teams use different processes, from waterfall to some of the more extreme versions of agile. Agile practices advocate for learning as you go over up-front planning.

Developing user stories that are very small and, in particular, using the concept of vertical slicing (small slices of functionality in an app from front end to back end) is one way to increase success on a project. With small vertical slices of functionality, the team quickly implements functionality and deploys changes in quicker cycles. This allows the client to provide feedback much more quickly. Being able to do this increases trust between a team and a client. It can also make the work more interesting. Large chunks of work that take a long time to implement can drag on a team. Smaller chunks of work keep things fresh and flowing. At Flexion, vertical slicing is a practice we use across all of our engineering teams, and our CDC team was no exception. It was a core part of how we approached building software and delivering value to our clients.

Team management

Being empowered to make their own decisions and not being micromanaged also moves a team closer to amazing. These items came up in conversations with my former teammates as an extension of discussing autonomy and trust.

Empowering team leadership

The importance of establishing a tone of empowerment rather than control cannot be overstated. In the section about autonomy, we looked at how limiting hierarchy in a team can be helpful. However, there are still some roles that are thought of as team “leadership”.

These tend to be the product type roles on a team: delivery manager, product manager/owner, scrum master. In reality, the individuals in these roles are equal to everyone else on the team. Clients consider people in those roles as leaders on a team, even though from an internal perspective, they function more as liaisons between the team and client stakeholders.

It’s critical for people in those roles to empower their teammates rather than manage them. A delivery manager, for instance, is not a people manager. Their job is to ensure the delivery of a product. It’s a role critical to the team’s success, like any other. On our team, this played out in tangible ways: our delivery manager ran interference with the client so we could stay focused on the work, and when pressure came to compromise quality for speed, the delivery manager pushed back. It is common, however, to need to actively remind teammates that they have the autonomy to make decisions, and that’s a worthwhile thing to do.

Team members should be encouraged to take risks, make autonomous decisions, and freely experiment. Everyone should model the positive behaviors of honesty and transparency. No one wants to be micromanaged, and there should be no need for micromanagement.

Engaging with clients (minimal micromanagement)

Trust between a client and a team is extremely important and increases the probability of success. A project team wants its client to fully trust it to make decisions. A project can be a success even with limited client engagement and collaboration. However, it’s much easier to have a client who is highly engaged from the start. When your client isn’t highly engaged, it’s important to constantly work on the relationship.

We worked hard to build and maintain that trust with our client. One thing we were deliberate about was keeping our retrospectives a team-only space, with no client present. This protected the psychological safety of those sessions and gave the team room to be honest about what was and wasn’t working. Our client trusted us to make decisions and stayed engaged without micromanaging, and the relationship was stronger for it.

Work to involve your client in what the team is doing. Be honest and transparent with your client. The goal is for your client to be able to make decisions and trust the team so that micromanagement isn’t needed. A team that works together, owns their work together, and makes decisions on how to work together without client micromanagement will develop amazing solutions.

Team luck

The wildcard that sits behind everything is “luck.” We can’t control it, and we don’t look for it. But it’s there. When I look back at our team, there was certainly an element of luck. We happened to get the right mix of people at the right time, and not all of the conditions that allowed us to flourish were entirely of our own making. Sometimes it feels like all the pieces fall into place and everything works perfectly. Other times, it seems like everything that can go wrong does go wrong. Luck is real, tangible, though invisible. Can a team make its own luck? Yes! It can consistently create the conditions where good outcomes are more likely and where unexpected opportunities don’t go to waste.

At Flexion, we try to position ourselves to recognize it, respond to it, and make the most of it when it appears.

Conclusion

There are many things that contribute to an amazing project team. It might not be necessary to do all of these things to have that amazing project team; however, if you read through the list again, implementing many or most of the items will have a lasting, positive effect on your team. Most of the items are just plain common sense and will feel like the right thing to do.

Executing them, however, can be challenging. It takes time, intention, and a willingness to experiment. Amazing teams may seem rare, but they don’t have to be. Don’t we owe it to our teammates to make things amazing?

And if building one feels overwhelming, Flexion can help. Through our strategic advisory practice, we partner with organizations to create the structures, habits, and environments that unlock true high performance. If you’re ready to build a team that thrives, we’re here to support you every step of the way.