Overall time allocation

At MUI, we aim to spend our time with:

(4/5) 80% on the KPIs (what are we optimizing for). These KPIs depend on the team, e.g. it could be the number of community contributions, revenue, number of uses, etc.
- Big bets vs. smaller bets. We want to stay mindful of the size of the tasks we work on. The target is to spend 50% of our time on large bets and 50% on smaller bets. Why? See the big rocks idea.
- Planned vs. unplanned. We want to allocate at least 20% of our time to unplanned work as it’s necessary to play and discover unobvious successful ideas.
Implementation. In practice, it means that it’s healthy to spend:
- 50% on the OKRs, which we convert into a Roadmap. OKRs are ultimately about the KPIs above but efforts of large sizes.
- 50% on smaller initiatives to improve the KPIs, or simply to keep them in the green area.
(1/5) 20% on personal objectives & development, feed by feedback in Unleashing potential. This is about investing in the long term.

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