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?
14 comments
[ 2.7 ms ] story [ 57.6 ms ] threadMore 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.
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.
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.
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.
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.
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.