Side Projects for Engineering Teams
An important part of engineering leadership, specifically people leadership, is providing opportunities for team members to remain interested and engaged. While it is inevitable that people will leave, it is good to ensure that they will some day look back at the time spent in the team as being interesting and advancing for their career. Among other things, this can include introducing 10-20% project time for developers to work on side-projects[1] not necessarily directly related to any product road-map deliverables, but of course related to the company’s technology ecosystem. This provides a good opportunity for engineers to work on some interesting things outside of the core deliverables and help keep them engaged. It is however necessary to put some structure around this with requirements such as the side-project needing proper definition, tracking time spent, prior approval, etc. This may be accomplished using these guidelines:
- Developers can spend 10% of their time every sprint working on side projects not directly related to any sprint or quarterly deliverables.
- Each side project much have some definition and deliverable pre-defined.
- The side-project must be related to the company’s technology ecosystem, or should have the potential to be so. For example, it could be doing research into a new technology that could be integrated into the platform. This new technology could be something like a ML library, a new tool for data analysis or even implementing a better algorithm. It could also be building some interesting new feature or application on top of the platform.
- The side project will need to have checkpoints. Ideally it should not take more than a quarter, but if it does, there should be some concrete deliverable at the end of the quarter as a quarterly checkpoint.
- At the end of the project, the developer would be expected to do a presentation to the immediate org, and very likely, a L&L for the engineering department. For longer running projects, this can also be done as part of the quarterly checkpoint.
- More than one developer can collaborate on a side project at the same time. Group work is encouraged.
- Each side project should have some progress at the end of the sprint. The developer(s) working on the project should be able to quantify this progress with the lead developer from his/her team and/or the engineering manager.
- Time spent on side projects will be tracked on the board using tickets, which will be labelled appropriately.
- Developers will have to get prior approval from the Engineering Manager to start working on a side project. Approval will be based on the developer’s current productivity, definition and deliverables of the project, engineering and product priorities, and current business needs.
If I am not mistaken, this side project time was first introduced by Google back in the day. ↩︎