Why a spreadsheet stops working

If you’re like a lot of people, once you start a job search you’ll want to keep track of what’s going on. Like many other people, you’ll probably start with a spreadsheet. And why not?! Company, role, date applied, status. Five columns, twenty rows, easy setup, sorting, find and replace: You’re ready to rock.

An amazing value to effort ratio. There’s a reason people have been using these for 40+ years. A spreadsheet is a pretty good place to start with this sort of project. As your project expands however, you’re likely to run into a few problems which will likely get worse over time.

The small problem: a modest snowball effect

If you’re just tracking one thing, like applications from our example above, the sheet gets gradually less pleasant as it grows. Scrolling gets longer. Sorting and re-sorting get just a bit trickier. Finding a row takes a beat more. It just costs a little more attention every week. Then a little more, then more and more… etc. You’ve got a snowball effect on your hands.

This may not be a problem for you, depending on your needs and how you respond. Maybe you delete entries as they are rejected or stale, your search pool is very small, or perhaps your job hunting cycle is not that long. In keeping with the snowball metaphor: the angle of the slope your snowball is on, will have a big effect on how much of a problem it is for you.

There are conditions where the spreadsheet is managable in this scenario, but others where it gets out of hand.

The big problem: the “invasive frog” effect

Let’s say you expand your scope beyond applications. Inspired by the multiple tabs and sheets available in your spreadsheet application you start tracking more. And you have lots you can track!

First it’s applications. Then you need to remember who you talked to, so now there’s a contacts sheet. Then companies, because a company isn’t the same as an application. You might apply twice. Or get referred by someone who works there. Or want to note that they went through layoffs in March. Then interactions: when you emailed, when they replied, what got said. Then documents, because you’re tailoring the resume per application and you need to know which version went where.

Each new sheet doesn’t add work in proportion to itself. It adds work in proportion to everything it touches. A contact belongs to a company and shows up in several interactions, one of which led to an application, which used a specific resume version. Update one fact and you’re finding and editing it in four places, and keeping those four consistent is a job you didn’t sign up for.

To use a new metaphor: you’ve got invasive frogs on your island. Unnoticed, at first. Then they multiply, and multiply and multiply.., etc. Unlike the snowball however, you’re vastly less likely to tame their growth. They will overwhelm you, it’s just a matter of when.

It’s at this point where a spreadsheet can become as much of a hinderance as a tool.

You may be thinking at me now: “But Matt, come on! You can make linked entries in spreadsheets! And slay your frogs!” It is possible, but depending on your level of skill it may be beyond your reach. Futher, I’d still argue that the links can overwhelm you, even if you do have the skill to link as your complexity is still growing.

A side problem, or solution: “How good at spreadsheets are you truly?!?”

Spreadsheet UI is optimized for grids of numbers. That said, you can get very good at spreadsheet entry. Keyboard shortcuts, data validation, named ranges. I did. It cuts the friction a lot. And again, depending on your issue this skill may be enough to solve your problems.

Even so, the interface is not built for entering your custom record with fifteen fields, half of which reference other records. Software built for the job can be built for fast entry: the right field focused, sensible defaults, the relationship picked off a list instead of retyped.

You may see where I’m going here…

The reframe: they have an ATS, so why don’t I?

After running into all the above problems myself, I came to a realization.

Virtually every company I applied to was running an ATS: an Applicant Tracking System. Purpose-built software for exactly this kind of relational, many-to-many, months-long process. Pipelines, stages, notes, contact history, document attachments, reporting.

On my side of the same process: a spreadsheet.

An interesting imbalance given the symmetry of the problems. Both sides are tracking a lot of entities over months, with relationships between them, and both sides care about not losing a thread. They had tooling for it. I had tabs.

So I wanted the other half. A tracking system of my own. But an “ESTS”: an Employment Search Tracking System, to their “ATS”. And that’s what I’ve been building. It’s called Observatory, and it’s the first application in a suite called Constellation.

What actually needed tracking

Once I stopped thinking in sheets and started thinking in entities, the shape came into focus:

• Applications. The thing most start with.
• Companies. They outlive any single application.
• Contacts. People, who belong to companies and persist across roles.
• Interactions. When and how I talked to someone, and what came of it.
• Documents. Which resume variant went where.

And the important part, the part where a spreadsheet strained: all of these easily link to each other, and the links matter as much as the records. A contact without the company is half a fact. An interaction without the application it advanced is a note with no consequence.

This also shaped scope. An ESTS is one tool, and there are clearly others sitting next to it, which is why the suite gets a name of its own. For now Observatory is the whole focus.

Relational databases are, it turns out, for relational data

These links, this is what relational databases exist for. It’s in the name. Entities in tables, links between them expressed as relationships, and the database responsible for keeping them consistent instead of you. Update the company once and every application referencing it is correct, because there’s only one copy of the fact.

It is not impossible to make a spreadsheet do this, but databases are designed for this type of use. They excel at this kind of use. (sorry) They are very well suited, to be a snake to slay your frogs.

The biggest problem of all: Software

I don’t want to skip the cost of all this work however, because the cost is real. The moment you reach for a database you’ve left “a tool I keep my job search in” and arrived at software. There’s a schema to design and migrate. Authentication, because the data is personal. Authorization, because it should stay that way. Deployment. Backups. A test suite. All of it needs maintaining, and none of it helps you get a job on the day you’re building it.

I’ve released a bunch of snakes onto my island to deal with my frog problem, and they’ve solved it! My new problem? I have a bunch of snakes on my island.

So yeah, for a lot of people this too may be a bad trade. If your search is going to be over in six weeks, your targeted companies or job pool is a few dozen posts, or you’re a spreadsheet wiz thinking in formulas unblinkered by hundreds of entries: stay in the sheet.

But I want to track multiple types of information and building this kind of thing is what I do. Doing it in the open is the point of these posts: the decisions, the tradeoffs, the things I got wrong and had to tear out.

Next one is a tour of what Observatory actually does.