Our most recent (and motivated!) undergrad intern, Robert Gordan (Harvard ‘18), shares his experience as an engineering intern at Owler.
(Are you a driven self-starter who wants to know what it’s like working for a startup? Email email@example.com for more information.)
“Your paper examining societal trends in 16th century Italy through Baroque art is due the 26th at 5:00 pm. The paper should be 8-10 pages in length double-spaced, Times New Roman 12 pt font. It must follow MLA citation format. A minimum of 7 sources, with at least 5 print, is required.”
Most of us have seen a similar tagline attached to assignments throughout middle school, high school, and college. Projects vary in scope and complexity of topic, as well as in expectations of quality level, but the format remains the same. We know what to do, how to do it (in excruciating detail), and a hard date by which to finish it. The ‘why?’ remains quietly unaddressed, because knowing the purpose and motivation of a project is irrelevant when all its details are so clearly codified. Unfortunately, the “real world” irreverently upends this paradigm of structured tasks.
My first project as an intern at Owler involved estimating the size and fill rates of our competitors’ datasets, in order to have a baseline by which to measure our own dataset. Uncomfortable with estimation, I searched excessively for exact figures that were nowhere to be had. I constantly went back to Tim (Director of Product) empty-handed, asking clarifying questions despite the task’s simplicity. Having spent years working on clearly laid out assignments, the slightest whiff of ambiguity overwhelmed me. Work in the real world, as I quickly learned, is often defined by the worker, not by detailed formatting instructions. Successfully navigating the ambiguity that invariably accompanies real work is crucial for productivity. We all know how to analyze structured information, but dealing with the lack of it can be just as important. This involves thinking critically about the purpose of a task, rather than its precise details; perhaps there are multiple ways to address the issue. In the case of my first task, Tim eventually prodded me to rethink the problem. If our goal was to measure our success in database size and fill rates, perhaps I could estimate our ideal database size (all companies with websites) and a competitive size and fill rates (distilled from the 10 competitors for which I had individually sparse information). This unstructured flexibility with regard to my projects, originally unnerving, came to feel empowering. I decided what my tasks entailed and how I would work on them.
In the business world, this sort of initiative and responsibility is given by necessity to each employee, and even interns. The problems out in the wild aren’t neat and the answers aren’t either. Oftentimes it’s not necessarily true that the question associated with the problem is even a worthwhile one. You can do utterly brilliant and completely useless work; the two aren’t mutually exclusive. In a large company I imagine that a common recourse in such a situation would be to obfuscate and portray the useless as useful. In a startup there’s no one to fool but yourself, and you have to go back to the drawing board and reframe the problem. Ideally, this scenario never happens at all, because you think deeply about the broader issue and how to approach it before you start doing the legwork.
Ambiguity and the need for awareness of the work at hand and its context are constants across the corporate world, for organizations of all sizes. But at startups, the dynamic expands to an entirely different dimension. Not only do you have to define how you work on individual tasks, you often have to define your very role. Because startups are smaller, you’re constantly in contact with all parts of the organization, and your work reflects that. You have the opportunity, as an engineer, to think about and influence the direction of the product, or as a marketer, to write code for SEO purposes. That’s how I found myself, as a product intern, mapping out the ideal workflow for a webpage, handling outreach to users for a survey, conducting market research, and writing prototype code.
That fundamental power to define your own work can be overwhelming; sometimes it really is easier to know exactly what you’re supposed to do. It can be reassuring to have a straightforward, rote task handed to you, and know that as long as you put in a given amount of work, you’re sure to succeed. When you own the entire process — the formulation of the problem and the implementation of the solution — that guarantee evaporates. It’s disorienting, but the sense of pride and satisfaction that you get from your work as a result more than compensates this loss. As I write this, I’m watching the competitor graph algorithm, which has been my capstone project, repeatedly fall just short of the bar for inclusion into the live Owler product. It sucks. But I owned it, and I know that because I’m glad I did it, and not just glad I’m done.
Robert (in back!) with the India team during his two-week visit to Coimbatore.