Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time
November 19, 2013 17:47
November 19, 2013 10:48
February 8, 2017 11:41

What is this?

This project describes a set of job titles for software and infrastructure engineers and their managers. It was developed by members of the technology team at Airship, but could be used as a starting point for your titles within another organization. The actual titles are in the doc called 'eng'.

Why spend time on something so boring?

We all want our company to be a place where great engineers can make a career out of building great software for our customers. To do that, we need several things: a shared idea of what makes an engineer "great", room for people to grow and develop for the long term, and a way of recognizing and rewarding continuing excellence. We also shouldn't have to take everyone who's really good at their job out of that job and into a management role just so they can get a promotion and the good stuff that comes along with it.

Defining formal titles for both individual contributors and managers (with a rough correspondence between them) draws a sort of crude map of how people can grow within the organization. By combining this with regular performance review and promotion opportunities, we can provide public recognition for sustained job performance, as well as help to prompt productive discussions around goal-setting and development.

We have to be sensitive to the risks and potential pitfalls that accompany a formal job ladder as well. Titles can reinforce social dynamics that allow more senior team members to shout down or suppress good ideas from their junior colleagues. Also, if people perceive unfairness or favoritism in the assignment of titles, they may make decisions about which teams or projects to join that are detrimental to the rest of the organization.

Overall, titles should be used as one of many tools in a manager's kit to motivate, recognize, and develop the members of their team. They are in some ways the public complement to private rewards like compensation and equity, and if over-emphasized or mis-applied have many of the same potential pitfalls (e.g.: overjustification effect).

Why not just put this in a spreadsheet or a presentation or something like a normal manager-type person?

Most "job ladders" (as the progression of titles is usually called) are developed outside by senior management or HR in a fairly opaque way, and changing them is very hard. As engineers, we expect for well-intentioned and well-made changes to be continuously included in our projects, and we believe there's no reason that job descriptions can't work the same way.

So, fork away! If you have suggestions, submit a pull request and send a note to the folks listed in the OWNERS file.


Job titles and descriptions for UA engineering






No releases published


No packages published