How to approach titling for early engineering hires?
I'm wondering if folks have any advice about titles for early software engineering roles. It's probably a 'more art than science' situation, but we're too far along to consider "Founding Engineer", but still so small that we aren't really able to attract "Principal Engineers" with 5-10 years of experience.
In other words, if I'm keen to make an offer to someone who might be a "Senior Software Engineer" at another company, is it bad form to attach the title "Staff Software Engineer" if I feel that's the better fit for her responsibilities/role at our size? 'Founding <whatever>' is silly title inflation. Ten years ago 'Founding Engineer' was just 'Software Engineer'. More generally, I don't recommend fiddling with basic titles early. You don't know if your company will be alive in two years so there are more important things for everyone to focus on. Just give everyone a title of 'Software Engineer'. Anyone who rejects you for that is likely someone who shouldn't join anyway. Founding <whatever> only makes sense if you're giving them a founder-sized slice of equity. Good advice, thank you. Beg to differ. Whether you like it or not the world does not operate on idealistic standards. Most people when hiring for certain higher levels are looking for (among other things) a steady growth trajectory in candidates and unfortunately titles are the only way to show that on linked in and resumes. When somebody is a principle engineer prior and moves to software engineer title it’s hard to parse this dip without the person being able to provide context. As such people who are career minded ambitious will likely have a problem with this and pass.to box everybody under software engineer might be great for the company but demonstrates one sided thinking. Lot of candidates are not ok with that. I would just make the title as accurate as possible for your organisation. People who care too much about titles probably wont stick around too long! Salary and what the job entails are far more interesting. That said if you find
someone great and the title is the only sticking point maybe be flexible. It could be the reason they choose your company over a
similar offer that is hard to
choose. No one cares about titles. Everyone cares about compensation. If your "staff role" is getting less than other's company "senior role", well, all things equal, you cannot compete. I was a staff engineer in company A, and moved to company B in which I am "just" a senior engineer. My compensation is higher now. Everybody's happy. I’d probably avoid more titles than software engineer and senior software engineer until you have a proper leveling system with expectations for each title. I think the only titles that make sense in a tech org are Software Engineer, Senior Software Engineer, Lead Software Engineer, Engineering Manager and CTO. Everything else is more noise than signal. I assume you are still happy to call yourselves “CEO”, “CTO” etc… you really shouldn't use engineer at all. engineers are licensed by states. Legally speaking, that's true. But software developers do something that can be described as engineering, and I don't think that terminology is going away anytime soon. So what now? Does anybody really want a push for "software engineering" to be licensed by the state? I can think of a world of problems stemming from this. Seems to work all right for almost every other engineering path such as mechanical and electrical. I think we could do with some state level accreditation, starting with a rigorous PE exam for computer science. It's not like it would prevent you from working as a dev, you just couldn't call yourself an engineer. > Seems to work all right for almost every other engineering path such as mechanical and electrical. I respect your analogy, but I think this is a very incomplete and shallow way of looking at it for just some of these reasons. > Regardless of however pleasantly you might conceptualize a smart and basic Computer Science exam that you think might not prevent you from working as a dev, there's going to be consequences in the job marketplace and inevitably government overreach that you cannot predict if this emerges. I think this could be catastrophically bad for many developers on a level that we cannot even fully see. > Software isn't tangible and must move much faster than physical engineering. A bridge or skyscraper might be designed to last at least 100+ years, and can't easily be changed once built. But software is infinitely flexible and can be rapidly changed and adapted to other situations. Rigid thinking in the software domain is much more damaging to progress than in physical engineering. > With civil engineering for instance, there's a very clear and measurable success and failure condition; basically a structure either handles the load its designed to handle or doesn't. But software is different. A system or an algorithm can be very inefficient and wasteful and "bad" from a software engineering perspective, but still successfully solve the problem and be the right solution from a business perspective. True wisdom in problem-solving through software comes from understanding the tradeoffs involved in building stuff and being able to make the right decision on how to build something, even when it's a "bad" solution "by the book". I don't see a government software engineering test ever being able to capture this.