Over the last several years, Appian’s Engineering department has grown tremendously (~30% per year). We have cultivated a great pipeline of top graduates coming from the Computer Science departments at local universities, hired a bunch of successful industry veterans, and kept turnover extremely low by having a culture that people love. With that rapid growth has come loads of intelligence, creativity, and experience, but it has also brought with it a major challenge that is extremely common in this situation: How do you get all of those new developers ramped up on company specific knowledge as quickly as possible without severely slowing down the velocity of your existing developers? It is a great problem to have, but it is a very real problem all the same! The solution for us was becoming a Learning Organization.
Before looking at what a Learning Organization is, and the steps we took to become one, let’s examine some other options to see what problems arise:
A simple option for ramping up new hires is to have experienced developers work with them one-on-one to teach them the ropes. While this individual attention can help the new hire ramp up quickly, it slows the experienced developer’s velocity to almost zero while they are doing the training. One way to regain some of that velocity is to have the new hire pair code with the experienced developer on whatever work they would have been doing, but that sacrifices some of the learning quality as the knowledge being taught is guided more by the particulars of the work than by what is most important to teach. It is also common to run into an issue where the experienced developer has difficulty explaining things at a level that is understandable for a new hire, as it is very easy to assume knowledge that isn’t there yet. Carefully choosing the right mentors and the right work can make this better, but it will quickly hit an upper limit of effectiveness, especially when the growth is rapid and your pool of experienced mentors is small.
Another option is for experienced mentors to put together learning materials and put new hires through a Boot Camp, creating the materials once and reusing them multiple times. This was an option Appian used for several years while the growth rate was slower, but it started to break down as the growth rate increased. For one, it takes a lot of time to create these materials in the first place and there is an ongoing investment in keeping them updated. Since these materials are being created and updated by experienced mentors (usually a rare and valuable resource), the cost is somewhat higher than ideal. In our experience, those mentors were often needed on higher priority development work and the materials quickly became out of date; lacking coverage for new topics and (even worse) often containing outdated information that was no longer correct.
New hires could simply ramp up as they go, but in a rapid growth situation, quality suffers, velocity slows down, and new hires are left feeling unproductive and unsupported, leading to poor morale and high turnover.
From looking at these options alone, some clear requirements start to emerge:
So then, what is a Learning Organization and how can this concept be used in practice to meet these requirements?
Wikipedia has a detailed definition, but it is basically an organization that fosters a culture of continuous learning, with its members acting as both students and teachers. That might seem simple, but it can be very powerful and transformative when the organization truly embraces the idea. Employees are constantly in a state of learning (not just when they join) and need to quickly become both a student and a teacher. Our culture fosters all of this, not just tolerates or makes small concessions for it. Appian’s Engineering staff has always contained smart and talented developers, but now our Engineers are also students and teachers…all of them.
A little over a year ago, we began this transformation, and in the last few months it has stabilized into a sustainable system that is scaling as we continue our rapid growth. Newly hired developers still start out by going through our Boot Camp (now called “Engineering 101”), but it has been pared down to cover far less material since it is now just the first step on the path of continuous learning.
After Boot Camp, developers join their new teams and pair code on small tickets — but they don’t do this with seasoned veteran mentors, they do it with junior developers who have joined in the last 6–18 months. Those junior developers still remember what it feels like to be “noobs,” knowing about as much as Jon Snow, so they are able to explain things at the right level. Just as importantly, these recent students are now teaching, which helps them to confirm and solidify their own knowledge and grow their mentoring skills at the same time.
After a couple of months on a team, the formal education process continues with the student taking the Engineering 201 course, giving them additional foundational knowledge that they weren’t ready to consume during Boot Camp, but they now have the context to grok. In addition, they can start going through topic specific courses that are part of the Engineering 202 set (e.g., “Intro to React,” “JUnit Testing,” “Intro to SAML,” “Usability Testing,” and “Intermediate Spring Concepts”). These courses are reasonably short and self-guided, so students can work them into their schedules on a regular basis without taking a long break from their team’s sprint work. Since everyone has embraced a culture of continuous learning, the teams are supportive of members taking this time, thereby reinforcing the learning culture. As new members ramp up much more quickly than before, the teams share in the benefits.
Once new hires have been in the department for 6–9 months (although this has been slowly shrinking as the system has grown), they have learned a great deal and are very productive members of their teams. As mentioned earlier, this is when each junior developer starts to grow beyond a student into becoming a teacher as well. In addition to pair coding with new members to help them ramp up, it is at this time that we have them start to ‘give back’ to the system to make it sustainable.
Junior developers are responsible for either the creation of a new Engineering 202 course, if the topic they choose does not have a course yet, or the maintenance of existing courses if the materials have started becoming stale. As they create the course, often pairing with another junior developer, they are encouraged to fill in any of their knowledge gaps by consulting with mid and senior level developers. In this way, they are again able to reinforce what knowledge they have already gained as well as learn new things as needed. This also allows a senior developer (usually a precious resource) to remain focused on solving hard technical challenges and mentoring mid-level developers, with only minimal requirements on their time for mentoring junior developers along the way (and no time spent mentoring new hires). To provide additional motivation and embed this practice into our culture, we even added 202 course creation as a part of our promotion plans, making it clear that learning and teaching are part of our core values.
Using this “crowd-source” type of model has allowed us to scale up the amount of training content with the pace of growth with only a handful of volunteers (members of the Education Guild) to maintain the system — primarily providing structure and guidance for new course creation, and curation of the course library (which, as a nice bonus, we manage using our own product — hurray for dog-fooding!). The process has proven so successful that we have started expanding it beyond Software Engineers and now courses are starting to come online for our Quality Engineer and Product Owner roles, with courses for the Agile Coach and Chapter Lead roles in the works.
Scaling quickly can often be both perilous and painful in a number of areas. Adding a large number of new developers can dramatically increase your productivity…once they are ramped up. Getting to that point is a major challenge and often results in sacrificing velocity or quality along the way. As we have continued our rapid growth rate at Appian, becoming a Learning Organization has helped us maintain a growth mindset and given us a critical tool for ramping up new hires quickly while maintaining our ability to deliver high-quality software to our customers. If your Engineering department is fortunate enough to experience rapid growth, creating a learning culture could be a key factor in managing some of the growing pains involved.
Appian’s Engineering Education: Creating a scalable and sustainable learning culture was originally published in Appian Engineering on Medium, where people are continuing the conversation by highlighting and responding to this story.