March 24, 2019
Recently Henrik Joreteg tweeted about the difficulty describing his role on a project when no one particular label encompasses his skillset.
Don't know how to describe the role I play on most projects.
— Henrik Joreteg (@HenrikJoreteg) March 20, 2019
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 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 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.
The generalist demonstrates the capacity to learn many disparate skillsets which, within the tech world, is important because technology is always changing. (Remember when there was a hot new Javascript library every 4 months?) Chances are you’ve been put into a situation where you’ve had to learn something out of necessity, and, whether through divine inspiration or repeated banging of head against wall, you’ve managed to at least kludge something together that gets the job done. We, the generalists, are the masters of kludge. But once you kludge enough, you learn to build something that not only works, but leaves you with a small sense of pride.
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) to some things at the expense of other things. We can’t all be Aristotle or 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 mistakes. 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.”
My point here is that having knowledge of coding and design is beneficial to both endeavours precisely because of their entwined relation to one another in the larger task of building an app. The generalist has the benefit of a built-in understanding of that relationship.
Let’s not 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
This is a pretty bad user experience and is likely a byproduct of having teams not properly communicating with eachother. 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 as a generalist. Are you a generalist? How would you explain your value? What should we call ourselves? Is it time we brought back the “Web Master”?