The Conflict of Pursuits
Week 56 of Founding Typogram
Hi, I am Wenting. I quit my job at Adobe to build a startup, Typogram, a logo design and editing tool for startup founders. This is my weekly newsletter documenting my journey from the start on Aug 2nd, 2021 till the present.
Hey friends! I hope you are having a fabulous start to October. October is a very inspiring month for creatives. My social media feed is currently filled with various hashtags of creative challenges like:
#Inktober — draw with ink every day
#Witchtober — draw a character in their witch form every day
#OctoBrr — draw an octopus to do various fall-related things every day
Being a creative myself, claiming designer as my primary profession until recently, I am tempted to join the movement and hone my skills. However, due to the intense schedule of Typogram development, I will have to pass this year. This leads to today’s topic — the conflict between the pursuit of a designer/engineer and the pursuit of a startup.
My designer career was mostly spent in big corporate, where my primary self-improvement goal was set around becoming better at my craft. I hone my skill in typography, color theory, design systems, and prototyping to become a well-rounded designer. I always design with perfection as a goal, aiming at design deliverable that is well-organized, thoroughly thought out, and sometimes prototyped with code neatly according to my design spec.
When I designed the Typogram pre-order page back in March, and the brand color step’s UI redesign in Typogram last week, it was out of my old habit to set the bar too high. I spent a long time doing visual study, design research, wireframing, and finessing with countless directions before I committed to designing the real version. It was too time-consuming and slow. While it may be the right approach if I still work at Adobe, it is not fitting for Typogram, a young startup with just two co-founders on the team. My lifelong pursuit of becoming a better designer is conflicting with what a startup like Typogram really needs — fast decision-making, jumping right into the design phase, and then to the next, iterating after launch.
I remember getting into a workplace argument with Greg Veen, the product lead of Adobe Typekit at the time. Before jumping into designing the solution and delivering it within two weeks, I insisted on doing thorough user research first. Greg explained that speaking from his startup experience of co-founding Typekit (before getting acquired by Adobe), he was more inclined to build it, launch it, and then validate it with analytics data afterward. After many years, the memory of this workplace argument came back to me; I realized that I am now on his side. I am having the reversed version of what he experienced — the transition from big corporate to startup and the adjustment that it entailed.
Software engineers have the same conflict of pursuit with the startup they worked for. Good coding practices sometimes do a disservice to a startup; over-engineering is a major example of this. I think my background as a self-taught coder helped me in this regard. Knowing just enough to get by and always picking up new things along the way, I am constantly in “survival mode” when I code, and as a result, I rarely over-engineer anything. I picked the easiest and quickest solution, and don’t hesitate to abandon “good coding practices” for efficiency. Unlike my perfectionist designer profile, my career as a software engineer started with Typogram, and I don’t have the self-seriousness to pursue higher goals in coding than making Typogram functional.
I remember hearing a talk about entrepreneurship where the speaker made a bold point about their startup needing the best product people but not the best QA (quality assurance), and they were saving their best QA contacts for the later stage of their company. The best QA would drag on the development phase and harm the startup with their excellence. They were talking about a similar phenomenon with a slightly different context.
Hear from You
Have you experienced similar conflicts of pursuits between your craft and your organization? How do you cope with it?
❧
See you next week! If you have friends who are interested in founding startups, please consider sharing my newsletter with them!
Great post! I recall our "healthy debate" over user research that time at Adobe years ago. :) I'm actually a strong proponent of user research – I'm in the middle of some for a project right now, in fact. But, yeah, sometimes it makes sense to rely on learning from previous user research and your understanding of your user base and the competitive landscape to move quickly to build and get something in the hands of people in real world contexts, where you can learn directly from them. This can be a delicate balance to strike, of course.
If you would perform one automatic QA test for Typogram, what would it test?