3 ms·
I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan
by cik 19d ago
I tend to apply this to myself, within an organization (as opposed to those who like to generically try it all - fair enough). I've always been an enormous fan of touring the organization. Whether I join as a dev, or an exec, I always make it a point to spend some time with product, with support, and with marketing. It ends up providing me a unique vantage point. I encourage others to do the same, and when I 'control' onboarding, make it part of the process.
It's literally the fastest way to have someone get up to speed with the customer profile and product. They can play with it whilst listening in to support calls (if a thing). They can learn about pain points and "hard edges" that as developers we don't always come across.
- nkapias 18d agoI've experienced that being knowledgeable of the inner workings is a risk of getting dragged into every projects. When scheduling onboarding, I try to enable touring without those drawbacks.
- RugnirViking 18d agoany tips on how to go about such things? its occasionally hard to find excuses to go hang out at the other end of the building and talk to another team I dont know much about as a regular developer
- nkapias 18d agoI usually asked my managers by framing it to their goals, if agreed they would schedule with other managers. It's harder during crunch or when everyone is remote.
- harry8 18d agoAlways have a folder in your hand when visiting other teams in other parts of the office. Print out some code, a few pages of spec, whatever. Just don't go walkabout empty-handed.
- JR1427 18d agoJust send someone in the other team a message saying you're interested in learning more about what they do, and would like to grab a coffee.