I don't think a list of job titles would be helpful for you because (not surprisingly, as a startup) you are looking for one person to do 3-4 different jobs.

In my experience, what and where to measure should be led by your business folks. The rest of the responsibilities could probably be handled by a data engineer.

I guess my word of warning is that I don't think you'll find someone with three areas of expertise

1) understanding your business / industry at a level deep enough to know what to measure.

2) having the core statistics and analytic capabilities to work with someone in category 1) to get insights out of the data.

3) having a deep understanding of databases and engineering pipelines to make functional and reliable data infrastructure that allow folks in 2) to be good at their job.

If you are starting a new analytics department, I would be looking for an existing person at the company to take responsibility for 1) and look for a great candidate in 3) who has worked closely with others in 2).

Great advice, thank you! We have 1 (founder team) and 2 (data scientist), actually looking for 3 to chose the right tools and lead the team to implement them across the stack from front to back to database to operations. I guess that putting the explorative work of 2 into operations is, again, another position 4? Probably a problem for 2023 ;-)

Not a definitive list, but do look around on which titles other companies are using. One way to do that is through career ladders - the Dropbox one was already mentioned in this thread, but take a look at https://progression.fyi/ and https://www.levels.fyi/ for a compilation of other examples.

Another way is to take a look around LinkedIn and see what titles other companies are doing (especially ones in the same talent market as you). Look both in the titles of current/past employees and in the job postings themselves.

Thanks, will definitely check out your links!

About LinkedIn – checking other companies job postings was actually the moment when I decided to 'Ask HN'. I wasn't able to extract systematic classifications from them.

I'd call this Lead Data Engineer, but it matters less what you call it and more what you put in the job description. For the requirements you've given, I'd suggest looking for someone who's set up tracking and the modern data stack from scratch, regardless of whether their title at the time was software/data/analytics engineer. Searching for "modern data stack" will get you a (growing) set of relevant tools.

You might also want to read The Informed Company by Fowler & David, which does a good job starting with a very simple setup and walking through how and when and what to add on - the folks you're looking for are in high demand, and if you don't find someone quickly, the book might give you enough to help your junior devs make reasonable choices for where you are now.

Will read it, thanks!

Slightly OT, but I had a job a while back where they were fed up with titles, and let you choose any title you want that wasn't a protected title (in practice a C-level officer).

God-Emperor of code? Alright.

Artifex maximus programmanorum? You do you buddy.

Most people just chose "senior developer".

Some of my acquaintances work in a customized software development shop that's doing that. They have over a hundred devs working there and their business is that any client can just walk in the door, specify what they need, and then a team of typically no more than 3 engineers will go and implement it.

When one of them walks in a meeting room with a new client, they'll introduce themselves with a job title that they make up on the spot and satisfies these criteria:

- make it sound like a legitimate job title

- make it sound as senior as you can credibly get away with

- make it sound unique to the client's industry or requirement

- obviously: don't say anything stupid that will have legal consequences like "CEO" or "General Counsel"

It's working really well for them. They're having a blast doing it, and clients get to feel special.

For example a client in the retail business will say things like: Oh, I can tell the agency is really taking my business extra serious. I can tell because they don't just have any old senior developer working on my project, but rather my project is handled directly by their "Senior Head of Retail".

Or if a client asks: "Can you make me a responsive website?" One of them might say: "Yes. In fact, do you know who the gentleman sitting to my left happens to be? He's our Responsive Designs Art Director in Residence".

This is... probably making the clients very happy! Good for them! Wonder if the clients' shareholders would feel the same way, though.

> Artifex maximus programmanorum? You do you buddy.

At least it points our the absurd arbitrariness of titles in software development.

15 years working on business/safety-critical infrastructure? -> senior engineer

3 months javascript bootcamp, no degree, 2 years of work? -> senior engineer

I've always gone with señor developer myself.

I had a job like that right after college, my title was "Software Ninjaneer".

I'd probably pick "Software Archaeologist". I've got a soft spot for old programming languages, code bases, etc.

My cards where already printed but we can also choose our own titles. My next card will say: "Üb3rn3rd"

How is a C-title protected?

Depends on the C-title and the jurisdiction. There are legal documents that can only be signed by the CEO. Some actions of CEOs need to be published immediately in case of public companies. So it's the duty of the real CEO to prevent other people in the company to make outsiders think they could act in a certain way on behalf of the company.

CEO I understand, also other officers that are legally bound (possibly the CFO for reporting financial results for instance, or the Secretary).

But then there is the plethora of Chief Marketing Officer, Chief Information Officer, Chief Whatever Officer which are being created more or less ad hoc.

First thing that comes to mind is the big list of tech industry position descriptions from the Australian Information Industry Association [1]. Not sure how good they are since I haven't actually had a proper read of any myself.

[1] https://www.aonhumancapital.com.au/getmedia/9b5d9f13-294f-46...

Sounds like you might want an SRE lead / Platform owner.

in my experience it is still too early in the game to thin slice roles like this.

It makes sense to have broad buckets like:

  - mobile (ios, android)
  - frontend / backend (web or fullstack)
  - SRE
  - Security and compliance
  - AI / machine learning

this is how i might tag tickets. but small teams probably have to share responsibilities until there are enough resources to focus

> want an SRE lead / Platform owner

No. Those are responsible for ensuring your platform doesn't go down and is well designed.

They aren't SMEs in Data.

We're even more lean than that, SRE and compliance are no concern other than the usual (don't break to much stuff in production, follow the law). The core task at hand is to tell junior devs on frontend, backend and db layer what to implement, and in which way to implement/integrate, so that data about business and product objectives can be measured, stored and analyzed.

What does the startup do? What kind of things do you have to measure?

Or to put it another way, whats the criteria for success. More sales? Faster development, less downtime?

I added more information above to clarify, thank you for asking. We're building an EdTech platform. Current criteria for success wrt the role we want to higher for:

- faster development

- happier junior devs: they demand more guidance in the given area

- better product, measured by usage, referrals and learning progress

Lead Data Engineer

> Is there a conclusive list of job titles and specifications one could rely on?

No, there isn't.

What you're describing could be called a lead data engineer but you can also call them a lead software engineer if you don't want to distinguish between data and non-data engineers with the title. But the "what to measure" and "where to measure" parts don't really fit under it - that's more like a data analyst or someone in a business role (depending on what you're measuring and how important/advanced it is), or a data scientist... but then not every part of the job needs to be reflected in the title.

Basically there are many different ways to set up the titles, and most of them are fine.

Data Engineer vs Software Engineer is always hard for me. It's always a choice between the lesser of two evils:

1) Advertise a data engineer role and get applications from rebranded DBAs who can't code their way out of a paper bag

or

2) Advertise a software engineer role and get applications from software engineers who believe joining a couple of entities in their ORM counts as deep database experience

"Big Data Software Engineer"?

(You can drop the "Big" if you have less big and want to appear less cringe)

You could also attach a specification to the title like "Senior Software Engineer: Data [Services/Infrastructure/Platform]"

Ah but "Big Data" attracts the people who took a course on Spark and now see it as the tool to apply everywhere. It's turtles all the way down ;)

When I'm hiring I've settled on sticking with "Software Engineer" and gasp being as specific as possible on what I'm looking for. But nothing will ever be perfect, or even great.

Right, my "eats shoots and leaves" panda just put the comma in the wrong place; also remembering that one of the best engineers I ever had the please of working with was indeed "big"

titles are almost as hard as naming things

Yeah, it's messy. From the applicant side I prefer the title software engineer over data engineer. A more general title is better for career flexibility, and for some reason I've run into quite a few teams where the DEs have lower perceived status (perceived to not be able to code compared to software engineers, perceived to not be that smart/educated compared to a data science team etc).

The DE being lower status thing is precisely due to the rebranded DBA comment I made. It's no different than how the term "DevOps" was coopted by sys admins rebranding themselves with a hipper title. And we're starting to see the same thing with SRE being used by QA folks seeking a similar rebranding.

As an applicant it's hard to figure out which form of Data Eng, DevOps, SRE the company practices and is seeking. As a company, it's hard to communicate your interpretation of the terms.

IMO at least with DevOps one tell is if they consider it to be a role and not a philosophy, they probably are using it to mean sysadmins.

There's also quite a few new-to-the-industry data engineers who are just starting out (many more than junior DevOps or SRE). It's a decently sized track for people who are graduating with CS degrees and for those who are switching from other fields. And I know quite a few people who started out trying to become data scientists, along the way figured out that they like DE more and stayed there.

This is what I struggle with as well. We have the coding capabilities measured by fingers that can type quality code, but we don't have the time nor the nerves to fail our way to solutions that work.

It is strange to me you get DBAs applying for data engineering roles. Especially given that DBA is a very specific title and track. The companies I have worked at typically had data engineers separated because it was a highly specialized form of software engineering.

What I mean is, I see a ton of resumes of people who have a background of "DB Guy". Perhaps they've taken a class or two for coding, or writing airflow pipelines. Or maybe they've done a project or two in something buzz worthy. But they still pretty much just know how to operate, manage, and interact with DBs in the same manner as someone from 2005. That's not a bad skillset, those people are valuable. They're just not what I need.

I rebranded myself as dataengineer because i was sick of doing crud apps. Now i write etl all day.

What kind of analytics are you talking about? Is it for your clients to use, or to measure your own engineers' performance, or is it product telemetry, or etc etc etc?

I added more information above to clarify, thank you for asking. We're building an EdTech platform. The objectives for the job are:

- faster development

- happier junior devs: they demand more guidance in the given area

- better product, measured by usage, referrals and learning progress

OK, your updated description is

> 1) give users an overview of and feedback about their activity, 2) create effective and evidence-based interventions, and 3) improve learning outcomes and engagement.

...which is product telemetry; on the technical side you want someone who knows how to use GTM or mixpanel or (any of dozens of other competitor tools) to track what users are doing in your app, and on the analytics side you want someone who knows how to interpret that data and create meaningful interventions or product changes as a result

The first part is relatively simple, any developer can figure out how to install one of these tools and start logging events. The second part probably needs an education SME who can take that data and do something meaningful with it, or a strong product lead (who would look at it more from a features-and-workflows point of view than from an educator point of view, different paths to maybe similar results).

Neither of those people would be who you'd want involved in deciding where to store the data or how to access or process it; that's more in the database admin realm.

Your list of objectives here, though: > - faster development > - happier junior devs: they demand more guidance in the given area > - better product, measured by usage, referrals and learning progress

The first two are completely unrelated to the above: the first is more about measuring cycle time, velocity, all that fun scrum/agile stuff; the second is ensuring that your junior devs have good mentors and managers. The third one is more of a restatement of the product telemetry goals.

Longwinded way of agreeing with many of the other responses you're getting: the reason you're having a tough time coming up with a reasonable job title is that you're describing at least four unrelated jobs.

(I'm not currently in edtech but have a long history there, and some in a couple of those unrelated roles; happy to discuss further if you like, I admit partially because I'm curious to see what new startups are doing in that space ;)

"Is there a conclusive list of job titles and specifications one could rely on?"

You'll be rich if you find one. Most companies can't even keep a decent list as the reality varies from team to team.

I suggest reviewing the Dropbox Engineering Career Framework. https://dropbox.github.io/dbx-career-framework/

I do not really understand their structure. There is a bunch of engineering scopes, and then one set for the engineering management (all scopes are covered)?

In other words you can have a "M7 Security Senior Engineering Director"?

Awesome! Thank you!

You have several questions, and they range across more than one discipline.

I'd be happy to help you narrow down a job title / job description that would help you recruit for your role. Email in profile.

Analytics Engineering Lead or Data Engineering Lead.

Unfortunately everything in software engineering gets kind of...wibbly-wobbly. I can generalize for you from my experience but you'll see just how weird it can get:

1. Junior SE: Typically not responsible for anything. Expected to be a cost-sink for a bit but will ideally not spend long in this position and advance to whatever the next position is. Usually someone fresh out of school or new to the sub-field.

2. Software Engineer: This title can be an alternate title for Junior, and it can have several ranks inside of it (1-3 in order of experience). This person typically has 0-N years of experience where N is determined by industry. In start ups you see people not spend long here. In more established companies people can spend quite a few years here.

3. Senior Software Engineer: One of the only consistent titles in the industry. Always comes after Software Engineer. This person has experience and is typically responsible for maintaining a single code base, mild planning tasks, and sometimes overseeing 1-2 software engineers/juniors. In more established companies SSE has tiers, with the final tier having responsibility approximately on par with the next rank.

4. Lead Software Engineer: Some companies use this to refer to a final-tier senior.

[At this point the tree bifurcates]

5. Staff Software Engineer: This is an IC track "management" position. Less code contribution, more high level planning and architecture. Will typically oversee a few senior engineers but this is not required. Typically "do-ers" fall into this position and have 7-10 years of experience.

5a. Director/Junior Director/Manager: All of these titles can mean the same or different things and it REALLY depends on the company. At any rate, the "L-equal" title to staff is a people position that specializes in management of engineers.

6. Senior Staff Engineer: Usually awarded late in the staff engineer career path. Either represents the top tier of staff engineer, or as a special "preparation" tier for principal. Roles for principal and senior staff are similar but senior staff will have less expectation.

7. Principal Engineer: In some companies this replaces staff, and principal gets tiers. Generally principals are responsible for staff duties (see 5), but as they advance further in the tiers they become closer to R&D. Typically responsible for engineer oversight and code culture, spiking new services, planning, architecture, etc. The jobs can vary dramatically by company.

After this titles can vary wildly and it wouldn't be possible to nail down exact traits. You typically will have either research engineer, resident engineer, or another very important very small title coming after this.

In the event of data jobs typically engineering jobs are given an extra "data" in front of them. Data engineers (just add Data in front of 1-6 with the exception of people management) have additional responsibilities that involve dev-opsy infrastructure work as well as building pipelines. Usually data engineering positions require more in depth backend knowledge and can be performance critical positions (in contrast "regular" SE positions can be performance critical but typically are not as critical except in special cases).

Great comments so far! I expanded upon the role in the initial description!