Principles

Aside from objective skills and work experience, I genuinely believe that for a group of people to work well, the ground-level principles must be, at least, in rough sync. In agreement with what Henry James Garrett argues in "This Book Will Make You Kinder", (what a sweet read, by the way) we need to lay out our fundamental root beliefs explicitly.

In doing what I preach, here are a few of the work-oriented principles that have guided me through opportunities and challenges, helping me to position myself in this industry today.

Be a generalist

I genuinely believe that the trend of very specific roles we've been seeing over the past few years is slowly falling through the cracks. It makes the inherently fluid and multi-disciplinary process of building products waterfall-ish, which inhibits creative discussion, creates overwhelming dependencies, and reinforces not helpful authority hierarchies.

Products built by designers able to own an entire discovery-to-delivery process, without restricting themselves to get into topics x or y simply because it's "not their role", have a much higher chance of being high quality. Teams who employ very detailed roles (e.g., "UX Strategist" and "product designer"; "software architect" and "software engineer"; etc.) lose a relatively significant amount of time discussing the conceptual differences between these made-up ramifications instead of encouraging individuals to engage in the creative process end-to-end.

As with anything, there's nuance. It's somewhat bad and impractical to answer multiple different topics with the same level of confidence. So, within a certain field, generalism thrives a lot－be it in product development as a whole (software, design, product), music (multi-instrumentalist musicians), etc.

Seek self-sufficiency

There's an important gotcha to this one, which is that we are simply not truly self-sufficient. Period. We're deeply social animals, and we depend on others to exist. However, weirdly, the pursuit of it, despite its inherent impossibility, enables so many positive outcomes:

• It makes us try really hard before reaching out for help. It encourages us to break out of our comfort zone and/or assigned role to accomplish a task by ourselves.
• It helps expand our generalism, a positive thing, as argued above.
• It reduces depencencies.
• It helps us value even more someone else's skills as we realize how much we need their help + how much effort they've put into conquering it. Tangentially, it shortens our ego and exercises our humbleness.

Thus, seeking self-sufficiency is a tool to grow personally, to better empathize, and more frequently recognize how others enable us to live and do the things we want to do.

Be the conductor

Instead of owning something－a solution, a product, or a process－I'd rather conduct it. It can seem like just a slight rephrasing, but it honestly has had a significant impact on the way I view the product development process.

The practice of seeing yourself as a conductor is purely a tool to help folks that are working and collaborating with you to feel and share the often-said "ownership". It fosters an environment where folks engage because they really care about creating something that will be representative of who they are. Honestly, I have frequently felt that the concept of ownership is just too hard to allow a feeling like that－it usually works to separate people instead of bringing them together.

Don't get me wrong, I know that ownership is critical, and I absolutely have learned the hard way that the lack of it creates a lot of trouble. The "be a conductor" reframing still acknowledges that while making room for shared ownership of collectively developed solutions.