How do you help a new hire start contributing to an agile delivery team in as little time as possible? At Asynchrony — an agile software-delivery firm expanding and hiring rapidly — we embarked on an experiment exactly a year ago to bridge the gap for our new employees between orientation and the high-expectations of a real, billable customer-facing delivery team. What we tried we called simply “The Learning Team,” an ongoing internal team where new hires and veterans alike can safely learn new skills like TDD, pairing, continuous delivery and data-driven forecasting so that they can hit the ground running with external-facing teams.
Our current organizational context necessitated that we find a way to more effectively onboard people. We’ve been growing at a pace that has meant aggressive hiring goals, which increasingly means that we’re adding people who have the aptitude and attitude for but sometimes not the experience of agile delivery. That means that some new hires may not have experienced pairing, TDD or other vital practices for how we deliver quality software for our customers. We’ve found that, although pairing dramatically shortens the learning curve for new team members, new hires were not always able to go straight into that environment.
In the past, we had occasionally used ad-hoc and sometimes loosely run “bench projects” as places where new hires spent a few days before jumping onto a real project. But those were not designed to provide much in the way of mentoring or professional development; they were more a place to bide time. We had also recently successfully experimented with research teams, but those were more oriented toward R&D than product delivery.
Enter the Learning Team.
With the leadership of our CTO, Nate McKie, we envisioned it to be a permanent, first-class team, staffed by a full-time tech lead, a full-time product owner and a part-time agile coach. Following the first week of a new hire’s tenure at Asynchrony, which includes the same three-day agile overview workshop that we offer to our customers, he or she would join the Learning Team. Depending on the individual’s learning goals, the person might be on the team from a few days to a month or longer. It would also be a safe place for existing Asynchronites to acquire new skills or transition to a new role. (For instance, one colleague who has been with the company for a few years wanted to learn the skills of product ownership, so we made her the team’s product owner.)
Since the project would be entirely internal, we would have few, if any, dependencies outside of our control, so we could run the project in an exemplar way, focusing on learning through delivery. As an advisor to the team, I occasionally encourage the new hires to immediately apply the learning that they get in the agile overview workshop to what they’re doing in the Learning Team. The pattern should then be:
- Implement in the Learning Team the good practices you hear about in Agile Overview, then
- Implement in your future customer-facing team the good practices you experience in the Learning Team.
Our Crossing-the-Chasm-style elevator pitch looks like this:
For new hires and veteran Asynchronites
Who need to learn the Asynchrony delivery “way,” brush up on skills or learn new ones
The Learning Team is an internal delivery team
That provides a safe place to learn proven practices and experiment with new ones
Unlike being thrown straight into a team without knowing what great delivery practices look like
The Learning Team is an exemplar team where people can learn healthy practices that they can take to other teams.
We kicked off the team with a proper inception, complete with “customers” and internal stakeholders. We added a twist to the typical visioning, chartering and release planning of inception: personal learning goals. Each person on the initial incarnation of the team took some time to write and share his or her goals with the rest of the team, which they would hold each other accountable for and encourage each other in.
Obviously, the biggest risk was whether the return would be worth the investment. After all, it’s not chump change to intentionally run a bench project, staffed with a coach and dev mentors. Nate had gotten buy-in from the rest of exec management to carry out the Learning Team experiment for a few months. Had it failed, we would’ve pulled the plug and tried something else. But we’re now to the team’s first anniversary, and we’re continuing because we’ve seen how much it has bridged the gap for new hires — less friction when they join new teams, and the added bit of confidence that they know something about delivering in the “Asynchrony way.” Moreover, we now have a couple of employees who have gained valuable experience as product owner and tech lead who are potentially able to do those roles in other teams. It’s true that we incur opportunity cost by “benching” our people to work on the Learning Team. But the tradeoff in reduced risk is worth it. People who are new to Asynchrony and our way of working — in which transparency and honesty are precursors to learning — aren’t always trained or made to feel safe to expose what they don’t know. The Learning Team helps them develop that mindset so that, when they start pairing in earnest under the delivery pressures of customers, they don’t feel they need to hide problems or take shortcuts, which can lead to messy delivery problems. With so many new people coming onboard, we need to invest in preparing them for success. It’s one of the necessities of fast growth.
Because the team composition is always in a state of flux, we have to always be prepared for someone to leave. We’ve mitigated that somewhat by having three of the roles — product owner, tech lead and coach — be staffed by the same people, which provides some continuity. Also, because members don’t generally know when they’re going to be “promoted,” it can be disconcerting and inhibiting to team morale. Along with that, we’re still trying to figure out the answer to the question “When is a person ready to move out of the Learning Team?”
We also learned that we need to choose the product and tech stack wisely. The product that the Learning Team has been developing over the last year was built on a legacy code base with a not-insignificant amount of a not-altogether easy language to pick up (Erlang). With dependencies on some business-facing concerns about the legacy code base (some real customers use it) and the steep learning curve of Erlang, we have decided to use a simpler, more straightforward product so that the team members can focus on Asynchrony agile delivery rather than some of the unnecessary distractions from our previous product choice.
We’ve seen benefits for our new hires being able to more smoothly integrate into their delivery teams and for our veteran employees learning new skills and roles. One of unexpected benefits that I’m looking forward to in the new year as we emphasize exemplar practices in the Learning Team will be to the delivery teams themselves, getting infused with people who not only avoid a drag on their throughput, but provide fresh, innovative practices to invigorate the teams. My goal is to hear more things from Learning Team graduates such as “We were doing continuous delivery on the Learning Team; why aren’t we doing that on this team?”