You need a partner who prioritizes your digital product’s long-term success. That’s DockYard. Book a free consult today to learn more.
Senior Software Engineer Stefanie Holbrook coauthored this blog.
Whether you are a tech lead, a CEO, a Product Owner, or something in between, you have probably wrestled with these questions on some level: How do I balance structure with flexibility? How do I empower my team to keep them engaged without losing control of the product? How does my team “self-organize” without going off the rails?
These are good questions to ask, and whatever your level of leadership, you should consider the implications of your answers.
To gain some insights, we turned to Stefanie Holbrook and Peter Reynolds, two DockYard team leaders with plenty of experience building and managing digital product development. Over the past few years, Stefanie and Peter have led a team of 12-15 engineers, splitting leadership responsibilities with Stefanie as Technical Lead and Peter as Project Lead. Peter handles the business coordination, roadmap planning, and requirements gathering, and Stefanie oversees application stability, technical decisions, and engineering quality.
On this team, they have built something truly unique and very successful. Let’s take a look at what they did, why they did it, and how those concepts might help your team!
What Did Your Team Do, and Why Did It Work?
Peter: We kicked off the team with a couple core values. First, we all agreed that we are not here to show off or prove that we are better than everyone else. This created the safety to make mistakes, ask for help, and learn from one another. When no one is trying to impress anyone else, they can focus on building what needs to be built. Second, we agreed that “We take our work seriously, but not ourselves.” With those two foundations in place, we can work on a team with little room for ego-driven engineers or fear of making mistakes. No more fighting to be the coolest engineer in the room or being too afraid to ask the simple questions. We all already have the job, let’s just build cool stuff together.
From there, we realized that most engineers tend to like variety in their work; sometimes working on a straightforward AppSignal error and other times leading an initiative across a few months. No one likes to be stuck in the doldrums, but high-pressure work without an offramp burns people out, too.
So, we set up a rotating feature lead structure. Every new item on a roadmap went to whoever was next in line. Every few months, each engineer would get the opportunity to conduct a “spike” on their new feature, cut out and explain all the tickets to their “squad” of two or three other engineers, and oversee that feature all the way out the door. Acting as technical lead on a small feature built ownership, confidence, and shared respect throughout the team as everyone got a chance at the helm.
Stefanie and I still oversaw all the work, though. I shepherded the roadmap, making sure we always had the next top-priority thing ready to work as the team became available. Stefanie ensured the engineering team met their agreed-upon standards in each new feature.
Stefanie: As Peter said, no one likes to be stuck in the doldrums. A common problem I’ve experienced on past engineering teams is the siloed engineers and knowledge. Individuals become masters of a domain that no one else knows anything about. This not only creates monotony in your day-to-day work but also leads to lost knowledge when that engineer moves on.
When I started as tech lead I saw that Peter had the same concerns. His structure made it easy for me to create a space for engineers to stretch their wings with the support necessary to succeed.
As a team, we established a weekly engineering meeting for knowledge sharing, getting feedback, and conducting architecture reviews. Engineers rotating as leads on upcoming initiatives could use this time to share a solution with the team. That allowed individuals with knowledge in this area to share what they know and helped spread knowledge to team members who weren’t involved in that specific initiative. Rotating as leads and sharing your solution doesn’t just break up the work, it also has the benefit of preparing engineers for senior roles and leadership.
This system also works well when it comes to handling technical debt. As engineers tackle different problems, we come upon issues with old systems or infrastructure. Providing a space for exploration and discussion allows engineers to document the issues and present a solution for addressing them.
Should We Do This on Every Team?
Stefanie: Every team will be unique, and require different approaches. Our team currently has an even spread of staff, senior, and junior engineers. This allows us to utilize the different strengths of team members, while also supporting junior engineers.
Peter: No. Other teams should not copy and paste this solution onto their structure.
Like Stefanie said, every team is unique. A forced structure (yes, even an “agile” structure) is never a “one size fits all” solution. This pattern worked well for this team. It grew and adapted naturally through transparency, inspection, and adaptation.
Maybe this would work for them, maybe it wouldn’t. Not every team will communicate like this one. Not every team will feel comfortable passing leadership around from epic to epic. Not every engineer wants to learn the product side of the application. Just because it worked here, don’t assume your engineers want to do the same thing.
What Core Takeaways Should People Apply to Their Teams?
Peter: Instead of forcing a new team into a “lived-in” structure, rather try talking with your team. Trust them. They want to build the best application they can, and they want to build it in a working structure that supports them.
Within generous guardrails, teams can flourish. Engineers do well when they are able to voluntarily wear other hats from time to time — hats like tech lead, UAT facilitator, analytics researcher, or bug collector. Variety builds stronger engineers, but only when it happens naturally.
A lot of what we did was simply asking the engineers how they prefer to work, and building a repeating pattern around that.
I have written previously about how trusting your Product Owner leads to a more resilient product. To build on this, Product Owners should trust their team of engineers. After all, it is the builders who know the house best. Give your team targets, the next feature or user experience, and let them direct you on when it will happen, how that will work, and what might be better. You set the vision and the guardrails, let your team build the product.
Stefanie: At the end of the day, your team’s needs will be unique to the individuals within it. As Peter stressed, to create a collaborative environment where we’re all doing our best work, it’s important to trust your team.
Empower individuals to take ownership of problems. Whether it’s related to code or team processes, let engineers gravitate toward the work they’re passionate about, and provide support and encouragement in the areas where there’s opportunity for growth.
A team only collaborates as far as their trust takes them. Empowering the engineering team always creates room for the team’s natural strengths to shine. They leverage the existing team dynamics, relying on camaraderie and distributed leadership to build quality products at a sustainable pace. Let your team organize around a system that works for them, let them ask questions and drive product architecture, and give them the space to do it!
