Onboarding onto a Technical Product
In a previous post, I wrote about growing the design practice. Some of the points included finding the right project fit and onboarding new team members in a sustainable way. The next few posts are intended to go deeper into that topic and provide more context around onboarding onto a technical product.
For this post, I’m defining a technical product as a product where the majority of terms, concepts, and user workflows for the product are unfamiliar to people without a degree or years of experience in the domain. For example, these could include databases or cloud application platforms.
Crash and burn onboarding
Why is onboarding onto a technical product different from any other product? I’ve noticed that intelligent designers with strong design thinking skills crash and burn when onboarding onto a highly technical product, even with plenty of support from their team and manager. That’s because the traits that have made them successful, like being ambitious, curious, and keen to add value, backfire when not scoped appropriately.
It’s reasonable to feel like you need to know everything when first joining a team. There’s so much to learn and it’s all new and exciting, but it can also become overwhelming. Scattering your focus on all the things means less time and attention on what you need to become productive.
This situation can apply to any product and any domain, but the downside effects of poor onboarding are highlighted and exacerbated in a technical domain space. People can very quickly end up feeling demoralized or worse, penalized because they don’t know the domain enough to make product decisions.
That said, approaching onboarding with a different strategy can help. One such strategy is focusing on a vertical slice of the product.
Focusing on a vertical slice
Generally, features in a product can be grouped based on type of user interaction or functionality it provides. For example, it could be the onboarding stage, the monitoring tools, or the debugging tools. I call these groupings a vertical slice of the product. If it hasn’t been done already, work with your team on determining which is the vertical that needs work and limit the distractions coming from outside that area. Start to become an expert in that vertical slice.
This does two things for you. One, it scopes out your work so that you know where to focus your time and energy. Two, you’ll be better equipped to handle additional complexity if you can build from a solid foundation.
Inevitably, asks will come your way. It’s up to you to ask yourself if effort in the task aligns to the value you or your team will get out of it. During the initial few months of the onboarding stage, remember that investing in yourself will add more value to the team faster than stretching yourself to be of service to the team. The more you’re able to follow and contribute in technical discussions, the more you’ll be able to lead.
Coming soon will be strategy two — Incrementing how much “big picture” complexity is introduced.
