I'm Co-Founder & CTO of BlockAvenue. , connect with me, or subscribe.

Mentoring & Apprenticeship for Software Engineers

blacksmith glassblower software engineer mentoring apprentice

What we software engineers (and designers) do is very creative and, in general, best learned through experience. Computer science and color theory can be groked from a book but client communication, handling conflict, and other less tangible disciplines are gained in the trenches. Learning on your own is slow and error-prone; you can miss out on stuff or learn something wrong based on the project work you get or who you happen to work with.

I view the apprenticeship mentoring model for software engineers (as with a blacksmith, glass blower, ceramics or any of the high-skill, difficult to master traditional crafts) to be the best way of accelerating growth, increasing retention, and creating the kind team your organization really needs. What follows is my approach to such an apprenticeship model that works in both client services and product teams.

For what it’s worth, I have a good bit of experience with this: I was head of engineering during company growth from 25 to 50 (with a corresponding growth in revenues and projects). This meant going from an engineering team of 6 to an internal team of 15-20 and an off-shore team of about 10. It also required increasing the number of technical project leads from 1 (me) to 5 or 6 through direct mentoring. Those tech leads then themselves became mentors to the new hires as we grew. In my consulting work, I worked with early stage startups, such as ByteLight, to design and execute hiring as well as plan and stabilize development teams for long-term product development.

Why Apprenticeship Makes Sense

Apprenticeship takes effort and dedication and does not come naturally to most individuals or organizations. It requires time and effort that may need to be justified:

  • It accelerates learning on the part of the apprentice in technical and non-technical skills including everything from code quality and language nuances to object design to client communication.
  • It enables molding junior folks into what you need them to be. With a strong mentor model, you can widen your hiring field since you can bring on candidates that can grow more quickly into something really useful to the business. Associates without mentoring can become a big hiring and project risk and kind of a “boat anchor” that weighs more senior folks down instead of providing valuable support and fresh thinking.
  • It challenges the mentor to grow as well. Mentoring grows technical, communication, and management skills beyond the limits of normal project work and open up opportunities for getting your people to act like owners.
  • It encourages dialog and thought around actively managing their careers. This is good for both the team and management; when growth happens from the bottom up it’s healthier and reduces the overhead load on management.

Success Factors

There are a few factors that heavily influence the success of mentoring.

Clearly Defined Roles & Goals

The mentor and the apprentice should both understand each others roles. It should be something verbally stated to remove any awkwardness or barriers. The mentor is responsible for providing not only support (general advice, answering questions, etc.) but also constructive criticism and recognition for good work. Both of these last two are critical to balance each other out and create a good relationship between mentor and apprentice. The apprentice is responsible to raise their hand when they need help and be pro-active about it. They should be actively looking for areas where they feel weak and pull in the mentor.

Mentoring needs to be clearly defined between the mentor and apprentice. The more ambiguity and awkwardness there is, the more that becomes a barrier to successful mentoring.

Mentoring should be seen as a largely voluntary responsibility. They need to be self-motivated and see themselves in the role.


Proximity, or lack thereof, is a deal breaker. I prefer that mentor and apprentice be “attached at the hip”. It’s important that they feel very comfortable with each other and have a meaningful context that provides fodder for mentoring. They should talk often, even informally, so that there is a consistent dialog. Ideally the apprentice should sit near the mentor so that when a teaching moment arises the barrier to making that happen is as low as possible. Having to go find the mentor and interrupt them could be a high barrier, especially for junior folks.

They need to have something they both know so they can talk about it. Having to context switch from project work to a side project could be a significant barrier. Project work usually provides the best “fodder” for mentoring. People are already thinking about it and engaged. It naturally provides many “teaching moments” in a way that manufactured mentoring throughout side projects does not.

In either case, if you don’t make time to be working on things in pairs, the mentoring won’t really happen. Mentorship is prohibitively disruptive when it’s a constant interruption to “real” work and involves at least two mental context switches. It requires some dedication to a schedule to make it happen effectively.

This kind of thing can work without being spatially proximate. Pair programming through screenshares and audio chat can be an effective method of working through problems and passing along knowledge. You sometimes lose the non-verbal communications, i.e., being able to read the apprentice’s general level of frustration, but for many folks it can work. With remote team members working from home, knowing how to be effective as a mentor remotely can be challenging but critical. There are a lot of tools at your disposal to make this work; use every one of them.

Whether remote or not, make time for low-intensity touch points. Go grab a coffee or go out to lunch. This helps highlight issues you might be having that otherwise don’t get communicated.

Support for Mentors

Mentoring is not a natural thing for most tech leads. It’s a skill that needs to be developed. They should have someone that can provide support. This could be someone with some experience in it or even other mentors.

Acknowledgment that the mentoring investment is worth it needs to start at the top. Management support in the form of explicit goals, advice, time, and resources is critical.

Every Apprentice is Different

Apprentice experience level, skill level, interests, and personality and some of the factors requiring that each mentoring situation be customized to the mentor and apprentice in order to be most affective. For instance, with one apprentice they might be really strong code wise and need to focus on client skills and another might be totally different. It’s a balance of what that person needs and what the project context provides opportunity for.

Doing It

The Kickoff

Any apprenticeship should start with a structured meeting between the mentor, the apprentice, and whoever is heading up the apprenticeship program. The meeting should cover:

  • What mentoring is and why you are doing it (answer: because it makes you better, will make you more successful in your career, will help you enjoy and be more successful in your projects, and helps the business as it grows)
  • Where they are now in their skills and where they want to go
  • What everyone wants to get out of it
  • How it’s going to work: project set up, logistics, communication, going out to lunch together, etc

Mentors must know that the hour / day / week they would spend to do the best job of training / pairing with an apprentice is working towards some series of agreed upon goals. Knowing those goals would allow them to make the judgment call whether teaching or doing are the correct goals at any given point.

On the Same Project

In this model, mentor and apprentice are on the same project. This is usually a situation where the mentor is the project tech lead and delegates work. They sit near each other so the apprentice can ask questions and get help easily. The mentor frequently checks quality of work and provides feedback (for instance, code review a feature branch before merge).

The mentor should look for opportunities to push the apprentice outside their comfort zone using project work. Give them responsibility on something that is just outside their current abilities and has real consequences. This could be technical such as building a large feature, researching a technology, designing an object model or non-technical such as leading a client meeting, writing a spec, estimating something, or leading some aspect of the project process.


This requires projects that can support both the mentor and the apprentice in terms of project budget and having work that can be affectively delegated.

One of the biggest challenges is in the staffing plan for projects. Not all projects will be a fit for their respective skill sets. Many teams don’t have a lot of flexibility in mixing and matching project teams for an ideal makeup and staff largely based on current availability. This could be a source of friction to the process and one you’ll need to be diligent about.

It also can change how you sell projects as you need to plan for mentorship hours and some inefficiencies, especially in the work done by the apprentice: all growth requires some degree of failure. Re-examine your task estimates for things that may be delegated to the apprentice.

Be careful to strike a balance between the cost of ramping up apprentice resources and the cost of delivering project features. Budgets may creep to account for “apprentice time” to a point where it effects project budget significantly if left unchecked. Crunch-time pressures also present a challenge to on-project apprenticeship.

One model is to attach the mentor / apprentice and then look for projects for the pair. The opposite approach is also possible in order to lower the resource challenges and budget waste; to find a project fit for the apprentice and then start mentorship with the tech lead on that project. I’m making a big assumption here that apprentices are not put on projects by themselves; having them on a project by themselves can be really risky.

On Different Projects

In this model, mentor and apprentice are on different projects but maintain a relationship across projects. They need something they can use as mentor-fodder:

  • The project the apprentice is on. This requires the mentor to stay up on it enough to look for opportunities to mentor with it.
  • A side project the apprentice is passionate about. The mentor would also have to agree that the side project provided the right opportunity for growth (it’s likely something that encourages technical growth).

Using a real project helps the apprentice be more passionate / engaged / successful in their project (which is more valuable to the business than a side project). It also provides scenarios and challenges to the apprentice that a side project doesn’t such as client communication and project process. Working on a side project requires time and energy both of which are usually limited during project work.

These two models could be mixed in order to provide more resourcing options. For instance, you could start in the first model and then, as resource allocation demands, change to the second model to keep up the relationship between mentor / apprentice.

Bootcamp style projects, a non-billable project geared towards getting new recruits ramped up on our practices, can work in the right context but require a fair bit of management, mentorship, and coordination outside of billable work. The “shadow” apprenticeship model on real billable work may be more practical for most organizations.

Resource Allocation & Project Pressures

Each project has it’s particulars and, just as you consider the situation for who would be the best fit as a team, consider whether it’s a fit for mentoring; the risk level and what you could get out of it. It could be very tough to mentor on a “heads down” project but there may be teaching opportunities there as well. In fact, a heads down project may be just the kind of catalyst for growth in a more senior person where it wouldn’t be a fit for apprenticeship of younger staff. The decision to go heads down and crank (and how to do and handle that) is, in itself, something a junior person could learn. Learning to manage project pace and intensity is a valuable skill.

Mentorship is a distraction. It is a context switch and that’s okay. Teaching and doing are very different goals and, at any given moment, one goal or the other should be the highest priority. If it’s crunch time, and delivering the product is the highest priority, you might put teaching on the back burner and focus on doing good work quickly. But at other times you would prioritize training and acknowledge the slower production time in favor of allowing the apprentice to work at his own pace.

The ratio of mentoring to project time could be estimated (and should be capped) but likely won’t be consistent. Mentoring with the context of a project (such as code reviews) can be a really effective method of upping quality, lowering risk, and lowing cost so it doesn’t always need to be seen as waste or overhead. For instance, code reviews are an excellent way of teaching while catching bugs before they make it into production code.

Mentoring is much less of a distraction if it’s in the context of normal project work. If two people are jogging together, it’s much more natural for one person to teach the other person better jogging form while they keep running. It would be highly disruptive if you were jogging and suddenly one of you said “now stop so I can show you how to do good pushups”.

Expect mentoring to need case-by-case consideration with resourcing to ensure that it’s done affectively without significantly negatively effecting project budget, quality, or overall success. Mentoring (and having junior folks in general) does take investment on the part of the company but that investment should be as known and controlled as possible.

The End Game: Make the Mentor Redundant

A mentor should, in most cases, be growing the apprentice in whatever way is necessary that the apprentice could eventually do their job. In many cases, this actually happens: the mentor starts as the project lead and by the end of the project the apprentice has taken the reins. A good example of this is a new project that has a heavy, green field development phase followed by a slower maintenance phase. The first provides an opportunity for the apprentice to lead the process, the product, and the technical machinery and possibly take the lead for the maintenance phase. This will be a challenge for them but is much simpler than green field development.

This isn’t always the case; you could also have an end game of an apprentice simply getting better at something specific. But, in general, you should be growing them to be well-rounded contributors. This typically is better for them and for the business.

Growth is Not Just for Apprentices

A well-rounded view of growth affords everyone opportunities for growth and improvement. For more senior folks, this means they don’t need apprenticeship but rather support in other ways from their peers and management. In many ways, growing senior folks is more difficult than apprenticeship since, as people grow, the challenges they need to encounter in order to keep them growing become very specific to that person.

Your Mileage May Vary

The form that mentorship takes (or should take) can vary significantly by the team and individual. What has and hasn’t worked for you? If you were without mentoring, is it something you could have benefited from?