This project describes a set of job titles for software engineers, operations admins and engineers and their managers. It was developed by members of the engineering team at Urban Airship and updated here for Touch of Modern, but could be used as a starting point for your titles within another organization. The actual titles are in the doc called 'eng', the doc called 'ops', and the doc called 'ce'.
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.