Recently Henrik Joreteg tweeted about the difficulty describing the value he brings to a team when no one particular role encompasses his skillset.
Don't know how to describe the role I play on most projects.
It's some mixture of dev, tech lead, solutions architect, UX design, user advocate, and product manager.
I build products.
Do we have to have to slice that into 10 different roles? Can I just be a product developer?
— Henrik Joreteg (@HenrikJoreteg) March 20, 2019
Henrik isn’t alone here. I find myself struggling with the same thing and I know many others do too. I am what you’d call, for lack of better terminology, a generalist. I can design. I can code. I can do frontend and backend. Postgres? Typefaces? Writing copy? Bring it on! I may not be amazing at all of these things, but I’m competent enough to at least get stuff done. So what am I? A “product developer”?
I guess the label doesn’t really matter. What matters more is being able to explain what the generalist brings to the table. And I think that value can be expressed as three primary capacities.
The Swiss-army knife is great, especially when in survival mode. And let’s face it, early stage startups are often in survival mode.
The generalist can wear many different hats and do what needs to be done. The value of the generalist at the early startup stage is fairly self-evident and probably least in need of explanation.
Much of the expertise in our world is divided amongst specialized experts, and for good reason: to fully understand something we often need to devote resources (our own time and energy) at the expense of other things. We can’t all be Leonardo Da Vinci.
But this comes at a cost. Our categories of expertise can be artificially stiffling and limiting. They can result in biases - a sort of myopia brought on by looking at something too close. Stepping back and being able to look at a problem from multiple perspectives can help shed new light on them, and having people with a holistic view can help mediate between people in these areas of expertise.
The same holds true for web and app development. Consider the value in having a designer who can code:
On a practical level, a designer who can code has the capacity to communicate with programmers. But more fundamentally, a designer who understands the nature of their medium also understands the potential of that medium — the potential for beauty, expression and achievement, and, equally as important, the potential for ugliness and disaster. It’s analogous to the potter who starts with a conception of a pot — an image based upon an understanding of the medium, with all of its various constraints and possibilities — and is able to execute a vision based upon this understanding.
Let’s bring this back to the web. Code is, in many important respects, design. The symptoms of bad code can directly affect the user experience in obvious ways. But design also comes with a cost in terms of programming hours, performance, and added complexity which limits your capacity to change and evolve as a platform. Kevin Gates makes this point when he says that we should ”[t]hink of code complexity as the opposite of a force multiplier. It’s a force diminisher. It imposes a tax on everything you might want to do with your product in the future.” Introducing features comes with a complexity cost. And introducing features costs time and money. Again, as Kevin writes, ”[i]deas are cheap and disposable; code is expensive and persistent.”
Let’s not (sadly) forget about marketing and growth. Good design isn’t just about creating intuitive ux patterns, typefaces and beautiful gradients. It’s about designing a product that people will buy. You typically have your growth team and your product team, often with subtly incompatible aims, with one of these teams winning out (yeah, the growth team) resulting in something like this:
Wait, why did I come to this site again? pic.twitter.com/9rHce97Nvu
— Nicholas C. Zakas (@slicknet) February 18, 2019
Yeah, this is kinda horrible and can be avoided with good communication between teams. The generalist can help mediate these subtly incongruous goals while creating a solution that benefits both product and user.
This is how I’d explain my value. Are you a generalist? How would you explain your value? What should we call ourselves? Is it time we brought back the “Web Master”?
(This is an article posted to my blog at benmcmahen.com. You can read it online by clicking here.)