My experience onboarding to an in-flight software project
I've been working in a new space lately. There are more than 30 teams working on all sorts of different things. Web, mobile. Front-end, back-end. New products, new features. Ruby, Python, Javascript, Go, Swift, Java, lots of Java.
Questions that I had
- Was there an Inception for this project? Where are the artifacts?
- Are there Personas for this project?
- Is there a system diagram for this project?
- Is there a data diagram for this project?
- Are there workflows (Use Cases) or mockups?
Thoughts
- Have you considered adding a designer to this team?
- How do you onboard new folks in a less-than-trivial domain?
When assessing the priority of features, build features that provide business value. Should we build X? is always a decision that has to be made. How do you begin to approach that decision?
I'm a software developer, so I think about how to build software and what software to build.
David Bland and Andi Plantenberg have instilled in me to always ask: is it Feasible?Usable? Desirable? as a good way to scope a discrete piece of work.
As an Engineer, it is tempting to build for scale. Rather, as a Product Manager, I want to build for depth of experience. I seek to understand how user's engage and what they expect from a specific software tool that is being developed.
These notes are a work-in-progress, and they outline what has often been my experience onboarding to new software projects - what is the state of this project right now? What applicable context can help me understand how to steer the project in accordance with its natural and desired trajectories?
