building a development team

Hi, I’m Ben. I’ve been in software since 2004, but only recently have I begun transforming software development teams. I want to tell you all about it—from objectives to implementation—but first, I’ll give you a brief history of my experience with sports teams, which I leaned on when developing my team-building approach.

A brief history

Long before I started working with software development teams, I was part of several basketball teams. I’ve loved the game of basketball from an early age and began playing as soon as I grew strong enough to dribble a ball. In the time leading up to my sophomore year in college, when I played my last meaningful game, I spent countless hours in the gym trying to improve. It consumed most of my summers and free time in general. I always wanted to be the best player on the court and I didn’t really think about what else I could’ve done with my time until I was done playing. When I did quit, I remember this feeling of loss, like I invested so much time and energy into a thing that really didn’t add much value to my life. I was now a father with two years left of college and no real idea how to get started in the career I had chosen, solely based on my dad’s opinion that I should “do something with computers.”  I didn’t have a better plan, so there I was.

It wasn’t until I started coaching software development teams that I began to understand the lessons I learned playing basketball. It turns out that, because both sports teams and software development teams are made up of people, a winning team in either arena requires similar qualities: mastery of craft, great communication, and ownership of your work or your role.

On a recent project, I was given the opportunity to play the role of coach to a team of our client’s developers. The goal was to create a fully autonomous team, capable of supporting and developing new features in the client’s line of business applications. Focused on developing the leader within, we began changing the way we approach our work, addressing misconceptions about the environment we work in, and proactively communicating with stakeholders. Once expectations were clearly communicated, this team of leaders began to work and collaborate in a whole new way: We were frustrated less. We were right more. We weren’t afraid to fail. It felt like we were doing our best work. It felt like winning. Here’s the story of how we got there, along with some principles that could guide your own team transformation.

Getting to know your team

When joining a new team, especially in a position of leadership, it will serve you well to come in with a learner’s mindset. Ask a lot of questions. Don’t assume the team even understands why you’re there. They may not have any indication of the value you intend to bring. In order to earn the respect and trust you need to influence change, you first and foremost need to listen and engage. They need to know they’ve been heard. They need to understand your intentions and believe you have their best interest at heart.

Engaging as a coach with the client’s development team, I learned that as developers, they each were required to wear several hats, from working with end-users to identifying product needs to developing features to QA testing, and support. Management needed to know that the work would be done correctly and that stakeholders would be made aware of any issues, risks, or product changes. They needed each developer to truly own their work and take the lead on communication, so they wouldn’t really need to be managed at all.

I began meeting with each developer individually, working with them on features, noting where we could see the biggest impact. I met with them to understand their own personal development goals as well as goals within the organization. To find out why they got into software development and what motivates them to keep coming to work and giving their best effort. I asked questions like, “What is your role and what are the expectations in your role?” And then challenged any assumptions I identified. It probably felt to them like being asked “why” over and over again by a young child. But I’m hilarious, so there was at least some comedic relief.

After meeting with both management and developers, I had enough to identify values shared by the organization. This helped us to develop a vision that enables both the company and the individuals to accomplish their goals.

Communicating vision and expectations

Creating a vision, together, that aligns to shared values and each person’s individual goals will create the buy-in needed to keep everyone motivated. Hopefully, your shared values include personal growth, team growth, and helping others to achieve their goals. Focusing on people and the team instead of outcomes will change the conversations we have and produce better results—results you didn’t have to crack the whip to get, but instead are achieved by a team of highly motivated individuals who owned their work.

On our team, we talked about the type of developers we needed to become and identified gaps in knowledge or expertise that would keep us from getting there. We talked about the company’s future and the opportunities available to them, as well as the importance of the team’s role in the company’s success. I talked about these things one-on-one with team members too, helping them to figure out how they could accomplish personal goals while executing on the shared vision. From there, we worked to further define what was expected of us in our newly envisioned roles.

We all have expectations, whether spoken or unspoken. Since we valued transparency as a team, we began the work to communicate our expectations of each other and of roles and to document processes that were only loosely defined…or missing altogether. Asking “why” became a daily practice. Give an ambiguous answer, and expect to hear the question again. No manager or coach was safe from the “why” game, and for good reason.

As it turns out, we all like playing games we’re good at, games we can win. I’m sure we’ve all seen a blow-out game where one team is still on the court or field playing just because there’s time left on the clock. It becomes obvious they’ve lost all hope of winning and as a result, their motivation is lost. The frustration can be seen and even felt by the audience.

Development teams can experience similar feelings of discouragement in environments that are created by ever-changing or hidden expectations. Weekly syncs are a time to remind each developer of their important role in achieving team wins, to recognize their individual efforts and align expectations. When performance review time comes around, there shouldn’t be any question whether they’re up for a promotion or if they’re meeting expectations. As leaders within an organization, if we want transparency and proactive communication from our development teams (and we do, it’s a must-have for autonomy to work), then we need to lead by example.

Executing on the vision

Executing is the hardest part. This is where most team transformations fall short. Why? Because it requires you to commit to or to embody all your shared values. If we take shortcuts to avoid doing the hard things, we miss opportunities for growth and allow a spirit of complacency to creep into our teams. It’s like, you need to decide now: Do you want to be excellent? Or do you want to be comfortable?

Committing to excellence means we’re committing to doing the hard thing, the right thing, the thing that will make us collectively stronger, better, faster. Think grit. Few enjoy pain for the sake of pain, or working unpaid extra hours to complete a feature on time. However, when we collectively commit to excellence in pursuit of a shared vision, our motivations change. Working a little later into the night to wrap up a feature feels more like victory than loss. Staying late to help a colleague finish their work feels like you’re helping yourself as well, especially when the team and management recognize your extra effort. On our team, these things began to happen naturally, without a single ask from myself or management.

Enlisting a mentor or coach is the fastest way to achieve sustainable change. We see this time and again across all facets of life. When you have to figure it out on your own, you’re relearning the lessons your coach could have kept you from. During the coaching process, we did use some pre-existing tools: we leveraged supplemental training content to establish a foundational understanding of certain technology, and adopted certain development principles designed to help any team succeed. However, the majority of our time was spent in hands-on, individual and team training. We would focus on whatever issues we were facing in our current work. We adopted some new practices, like adding implementation details to our tickets to ensure understanding of the feature. We added to our team agreements as we learned better ways to work together, like asking for help in group conversation rather than going to our favorite rescuer.

In addition to ad-hoc meetings and bi-weekly, full-team meetings, I would sync weekly with each individual developer and management. In the developer syncs, we would discuss their work, their goals, their wins, and learning opportunities for the week. We would address any issues that arose, owning our parts in them and learning to lead the conversation towards resolution and finding ways to improve moving forward. This was our time to follow up on any commitments we made in our last meeting. When we missed a commitment, the focus of our discussion wasn’t shaming or blaming, but identifying why and then discussing ways to improve outcomes next time. There was never an expectation or goal without a clear plan to achieve it, which made winning more attainable.

We learned to own our work, to take the lead in clarifying any ambiguous requirements and to communicate our understanding of expectations and any issues as they arose. We started considering other developers, code reviewers, and product owners, making sure our work was broken down into simple steps and our notes included enough detail to lead them into the pit of success. From clarifying requirements to saying thank you, we looked for ways to lead conversations and reduce back-and-forth, or the need for a lengthy meeting. Here are some examples of how we started reframing our communications:

“What happens if the user hits the checkout button?” “The way I understand this is: when the user hits the checkout button we want to take them to the checkout page and display all the items in their cart with a grand total before prompting for payment. @productowner, please validate.”
“Thanks for finishing the checkout feature!” “Thanks for thinking through the feature completely and clarifying what we wanted to happen when the checkout button was pressed. You saved us a lot of potential back and forth discussion with the product owner and made it clear what I needed to validate before approving the pull request. I’m sure the testers appreciate this clarification too. Great job!”

In my weekly sync with management, the focus was on alignment in approach, direction, and messaging. We’d collaborate on ways to encourage and support the dev team as it continued to grow. We’d talk about expectations and how to further clarify or simplify them. We’d identify potential and areas of interest that we could use to challenge further growth in the coming weeks. To keep motivation high—to sustain that feeling of winning—we were intentional about recognizing individual growth and effort as well as any wins that we could celebrate with the team. It’s crucial that your messaging stays consistent and that devs are allowed to fail safely.

Celebrating successes and failures

Most people are afraid of failure. Rightfully so: bugs or failures in production can cripple an organization. Since we’re human, however, it’s going to happen. We’re going to make mistakes. The more fragile the process, the more likely we are to mess it up. Rather than letting this fear of failure cripple dev teams via lengthy processes and second-guessing—which leads to a culture of indecision and lack of ownership—we’ve found it better to create a safe way to fail and to encourage failing quickly.

DevOps can help a lot, as well as clean code with well-written tests that get run before any pull request can be completed. On this team, we talked about failure as a good thing. We know that’s how we’re going to learn the right way to do a thing, that it’s part of the growth process. So we identify the types of failure that are helpful. If we complete a feature and submit a PR, but that feature doesn’t meet the business needs or is implemented incorrectly, that’s going to really hurt team velocity (plus it’s not fun to redo work, so now we’re losing energy). We may have wasted several days or even weeks. If, however, we can find ways to fail fast, we can know before we ever start implementing that we were wrong in our original understanding. This means making sure to validate our understanding of the business value and context with the product owner, our plan to implement with our tech-lead, and then proactively clarifying the work that is needed.

On our way to achieving our big vision, there are many opportunities to recognize and reinforce the kind of behaviors and efforts that are valued by our team. For instance, say a team member worked to investigate an issue and pinpoint the specific problem before reaching out for help, instead of automatically dropping the problem in someone else’s lap. In this scenario, the person providing assistance should recognize the effort the asker put in before reaching out. The asker can recognize the effort the helper put into solving the issue. Or, as a team, maybe you were able to finally finish all committed work during your sprint. Someone on the team or the manager should acknowledge that as a huge win. The opportunities will be there if you’re looking. Recognizing other’s contributions should be part of your daily practice. Celebrating wins should at least be part of your weekly rhythms.

Handling inevitable conflict

Any team of individuals who are passionate about their work and pushing themselves to be better will naturally incur conflict. This is expected and a chance for further growth. Some coaches intentionally create conflict to force the team to work together. A long-time coach and personal mentor taught me that everything that can be said negatively can also be said positively. I find this is especially useful in an office setting, where you’re often talking to a colleague or client. Ultimately, the way we handle conflict determines whether our team is stronger or weaker as a result.

I have a saying: “Never waste a loss.” Meaning, let’s learn from our mistakes so we can avoid them. When coaching, make sure the recipient understands where you’re coming from. Align yourself with team goals, the shared vision, and a commitment to excellence. You can probably tie it to their personal goals as well.

Less managing, more coaching

So, consider what would happen if we focused less on managing and more on coaching? What would happen if it was safe to talk openly about issues as they arose; if everyone owned their work and adopted an attitude of winning or losing together? I can tell you from experience: You’ll create a culture that promotes growth, collaboration, and fun. High-quality output, creativity, and engagement are actually three great metrics for managing types to track. These occur naturally in the right environment, whether you’re in the office or on the court.

The client team that I coached demonstrated discernable growth in the four months that I was with them, and that growth has sustained itself post-engagement. Today, the manager has full faith in his team to own their work from start to finish, without much intervention or over-management. They continue to accept more responsibility in response to their great work—team members have become Subject Matter Experts for the products they are working on. While we may not have achieved full autonomy yet, we’ve definitely created a winning team that not only creates value for the company by delivering high-quality solutions at a fast pace but also helps each other reach their potential.

Contact an expert