By    |   January 12, 2021
Is your engineering team using these 4 key practices for growth?

How do you grow a technologist? It’s a question I grapple with as a team leader at Capital Management. Professional growth and mentorship are values that are steeped across our organization. As I think about fostering growth for those on my team, four “habits” come to mind.
 

1. Separate owning and doing

One of the best ways to grow as an engineer is for them to own the design and delivery of a feature. 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.

Why this habit matters

Owning a feature exercises many muscles that are critical, including leadership and design abilities. However, many engineers are intimidated by presenting a design document for feedback the first time. During a sprint, owning a feature naturally encourages an engineer to step back to ensure all the pieces fit together into the big picture. Especially when paired with the backing of an entire team and your manager, feature ownership gives less-experienced engineers a safety net to take risks and stretch themselves.

Tips for success

To avoid engineers from getting too buried with work, I like to use frameworks like Messy Opinion/Clear Ownership 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 to collaboratively deliver work: pairing, swarming, mobbing, splitting, tasking. These tools 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. On the delivery side, 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 get even better at delivery and problem solving.

2. Rotate production support.

At PEAK6, our teams own their services from ideation through production. 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. Yet production support can be a stressful, high-risk activity. 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.

Why this habit matters

Production support helps engineers build their overall competence. By supporting a system in production, engineers learn how the system works, gain confidence in their own abilities, and learn to troubleshoot issues as they arise. Yet, the high stress and high stakes of production support can impede younger engineers from jumping in and gaining that valuable experience themselves.

Tips for success

Rotating production support—including experienced backup—can help engineers challenge themselves and take on work they may not be super comfortable with, while supporting them with backup in case they get stuck. When issues do arise, it’s important to make sure everyone on the rotation is involved in 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 the primary cannot solve the problem.

3. Reimagine tasks as opportunities.

As an engineer grows in her career and with her team, her responsibilities naturally grow. Often these new responsibilities, such as code reviews, meeting with stakeholders, organizing and facilitating design discussions, writing up release notes, handling support questions, interviewing, etc., are purely additive. The combined responsibilities will scale with the engineer’s increasing abilities and competence, yet eventually, the sum total of those responsibilities can become a drag on that engineer’s growth.

Why this habit matters

Continuously adding things you do without ever leaving activities behind is a recipe for stagnation or burnout. By reimagining activities as opportunities for others on the team, 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 it 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 your thinking and design skills. For less-experienced engineers, having a corpus of documentation can help fill gaps and direct learning.

Why this habit matters

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, reducing context switching for everyone. 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.

Tips for success

At PEAK6, we encourage teams to write lightweight Architecture Decision Records (ADR) and share them with the entire engineering organization for feedback. In the moment, it can help ensure you are making the 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. If a team always optimizes for productivity or velocity, it skips over opportunities for cross-training, reflection and innovation. Some of these growth strategies may lower velocity in the short term, but, ultimately, by growing the capabilities of everyone on the team, this approach leads to a flexible, sustainable and truly agile delivery team.

Want to grow with our team? Check out our open our open roles.

Paul Nelson

Paul Nelson

Paul Nelson is a director of engineering with PEAK6 Capital Management, working with the product delivery teams to build best-in-class tools and system for our users. Outside work, he enjoys cooking, reading science fiction and keeping his two dogs from destroying the house.