Tech startup vocabulary
Useful terms to know as an early employee of a tech startup
Late last year I was talking to a friend about our work situations and I kept using words that made things click in his head - words that he kept exclaiming: "wow that's a useful term! Wish I'd known that in my previous job!" This conversation made me appreciate the massive amount I learned at my biotech/govtech startup. A huge part of that learning was just vocabulary, especially with terms that are standard in software-focused startups but which were absent from my biotech training. Since I believe that no knowledge is too basic to share, I figured I'd write some of these words down with my own definitions. Without further ado, a startup vocabulary lesson!
Subject matter expert (SME): the person who is an expert in a given topic. The nice thing about this term is that it really clarifies who needs to be involved or consulted in a project, but it also separates out the burden of knowledge from the burden of actually doing the work. So you can be an SME without actually being involved in execution. And on the flip side, if you're the SME on a given topic, then projects really shouldn't go forward without at least consulting you.
Individual contributor (IC): someone who is not a people manager as their primary role. I've heard this described as something like: an IC is a person who codes; a manager is a person who manages the people who code. This term was already familiar-ish to me, but I gained a more nuanced understanding about it. Importantly, IC does not necessarily mean that (1) you code or do data science all the time and that (2) you don't have any leadership or influence. In my situation, I was an IC but rarely coded. Instead, I helped with high-level architecture designs and analysis plans, reviewing tech specs and code, and mentoring folks on the team. I also had a leadership role on the team, despite not managing anyone directly. Through this experience, I learned that being an IC just means that your primary job is not people management, but rather contributing to the work of the company - whatever that looks like.
Technical lead: the person in charge of the technical direction of a project. As a high-level IC, this was my primary job. I'd work in tandem with our project managers to figure out what needed to happen, make sure that the right SMEs had been consulted, and write the requirements & specification documents so that others on my team could then build the thing itself.
Agile: a standard project management approach where you break your team's time up into chunks (called "sprints") and each chunk of time is associated with a specific set of meetings. Sprints are typically two weeks long, with a planning meeting at the beginning, regular check-ins throughout, and a retrospective at the end. Agile is very common in software engineering, but can be applied to any sort of team (including data science). I like it because it lets you balance being able to pivot (since you have an opportunity to change what you're working on every two weeks) with the need to focus (since you commit to a set of tasks for two weeks and don't revisit "what do I need to be doing again?" until the next sprint start).
Retros (short for "retrospectives"): meetings where the team looks back on a project or sprint and discusses what went well and what could be improved. I like to describe them as productive vent sessions - it's the time to air out all your frustrations, but because it's a professional event, it also forces you to engage with those frustrations productively. I also really like retros because they are a great place to sanity-check whether the thing that's bothering you is actually a big deal and bothering others, or something particular to you that you can just try to get over and let go.
Technical debt: aspects of your software or operating processes that don't work well and which keep getting worse or accruing. Technical debt usually results from previous tradeoffs you made that haven’t been addressed or because your business needs have changed but your technical processes haven't kept up. Technical debt is ubiquitous but hard to explain to executives — I'd love to meet an engineering leader who's figured out how to successfully communicate about tech debt to their C-suite! The Southwest saga of winter 2022 was a great example of technical debt.
SLA (service-level agreement): an agreement for how long it will take to response to or resolve an issue. This is most often used in IT work, where the team has an SLA set for responding to and closing out tickets ("tickets must be responded to within Y minutes"). But you can also use it in many other settings to simply set expectations, like for example "X task must be accomplished by Y time every day."
Bus factor: the number of people who could be hit by a bus tomorrow without causing an entire stoppage of the company's operations. A more positive version is the lottery factor, which is the number of people who could win the lottery tomorrow and quit their jobs. If there is only one person who knows how to do something critical to the company's operations, then your company's bus factor is 1. You want the number to be high!
Project manager, product manager, product owner, program manager: the people in charge of making sure things get done. People argue about the semantics and differences between these p-words, but at an early startup they're basically all the same. And importantly, they're often roles taken up by non-PMs (like technical leads, senior ICs, and managers). Here are my working definitions for these words:
Project manager: the person who manages how the project gets done. They make sure ICs know what needs to be done, and they’re the keeper of the timelines.
Product manager: the person who figures out what needs to be built. They decide what the product looks like, what it should do, and how users will interact with it.
Product owner: the person in charge of the product. This person owns the success of the product, and makes decisions based on the product manager's input.
Program manager: the person who manages larger cross-functional efforts, which often involve multiple projects and/or products. These folks are professional cat herders.
At an early stage startup, the same person often plays all of these roles. As you grow, it's helpful to know about these terms so that you can start splitting up the work and learning best practices for each component of the P-management.
RACI (short for Responsible, Accountable, Consulted, Informed): a framework to break out different types of involvement in a given project:
Responsible: the person on the hook for doing the work.
Accountable: the person on the hook for making sure the project goes well (but not necessarily the one doing the work).
Consulted: people whose input is needed for the project, often SMEs.
Informed: people who just need to know about the project, but aren't otherwise involved.
RACI is helpful because it shows that there are many folks who need to be involved in a project but who aren't necessarily doing the work. It also clarifies what sorts of communications need to happen between individuals on the project team, and can help set boundaries so that you don't end up with too many cooks in the kitchen. I prefer to think of it as ARCI, since the Accountable person is the person at the top of the responsibility chain - they're who decisions get escalated to, and they're ultimately accountable for the success of the project.
On-call rotation: a defined group who is responsible for resolving urgent issues, and whose membership changes on a regular basis. It can be helpful to define an on-call team and SLAs as you start growing so that the early employees who have so much historical knowledge aren't always stuck firefighting or resolving issues, and so that newer hires can also learn how to troubleshoot their system.
Field application scientist: a technical person out "in the field" talking to customers. I think this term originally meant a scientist working for a lab tooling company who helps the company's customers install and troubleshoot their technologies. We used it more flexibly, to mean a technically trained person (in our case, epidemiologists), who would be available to serve as the technical person on customer calls.
Product requirements: a list of things your product needs to do. Importantly, product requirements should remain agnostic to how the thing will get done - it simply outlines the basic requirements. It feels simple when you say it out loud, but you’ll see that this step is often skipped over and leads to much sadness down the road.
Technical specification (tech spec): a document outlining how something will be built. In the case of software, this document outlines the inputs and outputs, any API contracts, and the implementation approach. A junior engineer should be able to use a well-written tech spec to implement a given project.
Architecture diagram: a high-level picture of how a system works, typically applied to software. Colloquially I call them the "boxes and arrows" diagrams - boxes are typically information or actions, and arrows show how things flow through the system.
Gonna share this with my students!