1 Introduction

7digital are the power behind innovative music experiences. Their diverse, highly regarded team of software and systems engineers build the music streaming and download platform that powers services for global brands. The industry in which they operate is fast paced and ever-changing, and the team needs to grow to react to those changes. Growing the team with the right type of people has often proven difficult but was addressed in 2012 by the inception of the 7digital Technical Academy. The academy programme has completed its third iteration and has evolved through continuous improvement with regular inspection and adaption. In the first iteration, a key retrospective resulted in a move to pull based learning; asking apprentices to solve real business problems and request sessions on the skills they needed to accomplish their objectives. The second iteration saw peer to peer learning and a self organising community develop amongst apprentices. The third iteration brought a wider set of people to the academy and was used to expand understanding of Lean and Agile principles across the organisation.

The authors have been heavily involved in the Technical Academy with Paul Shannon, now VP Technology, being the founder of the programme, and Miles Pool, the coordinator of the third iteration and a second iteration graduate.

2 Background

When searching for software development roles on the most popular recruitment websites the ratio of jobs requiring greater than two years’ experience to those requiring fewer is eight to one. Additionally, finding senior software developers, with greater than 5 years’ experience is notoriously difficult – so how do we provide the opportunity, to those with less experience, to work in a welcoming and learning oriented culture so that they can become senior members of our community?

These problems are not unique to any company working in the tech sector but became more prevalent at 7digital when they focused on quality driven software development practices, as the requisite skills made experienced people even harder to find.

7digital was established in 2004 as a small start-up in London’s “Silicon Roundabout”. After establishing itself in the first 5 years there was a marked switch to quality driven practices with the appointment of key people experienced in Agile and XP. The two development teams at the time totalled around twenty people, over half of the total organisation. As the technology platform expanded, so did the teams and the need to fulfil roles, and by 2011 the total head count for the Technology Team was forty with further plans for expansion.

2.1 Apprenticeships in Software Development

In early 2012, senior members of the team looked to solve the common problem of a lack of experienced hands available to join the team. They researched efforts in the Software Craftsmanship community to utilise the master/apprenticeship format of more traditional trades. 8th Light [1] ran a programme that defined levels of craftsmanship in the team, with newer members joining as apprentices and being mentored by master craftsmen on a one-to-one basis.

Other efforts of this one-to-one tuition style were attempted by Codemanship, and an interesting initiative at Accenture assigned groups of people to particular learning projects as they joined. One of the team leads at 7digital had experience in a classroom based training scheme during the agile transformation at Codeweavers Ltd [2] involving short, focussed sessions away from the usual team room for new team members to try intensive learning on a particular topic.

While many of these schemes had benefits, they didn’t directly fit with the team’s desire to expand and invest in the future.

“Education is the kindling of a flame, not the filling of a vessel.” – Socrates

2.2 Diversity

A major opportunity the team saw with expanding through internally trained developers, was that they could attract a more diverse cohort.

Gender diversity in the tech industry is a perennial yet slowly improving issue. The 7digital team hoped to improve the diversity of their team by offering a lower barrier to entry than their usual recruitment process. Research suggests [3] that female applicants are less likely to apply for positions that require assertions about experience or achievement - they would only apply if they meet 100 % of requirements whereas men would apply when meeting only 60 % - so a programme which provided training and which emphasised a lack of requirement for experience was believed to be beneficial.

Software development candidates are often products of education in a narrow field of study – Computer Science. The team felt that more diverse backgrounds would provide a wider selection of opinions, so a scheme that would be attractive to people in any field was most desirable.

3 Timeline

Before the academy was created, a first attempt at addressing our recruitment needs with a lower barrier to entry began with an apprenticeship model similar to that at 8th Light. New team members, with some experience in programming, were assigned a mentor and were expected to pair and learn from that person during their daily development tasks. This proved disruptive to teams as they effectively lost a senior developer who spent most of their time teaching, especially in the initial three months.

The following year, in 2012, we decided that a new approach should be taken and the Technical Academy was created. Following a gap of two years the second iteration began and then an opportunity one year later led to the running of the third. The programme is based in the London headquarters of 7digital with co-located teams.

3.1 The Inception of the Technical Academy

Research into other organisations’ attempts at apprenticeship programmes led us to believe that we needed some structure, a curriculum and a clearly defined career path for the Technical Academy. While the efforts at Codeweavers Ltd. proved useful, the lack of direction meant it was not a key part of the team’s learning there. Efforts elsewhere resembled the initial efforts at 7digital so a committee was formed to discuss and decide upon how to proceed.

An early agreement was reached that apprentices should be hired as full time developers, with a permanent role and that the offer of a position was not dependent on completion of the academy. This would give the apprentices confidence and security that they had a job at 7digital and were just at the start of a potentially long and prosperous career. To ensure a level of protection for both the apprentices and the organisation they were given an extended six month probation period.

3.2 Hire an Apprentice: The First Iteration

For the initial iteration we hired two new developers by advertising the role and contacting universities externally, and recruited one internal candidate through transfer from the operations team. Interviewing candidates with little or no experience in programming posed a challenge as the usual recruitment process involved working through a simple code kata. We decided that as the candidate was joining to both learn, and to write software, that this was still the best form of early assessment. Candidates paired with a senior developer on a simple test-driven development coding exercise. An observer would take notes, paying particular attention to how the candidate reacted to new concepts, such as test automation and refactoring, and how soon they could contribute to the conversation.

Once apprentices had been selected the committee planned a curriculum. This included skills related to Agile software development and Lean practices, with sessions on subjects such as Test Driven Development, Theory of Constraints, Databases, DevOps, Continuous Delivery and Design Patterns.

To help clarify what the apprenticeship entails, we produced a “path to becoming a 7digital developer” - this was a timeline encompassing an intensive “bootcamp”, tapering to less frequent sessions on basic techniques before moving into a term of specialisation and project work; it ended with graduation in week twenty-six. Graduation was a company-wide event involving presentations, drinks and gifts.

3.2.1 Adoption of Pull Based Learning

It was identified early that apprentices were being asked to pair on tasks involving concepts they had not yet been taught. A problem here became evident when a team member was struggling to explain to an apprentice the concept of Dependency Injection - a complex but widely used solution to software modularity. This was raised with the Academy coordinator who organised a dedicated classroom session on the topic. Following this the apprentice rejoined his previous pair, with an understanding of the concept and was then able to contribute to the continuing work.

At a similar time we met with Professor Dave West, who had been running a unique degree programme at New Mexico Highlands University, USA [4]. This course had students, with no software development skills, working on commercial projects and requesting the skills they wanted to learn in order to accomplish their task. They used regular feedback, retrospectives and planning meetings to ensure they were developing the right skills to develop software.

The success seen on Prof. West’s course, and in conjunction with our example above, led us to adopt pull-based learning; coordinators would talk to apprentices, tutors and team leads to organise group sessions on the topics that were currently of most relevance.

3.3 Evolution in the Academy: The Second Iteration

Following a two year hiatus, we decided to reinstate the Technical Academy under a new coordinator. The driving force behind this decision was from members of the team, including prospective internal candidates, perceiving the successes of the first iteration. Internal apprentices were thus self-selecting - one transfer to the Technology Team, and for the first time, one apprentice looking to up-skill in their existing, non-development role. Two external candidates were recruited as we had done in the first iteration.

The broad structure of this iteration was much like the first, however each of the four apprentices was now assigned a tutor who was on hand to assist with any technical issues. During the “bootcamp” first term these tutors felt superfluous.

In the weeks before the second iteration, the coordinator collated project ideas from teams in the wider business.

“The proposal should have clear interest to the business, but its implementation will be a proof of concept.”

At eight weeks the apprentices chose a project to implement over the following four months. Each project had a product owner who would help define requirements, and ensure continuous delivery practices were observed. With projects framed as real business products, apprentices were also encouraged to adopt practices such as test-driven development and Kanban, with Technical Academy stand-ups attended by stakeholders. While helping the apprentice, the tutor would check for clean code and good automated testing.

In the latter terms the pull for technical sessions allowed the structured learning framework to fall away in favour of “just-in-time” planning. The cohort situated in disparate development teams, built up a strong community with equally disparate technical skills; an environment highly conducive to peer-to-peer learning.

Following a term two retrospective, apprentices took to pairing on their projects; this was of particular benefit to the apprentice not based in a development team. It also allowed apprentices to work confidently on a new and unfamiliar codebase.

3.4 Reflective Practice: The Third Iteration

Just six months after the second 7digital Technical Academy the opportunity arose to take on another two apprentices. The academy was reinstated, this time coordinated by a Technical Academy alumnus. The academy started up with a total of six apprentices, after a short recruitment process and a number of existing speculative applications. Two new hires were made along with one internal transfer, with three apprentices from Operations and QA Teams looking to up-skill.

Termly retrospectives produced a number of valuable actions. To foster an open environment for discussion, a weekly reading group was set up in which apprentices would discuss several, occasionally conflicting articles. Further, it was felt that some crucial topics were introduced, and swiftly left behind. The solution was to theme the week’s practical, classroom and reading group sessions, and then to gauge the apprentices confidence level in that week’s topic.

3.4.1 Selecting Tutors

Often the developer working directly with an apprentice is not the most suitable person to teach a given subject. It is thus more beneficial to select an appropriate tutor from a wider group, on a subject-by-subject basis.

In the Technical Academy it is important that many and varied members of the organisation have direct contact with the apprentices. In contrast with the master-apprentice pattern, being exposed to diverse views within the team aids the apprentices in drawing their own perspectives on the values the team hopes to instill. It is felt that this is important in a team with a strong culture of shared responsibility. The academy is also a learning experience for the tutors themselves, many of whom are previous apprentices, and the more people involved, the greater this benefit.

4 Discussion

Making the academy visible was a key goal from early on; both in terms of its operation and its efficacy. We managed the first part by advertising sessions more often and getting people outside the team involved in project work. The graduation ceremonies and project demonstrations also increased visibility. Within the teams though we wanted to show that the academy had a positive effect on throughput and cycle time. This was difficult as many other factors could influence these measures (continuous improvement, absence, team changes, changing business needs) but the general trend for teams with apprentices was that, after week six, apprentices were making a positive contribution. This was attributed to the additional person available for pairing and - following their intensive classroom sessions - apprentices were now adding value during these pairing sessions.

Having someone with a new perspective, focusing on the detail and asking novel questions was itself advantageous, - one example being a simple observation resulting in a complete change in operation when an apprentice questioned whether we were encoding audio files in a mathematically suboptimal way.

Qualitatively, the benefits of placing apprentices into development teams as soon as they arrived helping the apprentices to feel as though they were already an important and valued member of the Technology Team - this was crucial in fostering a supportive community. It also allowed the apprentice to easily join existing pairs and gain exposure to the team’s domain; something which cannot easily be taught during academy sessions.

The feedback cycle of pairing, and subsequently discovering missing knowledge helped drive the tuition, through pull based learning. This “just-in-time” planning of sessions ensured tuition only on subjects that had a direct impact on the daily work of the apprentices, minimising the gap between learning and practicing those skills. Apprentices thus honed new skills through use, adding business value quickly. This resulted in a natural progression from isolated student to fully engaged team-member over the course of the six months.

Retrospectives in the Technical Academy gradually became more frequent as the value they delivered to the learning process became apparent, and with regular continuous improvement these ideas were instilled in the apprentices’ daily practice.

With larger cohorts, the community in the academy was slower to develop; a larger group meant apprentices would speak less readily in early open-forum sessions. Furthermore, with a larger cohort less one-to-one tuition was available. While one-to-one tuition has its advantages, group tuition was more efficient when introducing the fundamentals of a new concept. Pull-based group tuition also exposes apprentices to topics they may not yet have faced. On the whole, a balance of group tuition and pairing with other developers is more effective than either technique alone. Eventually a larger cohort became advantageous as the drive for technical sessions rapidly increased as the apprentices made progress with their technically-diverse work. With so many ongoing projects, the challenge then came in keeping up with the pull for such a diverse set of topics. Grouping these topics in a loose, longer-term curriculum was a method introduced to prioritise the sessions.

Tutors and coordinators also benefited from the academy, through areas of personal development and daily variety in their work. The sense of purpose and achievement garnered from contributing to the next generation of software developers, and ensuring they were taught quality driven practices, made it worthwhile for those donating their time. Tutors and team members that were helping apprentices were also challenged on their knowledge, as they were suddenly required to teach what they’d previously taken as rote. When Technical Academy graduate, Sophie, was asked to pair with a new apprentice she said:

“You have to really think about what you’re doing and it makes you realise how much you do actually know. I still question myself though, but that helps me to learn too.”

4.1 The Tech Academy in the Wider Organisation

A key change in the third iteration was to have projects backed by the 7digital product team. This improved alignment with adding business value and the projects gained more prominence in the wider business.

Fig. 1.
figure 1

Cycle time for content discovery team during their apprentice’s tenure

Full size image

There were some initial disagreements from other teams about the impact of the academy as it does require team members to spend time away from their usual daily work. We investigated ways we could measure and adapt, and elected to look at the things already measured (throughput and cycle time) while getting regular feedback via retrospectives, one-to-one meetings and reports to senior team members. One of our teams that took on an apprentice in the third iteration had a cycle time of around 2 days before she joined. For the following 6 weeks the cycle time rose to 4.3 days peaking at 5 days before reducing again back to 1.7 days (see Fig. 1).

When Miles joined the Content Development Team he initially had a detrimental effect on their throughput, reducing it to 1–2 minimum marketable features delivered per week for about 8 weeks. The middle period of his tenure in that team saw a stable throughput which then increased towards the end of his apprenticeship. We also added more people to the team in his sixth month which saw the momentum in the team further accelerate with a peak of 13 features delivered in one week.

The pattern based on our metrics appears to make a team slow down for the initial 6–8 weeks, then return to the team’s previous pace for the middle part of the apprenticeship. Within the last month or two of an apprentice’s tenure a team sees the throughput increase and cycle time decrease as the apprentice contributes more. While other factors could be affecting this, the general feeling of teams is that apprentices add value early on but notably from 4 months onwards.

4.2 Future Directions

An interesting consideration is the comparison between former Technical Academy developers and those hired from other companies. Shared team values seem to be more prominent in the academy graduates as they’ve been trained specifically by the existing team, and not had to forget the ways of their previous teams. However, this meant that fewer tried-and-tested ideas come from apprentices versus seasoned developers so the trade-off meant that a balance between new ideas, team cohesion and well known practices exists.

We considered alternative approaches prior to setting up the first Technical Academy (Sect. 3) but have since adopted new practices that should aid in training inexperienced developers. Mob programming is a good example of a practice we now use more often that is well positioned to easily spread knowledge. We’ll investigate its use as a learning tool in future academy iterations.

With the experience of three successful Technical Academies behind us, and a Technology Team comprised of nine strong graduates and numerous experienced tutors, 7digital is in a stronger position than ever to run a fourth iteration. One might question if we should ever stop, or why we would wait between iterations, or why we might limit the number of apprentices in each cohort, and the answer is quite simple; we do not want to overload the team with apprentices. Having more apprentices will still require effort from teams during the time spent pairing, and diluting the number of senior developers in the team would burden them with additional responsibility. We have discussed the possibility of sharing sessions with other local organisations though, so that we can get more value from each session by teaching their apprentices too.

5 Conclusion

There is a strong feeling at 7digital that the Technical Academy programme has been a success. All of the externally hired apprentices are still with the team, and despite their experience being lower than that of their peers, they contribute at an equivalent level. The team’s gender balance is higher than it was with a notably more relaxed and open atmosphere that promotes a variety of ideas. The mixture of people’s background also contributes to this. Engagement in team development throughout the team has improved, with discussion on career progression, increased knowledge sharing and collaboration between teams.

As more senior developers have grown in their careers they have appreciated being given the chance to pass on their knowledge through the academy. This interesting side effect has increased retention of more experienced team members. Having their knowledge questioned too has surprisingly resulted in a motivation to ensure we are following good practices and promoted learning at all experience levels.

Hiring has been easier; the best example with the replacement of a senior developer with two apprentices in half the time it took to find the previous senior hire. We’ve also hired more women into a variety of roles than previous years.

The existence of this paper is a key example of the benefit the Technical Academy has had on the team and organisation. It is motivating for the team to know that they are well regarded by peers in the community and that they have done something unique to solve a common industry problem. It gives team members a sense of purpose other than satisfying the needs of the organisation so 7digital will definitely be running the programme again in the future.