Junior developer development plan

High level goals #

Before a junior developer can be promoted, they need to be:

• independently productive
• billable as a developer

Support #

A junior developer has the following direct support:

• a mentor (for development related help and guidance)
• a helper (for dxw / ways of working related help and guidance)
• a line manager (for everything else)

They are also supported by individual teams and the technology team as a whole.

Planned stages #

1. Shadowing a project
2. Creating an internal service
3. Joining a team (short-term)
4. Shadowing support
5. Joining a team (long-term)

Shadowing a project #

Within the first couple of weeks of joining, junior developers starting at dxw, they should start a 4 to 6 week full-time period shadowing an ongoing project each (not the same one), alongside general dxw onboarding. An ideal project would:

• be based where they are
• have 3 or more people in technical roles working on it

One person on the project should be assigned as the point of contact, but the junior developer should shadow a range of team members, focusing on technical roles, but also other members of the team. The goal of this is to give them a low pressure situation to see how dxw does things, and hopefully pick up some good practices.

Creating an internal service #

After shadowing, junior developers should spend 4 weeks working on an internal service. This might be creating a new service (entirely new or a new version), or adding features to an existing one. It should involve the following additional team members / roles as part-time support (possibly drawn from the support rota):

• delivery lead
• developer
• operations engineer
• product owner

This project should be treated in the same way as we do client projects, with a Trello board, sprints, stand ups, planning sessions, retrospectives, and show and tells.

A good candidate project:

• is one built in the stack the Junior Developers are specializing in
• has clear, well-defined user needs
• is brand new or in a clean state with tests for existing features
• has or needs a browser-based interface
• can produce something useful for users in 4 weeks by junior developers

Junior developers should be encouraged to pair with each other and with other developers in the technology team and to use this project to get familiar with dxw’s ways of working, and practice some of the skills they’ll use in the future.

Joining a team (short-term) #

Next, each junior developer should join a client project team for 8 to 10 weeks, unbilled. This team should contain at least 2 full-time technology team members, and will ideally be in the beta phase. The junior developers should be considered full members of the team. They should be expected to be able to pick up well defined routine or simple tasks in the sprint, mostly on their own, but with some support from other developers. The teams should ensure that they have well-shaped tasks set aside for the junior developer to take on, and should be thinking about this in advance of the junior developer joining the project.

Junior developers should do client work for 3 days a week. The remaining 2 days a week should be spent working on anything that comes up as areas to focus on during client work, or any skills they’re unable to exercise on the project.

Shadowing support #

Within the first 4 months of joining dxw, a junior developer should shadow a developer on the support rota for a full support shift. During this time, they should be included in triaging, responding to tickets, and any support development work. They should also pair with the developer on any “filler” work they do during quiet moments.

They should shadow a shift again within the next 4 months, ideally shadowing a different developer. After their second shadowed shift, they should be added to the support rota.

Joining a team (long-term) #

Once a junior developer has spent a decent amount of time working on a client project, as well as working on their own development, they should ideally join a different project team with at least 2 full-time technology team members for 3 days a week for a longer period of time: at least 3 months. This might not always be possible, but priority should be given to creating continuity to allow them to get settled and fully understand the needs of the service they’re working on.

After a month on the project, the team should review how the junior developer is doing on the team, to establish whether they could start to be billed for that work. This review should consider that the value proposition of billing a junior developer is long-term. It may cost the client a little more in the short-term, but that value will be made up as the junior developer progresses and gains familiarity with the service and the team.

It isn’t a requirement that a junior developer be billed at this point, and shouldn’t be considered pressure on the team or junior developer, but more an evaluation of how much value they’re delivering for the client. This should be repeated every 4-6 weeks, so we can ensure that their continued progression is properly recognized.

Last updated: 9 May 2023 (history)