Add "Work on your first Project" section to onboarding task list

darylhedley commented 2 years ago

The issue template should contain:

[ ] A task for the buddy to identify a first project for the new engineer to work on. The buddy will lead this project, and the new engineer will participate.
[ ] A task for the new engineer to read some linked-to documentation about breaking down larger tasks at the project level
[ ] A task for the new engineer to read some linked-to documentation about cycle development
[ ] A task for the new engineer to re-read our engineering values again (and the task list should explain why they're being asked to read these values yet again: what parts of the values apply to how we do projects)
[ ] A task for the new engineer to read some linked-to documentation about where work comes from
[ ] A task for the new engineer to read some linked-to documentation about initiatives & projects
[ ] A task for the new engineer to read some linked-to documentation about tracking outcomes
[ ] A task for the new engineer to read some linked-to documentation about what to do during downtime/being blocked
[ ] A task for the new engineer to check off once their first project cycle has ended

darylhedley commented 2 years ago

Buddy is partnered with new Engineer for this Project

darylhedley commented 2 years ago

Buddy needs to pick the right Project

seanh commented 2 years ago

[ ] @darylhedley to add links to the various bits of documentation that're needed (see task list above), apparently much of this documentation already exists in Notion
[x] ~~@seanh to add links to old documentation about breaking down larger tasks and incremental/agile delivery~~ (I've added a comment below with some links. We might be able to get away with just reusing these?)
[ ] @seanh to create the issue template, once we've collected all the links that it needs

seanh commented 2 years ago

Here's some old docs that're relevant to the first item (breaking down larger tasks):

Features of FTv2 (This is an old document about "feature teams", which is a way that we organised ourselves in the past. It's mostly about agile incremental delivery, key quote: we should strive to build a working product with very minimal features, then add features until we have something that satisfies the business need. These features should almost always be released to end-users as we go.

Unfortunately there are some things said in this document that I don't think apply anymore today. For example As much as possible, the entire team focuses on solving the same problem/implementing the same feature and references to sprint boards, 2-week increments, and other things that we don't use anymore.

Maybe we can instead link directly to the third-party blog post that the above post links to? Making sense of MVP (Minimum Viable Product) – and why I prefer Earliest Testable/Usable/Lovable? It's quite long.
The book The Nature of Software Development was the inspiration for the initial discussions that led to the "feature teams" document above. It's a great little book on agile, incremental product delivery. Only 150 small pages! But maybe even a small book is too big to link to

seanh commented 2 years ago

Does your solution solve the right problem? from the Intercom blog is an excellent post that I think we might want to get engineers to read at this stage

seanh commented 2 years ago

hypothesis / onboarding