Planning product and engineering at GitLab over long periods of time
- How do we plan product and engineering over long periods of time?
- We have processes and tools in GitLab to plan within one monthly release, and we can somewhat plan over 2 or 3 releases. But when we go beyond that, it becomes difficult.
- How do we plan over quarters, and over even years?
- How do we plan to optimize for GitLab as a whole, and not just for individual product areas or engineering departments. I.e. we cannot easily consider a tradeoff of a particular Discussion product focus with a Platform product focus and understand the impact.
- How do we plan to allow for flexibility in shuffling people within GitLab?
- How do we plan to incorporate hiring? As a constraint and as a lever?
- Chicken and egg problem:
- Product can be aspirational and plan aggressively, but may not reflect engineering capacity.
- If Product under-plans, it could be wasteful plans, since engineering may be able to hire to compensate or tradeoff people to achieve product goals.
- What's the happy equilibrium?
Further out problems
- How do we incorporate market feedback, data in how our initiatives are performing? Measure ROI?
- How to identify and incorporate market trends, strategic planning, high-risk initiatives, and quantify these tradeoffs in the plan?
- How do we incorporate and account for external temporary? Staff augmentation.
- How do we plan to account for other organization goals like finance, marketing, remaining private, when to go public, etc.
Software development methodology
This is GitLab's software development methodology that we do not anticipate changing anytime soon. So the way we solve planning product and engineering at GitLab over long periods of time should be compatible with this methodology. This methodology is also undergoing iteration. But it will likely look like the following:
- The engineering function will be managed by engineering managers. The FE department within engineering has one engineering manager. The BE department has multiple bands, each with an engineering manager.
- Each engineering manager is responsible for managing the people that work in that band (or FE department). And that engineering manager is responsible for managing the capacity/velocity for that band, per iteration (which in GitLab, is a month, and corresponds to the monthly release, which is the milestone in GitLab the product).
- Each engineering manager is responsible to estimate effort required to accomplish work. We will use GitLab weights on GitLab issues to do this.
- Product managers are responsible for communicating relative priorities of requested changes in the product to engineering managers. Product managers work with engineering managers to determine work in scope for each milestone. This process should be more quantitative than the current process, incorporating effort estimation (issue weights) and band capacity.
- Not clear if we will have more rigorous workflow stages (In Dev, QA, etc.).
- Not clear if we will have a more rigorous demo process and a product sign-off / feature assurance process.