As engineering leaders and technology managers, there is one thing you know for sure, people are the most important part of any engineering teams. Yes, technology is important, yes, reliability is important, yes, delivering value to customers with speed is important, but guess who are making all these happen — developers.

Whenever managers and leaders sit down together to discuss about their people, a common thread arises around the need for more opportunities that would enable developers with great potential to leap forward. It’s also aligned with the many researches that we have all seen from top consulting firms like McKinsey and PwC; career growth is one of the most effective ways to keep employees engaged.

I can hear you thinking, ain’t great developers supposed to identify growth opportunities for themselves? While that’d always be ideal, not everyone is naturally driven and not everyone is equipped to do so. Besides, I’d like to think that it is the responsibility and privilege of leaders to help their people grow and achieve great things.

In this article, I’ll be sharing a few initiatives that you can run for your engineering teams throughout the year to empower developers to take charge of their growth. Some of them may be straight forward, but they are often overlooked in ambitious and big organisations where there is always a constant pressure to deliver and achieve business goals.

1. Career planning workshop

Failing to plan is planning to fail, and this is no exception when it comes to one’s career.
But just how does one plan their career in this ever-changing world of technology and in a dynamic environment so they can succeed and make progress without limiting their options?

While some developers are good at knowing what they want and how to get it, most developers, especially those in their early career are not even sure what they want, or worse, what is expected of them.
Therefore, the aim of the workshop is to introduce a framework for making medium-term career plans and setting actionable goals that will help developers make progress in their career. At the end of the workshop, developers will be able to create an actionable development plan. This plan consists of tasks that need to be accomplished in order to achieve their medium term career goal.
Knowing how to plan your career is an important life skill that will enable developers to take charge to their own career. For an organisation, providing such workshop is a low investment which could possibly result in high returns.

2. Current job level + 1 apprenticeship

Does your junior developer knows what’s expected of them at the next level? In other words, would they know when they are ready for their next promotion or more importantly, how to get themsleves ready for their next promotion by working on their gaps? Likewise, does a senior developer know how they could become a principal developer? Knowing what the next level requires is very important in making sure high-performing individuals are constantly motivated and engaged to do their best.
This apprenticeship requires a developer at the Current Job Level to shadow and spend a certain percentage of their time, say 50%, with another developer at the next level (Current Job Level + 1). Because this is an expensive initiative in terms of time and effort, you’d probably only want to offer the Apprenticeship to high-performing individuals.

3. Secondment within another team in a different job family

Having a in-depth knowledge in a technology stack is great, but as a developer progresses in their career and takes on more responsibilities, being able to understand other job functions and collaborate with people from multiple disciplines become more and more important. After all, a developer who has a breath of knowledge on adjacent disciplines such as product management, data analytics, customer support, design, marketing, etc is more likely to be able to make better trade off decisions when building complex software than the one who has never been exposed to other areas outside of their primary domain.

4. Team swap

If your engineering department has more than a single digit number of developers, you’re likely to have a few delivery teams. Some engineering departments follow the popular Spotify model where there are a number of cross-functional squads with clear responsibilities. Others follow the good old scrum team structure with many scrum teams and each team consisting of a development team, a scrum master and a product owner. While I understand and agree with the concept of having stable teams, if a developer in a team has been part of the team for more than a few years and they have become too comfortable and their career growth has become stagnant, it’s time to move that developer into a different team. This also provides an opportunity for other developers in the team to step up. Even for a medium-sized team of ten people, I have witnessed how the team dynamics could change with one developer leaving and another developer coming in. If planned well, a team swap provides a win-win-win situation; a growth opportunity for the developers, a different dynamics for the teams and a win for the organisation.

5. Stretch opportunities

I have worked with some managers who say if you have got a challenging project, they’d just give it to the developer who is the most capable and most reliable. However, the problem with this approach is that the top 10% of the developers will always be the go-to people and such organisations and teams can’t scale. To avoid this, my recommendation is to give stretch opportunities to every developer, but consider the impact—for example, start by giving non-superstars developers projects that will stretch them but if they fail terribly, it is not going to be catastrophe. They may fail the first time, they may even fail the second time, but with time and experience, they will be able to tackle challenging projects just as well as those top 10% of the developers. As managers, document a list of these opportunities among yourselves and keep them updated. Opportunities are everywhere, but writing them down and sharing them with others make sure it goes beyond just a good intent.

6. Task force for a special project

Do you have a project that with clear goals and requirements? Perhaps a lift and shift project where you create a micro service to replace the same functionality that is available in monolith, or upgrade your codebase from one programming framework to another, eg, rewriting your app from angularjs to reactjs. Or perhaps, a new product feature or a complete redesign of look and feel and therefore, rewriting all front end UI code. These kinds of project benefit from having a dedicated task force with a great focus. It’s also a great opportunity for developers to really focus on technical details and become the go-to person and domain expert for the technology that was used.

Here is a great quote to end this article.

Change is inevitable. Growth is intentional.

---

If you enjoyed this article, you might like to check out my latest book on engineering management. It's a practical guide for engineering managers at tech companies.

The Engineering Manager’s How-to Guide is very targeted for engineering managers, and in this book, you won’t find generic advice like having regular 1:1’s, giving feedback, etc. Yes, those things are absolutely important, but they are not specific to an engineering manager’s role. It’s my goal to make sure this book provides a concise and actionable guide for engineering managers, the specific and niche content for engineering managers that you won’t find in other leadership and management books.