Recently one of our team leaders presented me with the following question:
"What can I do to challenge my developers from a technical point of view, outside of the day to day features scope".
We've all been there before, the routine takes over our day. A feature is followed up by another feature and another feature, leaving us out of breath, and worse - it can worn us out.
As a team leader, you can find additional challenges for your developers, helping them to keep sharp and fresh.
I would like to share with you a couple of ideas we came up with in and you are welcome to add more of your own.
Foreign exchange program
When I started my journey in the software development world, every six months my team leader moved me to a different team for a couple of sprints. At the time it made no sense to me. Moving to a new team seemed "wasteful", since you need ramp up time when you encounter a new domain.
Looking back, I think it was the best learning experience I have ever had.
As time passed by, I always find myself asking tasks from different teams and sometimes moving to a another domain for a short time, to learn and experience something different.
Moving a developer, even temporarily, to a new team, brings diversity, allows her to experience and understand more areas across the system and also boost interest in the product as a whole.
Working with new and interesting people, not only developers - also product owners, is always a great learning experience for both the developer and the team, expanding everyone's horizon with new ideas and techniques.
Champion of a technology
Every system is composed from various technologies - from data technologies like ElasticSearch and MongoDB to program languages. Even if you define your developers as full stack developers, being an expert in every technology is simply unrealistic.
You can encourage developers to take ownership of one or more technologies, challenging them to learn deeper aspects and layers.
Understanding the technology in depth, gives the developer a different point of view for designs related to this technology, change usage paradigms and also can make the developer the "go to guy", boosting him to the next level.
As a team leader, if you decide together which technology, you can direct relevant features to this technology to your developer's table facilitating this process - giving the developer more support for her growth.
Champion of a component/module
The system is also composed from various components related to specific domains. For example: Seller feeds consumption, Search algorithms, data structuring and more.
These are usually maintained by the teams, or individuals.
You can encourage developers to take upon themselves to learn one or more of these components in depth.
The developer gains broader understanding of complex services and components, learn how processes in the system work and what makes the system as a whole.
By taking a component from outside of the team's scope, you also add a fresh mind that can push these components to new directions, improve them and spreading new ideas among other teams.
At every given time, I'm guessing your R&D is running one or more strategic projects from a technical or product point of view, like: upgrading to the latest framework, replace a frontend technology, setup a new computation grid or data warehouse stack.
Encouraging the developer to join one of these projects is a great chance to work with people he might not have worked with before, exploring new technologies and influence the choices made.
Also, since these are usually high profile, they can expose the developer to different groups and can focus her on delivering results, increasing ownership and accountability.
In the long run, it also guarantees more developers will understand the technical decisions and design of the project, easing its assimilation throughout your R&D.
Each company has its own challenges and flavors.
Matching these with an enthusiastic developer can benefit first and foremost the developers but they also benefit your company's technical level and vision.
If you have more ideas, please share them in the comments or post back