Overall time allocation

At MUI, we aim to spend our time with:

Roadmap

Most of the teams (aim for all) at MUI operate by having a general roadmap, derived from the OKRs, itself derived from the yearly goal, and itself derived from the KPIs.

This roadmap is quarterly based. It lists all the important tasks that the team wants to achieve. Some of this roadmap is shared with the community for transparency & accountability. Examples: https://github.com/orgs/mui/projects/18

Planning

Because the teams don’t use any specific methodology to plan, the teams don't operate on sprints with fixed scopes, where everyone is given a target for the upcoming weeks. Instead, each person fixes their own target.

Engineering

Onboarding

This usually creates a problem for new hires to find the best ways to contribute. In the beginning, before getting used to this way of working, it can be difficult, and new hires can potentially feel overwhelmed with choice or feel like they are not contributing enough.

To avoid this and to provide a healthy environment for the new joiners, the @Manager or the @Tech Lead (in some cases ****the @PM) ****of the team the new joiner must prepare a list of potential small bugs and features that the person can work on first.

In addition to these issues, new joiners should understand that PR reviews are as much part of the contribution process as opening PRs. So new joiners are encouraged to spend time reviewing PRs and engaging in discussions with their peers.

Note:

If the team you are in uses a more strict framework such as Scrum or Kanban then this should not be such a problem as those frameworks have a fixed scope for a given time. In these cases, the new hire is expected to work on whatever the team is committed to delivering in the given timeframe.

Opening PRs vs. reviewing PRs

What’s the ideal time split between writing code and reviewing PRs? This is left to each to decide but reviews should at minimum account for 20% of the time and at maximum 50%.

Community Engineer