How do you foster growth in your engineers? It’s a question I grapple with as a team leader at PEAK6. I strongly believe that mature, self-organized and motivated teams are the best way to deliver quality products. And while teams are more than the sum of the individuals who comprise them, growth, learning and advancement for individuals are great for both the one and the many.
The most effective habits create a positive feedback loop where the team supports the growth of the individual, which in turn enhances the team. These four habits have served me and, more importantly, the teams I’ve led and have been a part of, well.
4 Habits that Foster Growth in Your Engineers
- Separate owning and doing.
- Rotate production support.
- Reimagine tasks as opportunities.
- Write everything down.
1. Separate Owning and Doing
One of the best ways to grow as an engineer is to own the design and delivery of a feature. Owning a feature includes a lot of responsibilities outside of writing the code that powers that feature. It starts with partnering with a product owner or customer to understand the need and provide different options to satisfy that need. And even after the feature is shipped, owning means also helping with demos, onboarding or preparing marketing material.
In this way, the engineer owning the feature exercises many critical muscles, including leadership and design abilities. Especially when paired with the backing of an entire team and a manager, feature ownership gives less-experienced engineers a safety net to take risks and stretch themselves.
But if owning also includes doing all the work to bring that feature to life, few engineers can take advantage of the growth opportunity. They’re simply too buried with work. It could also include intimidating moments, such as presenting a design document for feedback the first time.
For those reasons, an owner should seek to be responsible for everything getting done as opposed to responsible for doing everything.
Tips for Success
To avoid engineers from getting too buried with work, I like to use frameworks like messy opinion/neat ownership or request for comment or RFC-driven development that allow for collaborative design while empowering an individual to own the decision.
On the delivery side, there are even more strategies software engineers use to collaboratively deliver work: pairing, swarming, mobbing, splitting, tasking. These tools are regimented approaches to problem-solving that can help an engineering manager or team lead spread out ownership while keeping the entire team engaged and allowing senior engineers to coach and guide the technical direction.
On a team I managed recently, a fresh-out-of-college hire owned a large, fundamental feature on a service owned by a team with multiple senior engineers. He was responsible for writing a design document, soliciting and incorporating feedback, and updating it as the implementation progressed. He did some of the development, but the largest value he provided was understanding the different streams of work and how they came together. There’s no way he could have designed and delivered this on his own, but by separating owning from doing, he was able to gain the experience of effectively owning the feature.
This isn’t simply about getting the work done effectively; it’s equally about building up engineers so that we all get even better at delivery and problem-solving.
2. Rotate Production Support
One of the most effective ways for someone new to a company or a team to get an understanding of the system is to support that system in production. Production support helps engineers build their overall competence. By supporting a system in production, engineers learn how the system works, gain confidence in their abilities, and learn to troubleshoot issues as they arise.
Yet production support can be a stressful, high-risk activity and the high stakes can impede younger engineers from jumping in and gaining that valuable experience themselves. Because of that, some teams fall into a habit of having the same two or three senior engineers jumping in and resolving issues that come up in production.
Tips for Success
Rotating production support — including experienced back-up — can help engineers challenge themselves and take on work they may not be super comfortable with while supporting them with back-up in case they get stuck. When issues do arise, it’s important to make sure everyone on the rotation is involved in the resolution in order to transfer knowledge. Over time, junior engineers gain the know-how to handle most issues without escalating.
To make sure junior engineers get this regular exposure to production support, one of our teams introduced a primary and secondary support rotation for production. The primary support is generally the newer or younger engineer, who is responsible for acknowledging and triaging an issue. The primary support person can bring in the secondary support person if they cannot solve the problem.
3. Reimagine Tasks as Opportunities
As an engineer grows in their career and with their team, their responsibilities naturally grow. Often these new responsibilities — code reviews, meeting with stakeholders, organizing and facilitating design discussions, writing up release notes, handling support questions, interviewing, and so on — are purely additive. The combined responsibilities will scale with the engineer’s increasing abilities and competence, yet, eventually, the sum of those responsibilities can become a drag on that engineer’s growth.
Continuously adding to what you do without ever leaving tasks behind is a recipe for stagnation or burnout. Instead, reimagine these activities as opportunities for others on the team. By reassigning them to others, you can both grow the skills of junior members of the team and free up senior engineers to focus on areas that deliver the most value. Moreover, increasing the number of people on the team who can handle any given task strengthens the flexibility and responsiveness of the team.
Tips for Success
As a senior or established member of a team, it is healthy to routinely audit how you’re spending your time to identify the activities that could be opportunities for others on the team. Perhaps you spend a lot of time working with other teams ensuring that their feature aligns with your team’s long-term design? Maybe there’s a piece of shared infrastructure like a continuous integration tool that you regularly troubleshoot? These provide opportunities to gain visibility, build a network, and develop expertise. There’s a reason you started doing them in the first place.
Keep in mind that, when transferring opportunities to others on your team, it’s best to hand off complete ownership. In short, don’t merely delegate — deputize.
4. Write Everything Down
One of the most valuable habits a team can adopt is a culture of documentation. For experienced engineers, clearly and concisely documenting systems and designs helps sharpen thinking and design skills. For less-experienced engineers, having a corpus of documentation can help fill gaps and direct learning.
Especially as more teams work remotely, writing things down facilitates rich communication, deep thought and asynchronous collaboration. In many cases, documentation also enables more avenues to collaborative work. For example, it’s sometimes easier to ask a question as a comment before raising it to the group. Someone unfamiliar with the material can consume the entire document, batch up questions and bring them to someone else on her team and get deeper, more holistic answers without repeatedly breaking the focus and flow of her teammate. Furthermore, incorporating the answers to those comments make the documentation more robust and useful going forward.
Documentation also creates a shared, durable artifact. This comes in handy when it comes to onboarding new developers or even reacquainting yourself to an area in which you have not been actively developing for a while. And, as your documentation grows, teams can answer common questions or resolve issues through the shared reference.
Finally, documentation makes it easy for all teammates to participate in architectural decisions. Lively discussions and energetic white-boarding sessions are great channels for many people to collaborate on creative and complex problems. For others, those sessions are intimidating and draining. Continuously generating a design document allows for more introverted members of the team to hear the positions of their teammates and contribute their own ideas and perspectives in a way that is comfortable to them.
Tips for Success
At PEAK6, we encourage teams to write lightweight architecture decision records (ADRs) and share them with the entire engineering organization for feedback. In the moment, it can help ensure you are making a decision with the most complete information. In the long term, these records provide context and durable knowledge about why decisions were made. We are moving beyond simply ADRs to design documents, project post-mortems, and even making sure we capture refinement discussions. By writing things down, we are enabling everyone to find key information and the context in which decisions were made.
Developing these four habits takes regular time and attention. In fact, the teams that consistently grow their capacity and impact often have periods where they slow down. But if a team always optimizes for productivity or velocity, it skips over opportunities for cross-training, reflection and innovation. So while some of these growth strategies may lower velocity in the short term, ultimately, by growing the capabilities of everyone on the team, this approach will lead to a flexible, sustainable and truly agile engineering team.
