Navigate the Startup Tornado: A guide to crafting effective job descriptions

With apologies to Sharknado, sometimes being in a startup is like trying to build a house while trapped in a tornado full of chainsaws. There are urgent things (dodging the chainsaws), and there are important things (creating a good foundation for the house). Today, we'll talk a bit about Job Descriptions and Job Advertisements (Ads) -- two things we've found foundational in previous jobs that, if done right, can help you dodge a few chainsaws down the road. At the end of the blog post, we'll provide a ChatGPT prompt that encodes what we discuss and will help you overcome empty.txt.

Why these two things? Well, as a startup leader, the most important job you have is to build the right team. You will want to attract top talent and then make that talent successful. You will need to understand the roles you're filling and help people understand your expectations for those roles. These two documents help you do that -- they force you to be intentional and explicit about what you're doing.

The first thing we do is distinguish between a Job Ad and a Job Description.

A Job Description is a document that defines the duties and expectations associated with a role in the company. Since it defines a role, its language must be declarative and unambiguous. We will use these documents when we promote people or coach them on performance. It should be possible for someone to use the document as a measuring stick -- "am I doing a good job in this role?", "How close am I to this next role?". Its stipulations must be measurable or confirmable.

A Job Ad, by contrast, is a document that describes what it would be like to do the role of a person who isn't inside your company, hence the term "ad." The language in a job ad is evocative and emotive. If done well, they can give a prospective candidate a feeling about what it might be like to work in the organization.

Perhaps non-intuitively, Job Ads act as a filter -- some candidates will find a job ad exciting and memorable, "Wow, I'd love to meet this team!" other candidates will read the same ad and say, "What a bunch of chuckle-heads, I would never work there!". This is as it should be-- if you are building an exacting culture of precision, the ad should reflect that as folks who thrive in a more shoot-from-the-hip environment, they will be able to judge the situation accurately and self select out.

For the graphical among us, this dichotomy is shown below:

Job Description Structure and Function

Job descriptions are used to understand the structure and function of each role in the organization. At Fixify, all Job Descriptions are available to all employees; we store everything in Notion. Do as you will with your own setup.

Each JD has a very particular set of sections, shown below:

This is the CTO job description. Getting good at writing them may require reading a bunch, which is one of the reason they should available to all employees internally.

Narrative Introduction

This section describes what the role is and what it does. When writing it, you're trying to answer the following questions:

• What is this role responsible for / what are its deliverables?
• Who is it responsible to / who are its customers? As your boss, these are the people I'm going to ask if you're doing the things you should be.
• Who does it collaborate with / who are its partners? These are the people that will help you do the things you need to. If you've done this right, those people also know this.

If you read an organization's job descriptions, the combination of deliverables, stakeholders, and collaborators should line up such that you have a functional view of the organization. If they don't (like you have one JD that references a collaborator role and the corresponding JD doesn't mention it), you have an organizational design problem.

As a manager designing a role, your job is to think carefully about these linkages to ensure that they line up.

Responsibilities

These are the activities a person in the job needs to be doing and producing, listed roughly in order of importance. As a manager authoring this JD, consider these as a list of high-level targets for the job.

These tend to have a structure like you are responsible for < high-level target>. <lower level evidence of target>. 

For example:

You are responsible for the technical vision of the company. You ensure that the products the engineering team develops are of the highest quality, and meet the business needs of the company.

Customers/Stakeholders

There are certain groups for which a role is producing output. These are the people you're going to check in with as a manager doing an evaluation. These sections tend to look like: You ensure <someone> has <something they need at a high level>. <lower level example>. 

For example:

You ensure that the GTM team has the tools necessary to launch products on time and on budget, including all necessary financial modeling and pricing plans.

Collaborators

If the outcomes are big enough, a single role may not be solely responsible for them. In that case, it may collaborate / partner with another team. You should think of these as the folks in the team meeting who will discuss progress and blockers.

These tend to have the structure: You partner with <who> to ensure <what> <examples of what that looks like>.

For example:

You partner with the GTM teams to ensure that what we’ve built has the desired ROI, every time, that delivery milestones are hit, and external targets are met.

As you're writing these, you want to think about a conversation with your team member in which you're evaluating if they did or didn't do the thing — is there some clarity on what an example of success or failure would look like? If not, sharpen the words.

Primary Responsibilities

While the narrative structure talks about the role in the organization's structure, the primary responsibilities are a bulleted list of what the person in the role needs to do to succeed. This list is in order of importance. Each bullet should capture one fundamental action or deliverable in a tangible way. They must be structured so that you can reasonably imagine sitting with a team member who is looking to get promoted and say "Yes…Yes…no on this one…Yes…Yes".

As an example, if I want to make sure that the CTO builds a reasonable set of products, I could write.

Ensure product roadmap makes sense

The issue here is that this isn't evaluateable. Does it make sense to whom? What we want to do is reword this to reflect what we actually need — I'd like to make sure we (a) build a process to inform our roadmap and (b) that translates into some action in the product team:

Use market research as inputs to develop a roadmap and plan for product development and implementation.

I can now sit with the CTO and say, "OK, can you show me the research we did to arrive at release 1.0 of whosamawhutsit?". The question is fair because (a) there should be a roadmap and plan, and (b) it should be informed by market research.

The second key for writing these is to ensure they're achievable by this person (or their team if they're a manager). If I modified the above to read:

Use market research as inputs to develop a roadmap and plan for product development and implementation, yielding 100M in ARR.

We've made the bullet worse because (a) the CTO can't make the number by themselves, and (b) now the JD is hooked to a specific outcome — what happens when we've gotten there? Do we rewrite the role? In general, collaborative goals and structure should be in the narrative section, while primary responsibilities reflect what this particular person will do.

Technical Skills

This is a priority-ordered, bulleted list of things you need this person to have in order to do this job. As with primary responsibilities, they should be clear and unambiguous. However, there is some flexibility inherent in these — it's possible the person can do a good job in this role if they are missing a few of these things — there is a "Fit" for a role that comes into play.

We are also well cautioned to not be overly specific if it’s not necessary. Consider the difference:

Expert level knowledge in Java

Versus:

Expert level knowledge in one or more object-oriented programming languages

If the person actually needs Java coming in the door, then ok. More likely, they can pick up another if they have expert-level knowledge in one OO language.

There is also a hierarchy for technical skills — you don't need everyone to be expert-level at everything. Words matter here, so, insomuch as we can confirm:

• Industry leading expertise in — you give talks on the subject
• Expert-level knowledge of — you can train people to use this tech
• Working-knowledge of — you can use this in your day-to-day work and not stumble around
• Familiarity with — you know what it is, have used it, but would have to google a bit

A technical skill/level for one job may be different for another. For example, when hiring a finance person, we may define "working knowledge of Excel" as "you can use pivot tables and advanced formulas and develop dashboards directly in the product." Meanwhile, "working knowledge" for an engineer might be "you can import some data and make a graph that doesn't make my eyes bleed.”

Non-technical Skills

This is a priority-ordered list of soft skills that the job requires. These are all evaluated in the context of the manager, so the evaluation criteria may sound a bit looser, but they're really not:

Ability to quickly engender trust

You might say, "Quickly to whom?" in this case, the answer would be "to your manager." It will be helpful during onboarding to specify what some of those expectations might be, which sounds something like:

“It’s critical over the first 30 days for you to build a relationship with team X”

By doing that, you define what quickly is, and you can set a check-in point with some stakeholders to ensure things are going smoothly.

Things to Avoid

Emotion

To risk beating the horse — you want to avoid emotive language. A JD shouldn't tell someone they need to be passionate — passion is subjective, and so cannot be a hard criterion for career advancement.

Over Specification

You also want to avoid over-specification. There is a tendency sometimes to stray out of the realm of expectations into the arena of mechanisms. As an example, consider the bullet below:

Prepare weekly status reports for the exec team, including all relevant financial metrics

The issue here is — what if we determine that weekly isn't necessary? What if it's better to do an oral report once a month? What we need to do is consider the intent — we want the exec team to be informed about the financial health of the business:

Perform necessary reporting to ensure all executive stakeholders are aware of the financial situation of the business

Winging it

Yes, I get it. You want to start hiring to get a job filled, and this seems like extra paperwork. It's not. Writing a JD isn't a requirement for hiring someone; it's how we ensure we hire the right person for the right role. That's our job as managers.

Finally a cheat code

There is no shortcut to thinking intentionally about the roles, responsibilities, and how each member, along with their teams, interoperates with others. The success of a startup hinges on numerous factors, but establishing a strong foundation for great people to thrive is undoubtedly one key element. But sometimes when your busy dodging all those sharks and chainsaws —a blank sheet of paper can seem overwhelming. To assist, we offer you an LLM prompt to help JDs get started. While this won't replace deep thinking about roles, organization design, etc. It should help alleviate some stress when you're faced with a blank page.

• Job Title: <Title of the role>
• Brief Description of the Role: <Write out your train of thought describing the role, what’s important to you about the role, skills they should have, etc>

Output:

Create a job description for the role at <Your company name>, incorporating the following sections:

Narrative Introduction:

Craft a comprehensive description of the role, integrating its purpose, deliverables, key customers, stakeholders, and collaborators. Ensure the narrative reflects <Your company name> values such as <insert some company values here>. The narrative should provide a clear and unambiguous overview of the role's impact on the company, aligning with the mission to humanize technology.

Primary Responsibilities:

• Detail the high-level targets and responsibilities of the role in order of importance, including aspects related to customers/stakeholders and collaborators where applicable.
• Each responsibility should be measurable or confirmable, in line with <Your company name>’s commitment to problem-solving, innovation, and <descriptors about your company’s vision>.
• [Example: Design user journeys that increase customer satisfaction, driven by data and feedback]
• [Example: Develop and monitor a capacity model to ensure scale and quality of operations]
• [Example: Build technical solutions appropriate for the problem at hand, considering requirements like performance, cost, reliability, etc.]
• [Example: Participate in building and maintaining engineering team products across the full lifecycle, from conception through development, deployment, and beyond]
• [Example: Collaborate cross-functionally to deliver features that solve real-world problems, not just technical ones]

Technical Skills:

• Enumerate the technical skills required for the role, organized by priority and categorized as per <Your company name>'s standards (e.g., industry-leading expertise, expert-level knowledge, working knowledge, familiarity). <Your company name>’s standards:
• Industry leading expertise in — you give talks on the subject
• Expert-level knowledge of — you can train people to use this tech
• Working-knowledge of — you can use this in your day-to-day work and not stumble around
• Familiarity with — you know what it is, have used it, but would have to google a bit

• [Example: Expert level knowledge in metrics and data analysis]
• [Example: Working knowledge of IT tools, technologies, and market landscape]

Non-technical Skills:

• List the essential soft skills necessary for the role, incorporating aspects of collaboration and stakeholder management as needed.
• Align these skills with <Your company name>'s culture of effective communication, empathy, resilience, teamwork, and continuous learning.
• [Example: Ability to quickly engender trust and work cross-functionally]
• [Example: Excellent conflict management and customer-interfacing skills]

In your narrative and lists of responsibilities and skills, remember to avoid emotive language and over-specification. Focus on clear, declarative, and measurable criteria that reflect the unique ethos and operational style of <Your company name>.