The Problem with Job Titles: Part 2(blog.workshape.io)
blog.workshape.io
The Problem with Job Titles: Part 2
http://blog.workshape.io/the-problem-with-job-titles-part-ii/
3 comments
Great article, and fascinating insight into the analysis of your data.
Its definitely a problem both ways. Companies hiring can't be sure their initial hook will return appropriate candidates. Then candidates looking for a suitable role can't really be sure what they are applying for will suit their skill set and desires.
Your classification of roles and candidates is certainly a much more complete approach for ensuring various parties get what they want, good work!
looks like a trend towards more general skills than highly specialised people, I'm calling that a win for cross stack engineers.
Interesting posts.
I'm not especially keen on the title "Software Engineer", though I accept by now that it is deeply entrenched. While the title "Engineer" doesn't carry the same general expectations of specific education and credentials as "Lawyer" or "Physician", it does carry those expectations within more narrow titles - a "Structural Engineer" means something very specific and people do have specific expectations for it. It's a complicated topic, but I'm one of those people who thinks that programming has deeper roots in math than engineering, and I am unsettled by the idea that the PE people would be able to leverage their control over the word "engineering" to gain control over who is allowed to call themselves a "software engineer", and then use this power, through scope creep, to start to restrict the practice rather than just the title. I lean against the idea of formal exams (a "bar" for software). I'm not completely opposed to it, but if it happens, I'd prefer to establish it completely independently of any professional engineering accreditation, since I just don't think computer science, or even the modern practice of writing software, is sufficiently similar to engineering to be considered a subset of the PE exams.
Software Developer is fine. I never minded "Programmer", I guess some people feel it's a low status sounding term that focuses too much on writing code rather than the other tasks that are equally or more important to writing good software.
Now, that second part there does hint at why job titles and especially (not mentioned in these blog posts) job descriptions ("job cards") can be so essential for software developers. As I've gotten more "senior" in my career, I have found my job card to be an essential line of defense on more than one occasion. There are a lot of people out there who want to put software engineers (I'll revert to the commonly used term here) in a box. They want to see the programmer as the worker who can execute someone else's vision, but they will try to deny the programmer the autonomy and decision making authority that comes with a more senior role.
There is, of course, a limit to autonomy on all sides, and there are grey areas between technical and business decisions, but it helps enormously to have a document that lists what it is you were hired to do. Job cards for more senior technical workers often have phrases like "establishes system architecture", "evaluates and determines technology choices", or even more deliberately ambiguous things like "works with business units to align business goals with technology" (where autonomy can clearly overlap). But it makes it clear - the technical side engages collaboratively with the business unit, but it isn't simply there to execute whatever it is the business unit tells it to do.
People often don't like job cards because they imagine the phrase "that's not in my job card." However, I've found that's not really the problem, at least for me. I'm more that happy to do things that aren't in my job card if that's what needs to be done. But I have found myself in a position where I'm saying "that is in my job card." A business leader may want to take a decision that at least (according to the organization) requires my input, and tell me how it is going to be. If this escalates, it's very useful to have a signed, sealed and delivered document establishing your role in the organization.
I'm not especially keen on the title "Software Engineer", though I accept by now that it is deeply entrenched. While the title "Engineer" doesn't carry the same general expectations of specific education and credentials as "Lawyer" or "Physician", it does carry those expectations within more narrow titles - a "Structural Engineer" means something very specific and people do have specific expectations for it. It's a complicated topic, but I'm one of those people who thinks that programming has deeper roots in math than engineering, and I am unsettled by the idea that the PE people would be able to leverage their control over the word "engineering" to gain control over who is allowed to call themselves a "software engineer", and then use this power, through scope creep, to start to restrict the practice rather than just the title. I lean against the idea of formal exams (a "bar" for software). I'm not completely opposed to it, but if it happens, I'd prefer to establish it completely independently of any professional engineering accreditation, since I just don't think computer science, or even the modern practice of writing software, is sufficiently similar to engineering to be considered a subset of the PE exams.
Software Developer is fine. I never minded "Programmer", I guess some people feel it's a low status sounding term that focuses too much on writing code rather than the other tasks that are equally or more important to writing good software.
Now, that second part there does hint at why job titles and especially (not mentioned in these blog posts) job descriptions ("job cards") can be so essential for software developers. As I've gotten more "senior" in my career, I have found my job card to be an essential line of defense on more than one occasion. There are a lot of people out there who want to put software engineers (I'll revert to the commonly used term here) in a box. They want to see the programmer as the worker who can execute someone else's vision, but they will try to deny the programmer the autonomy and decision making authority that comes with a more senior role.
There is, of course, a limit to autonomy on all sides, and there are grey areas between technical and business decisions, but it helps enormously to have a document that lists what it is you were hired to do. Job cards for more senior technical workers often have phrases like "establishes system architecture", "evaluates and determines technology choices", or even more deliberately ambiguous things like "works with business units to align business goals with technology" (where autonomy can clearly overlap). But it makes it clear - the technical side engages collaboratively with the business unit, but it isn't simply there to execute whatever it is the business unit tells it to do.
People often don't like job cards because they imagine the phrase "that's not in my job card." However, I've found that's not really the problem, at least for me. I'm more that happy to do things that aren't in my job card if that's what needs to be done. But I have found myself in a position where I'm saying "that is in my job card." A business leader may want to take a decision that at least (according to the organization) requires my input, and tell me how it is going to be. If this escalates, it's very useful to have a signed, sealed and delivered document establishing your role in the organization.
> I lean against the idea of formal exams (a "bar" for software). I'm not completely opposed to it, but if it happens, I'd prefer to establish it completely independently of any professional engineering accreditation, since I just don't think computer science, or even the modern practice of writing software, is sufficiently similar to engineering to be considered a subset of the PE exams.
Too late, the first NCEES software PE exam was in 2013. It uses the IEEE/ACM Software Engineering Book of Knowledge as a base and seems close to what the old IEEE CSDP certification was trying to do. It's intended (as I see it) for formally trained engineers who are working on software-intensive projects rather than developers who want to do engineering work. Your point about having someone besides NCEES do the licensure was tried (IEEE) and at least for now will not be happening going forward.
To your earlier point, I do expect someone calling themselves an engineer to have a basic grounding in chemistry, physics (mechanics, E&M, thermo), heat and mass transfer, calculus, etc.—basically, the first 2 years of engineering education common to all disciplines. I also expect that they're respecting professional standards and ethics. I realize that "software engineers" feel like they're an exception and it irritates me to no end, but I also don't see the cat being stuffed back into the bag at this point.
edit: One frustration I've had recently was in hiring an engineer on a software-intensive medical device project, and getting a bunch of web developers applying for the role. I needed someone with an actual engineering background, and tried filtering by including engineering undergraduate degree as a requirement and "professional engineer" as a preferred requirement, to no avail. If Silicon Valley wants to call everyone off the street a software engineer, that's fine, but I need a job title to use in hiring for safety critical software projects.
Too late, the first NCEES software PE exam was in 2013. It uses the IEEE/ACM Software Engineering Book of Knowledge as a base and seems close to what the old IEEE CSDP certification was trying to do. It's intended (as I see it) for formally trained engineers who are working on software-intensive projects rather than developers who want to do engineering work. Your point about having someone besides NCEES do the licensure was tried (IEEE) and at least for now will not be happening going forward.
To your earlier point, I do expect someone calling themselves an engineer to have a basic grounding in chemistry, physics (mechanics, E&M, thermo), heat and mass transfer, calculus, etc.—basically, the first 2 years of engineering education common to all disciplines. I also expect that they're respecting professional standards and ethics. I realize that "software engineers" feel like they're an exception and it irritates me to no end, but I also don't see the cat being stuffed back into the bag at this point.
edit: One frustration I've had recently was in hiring an engineer on a software-intensive medical device project, and getting a bunch of web developers applying for the role. I needed someone with an actual engineering background, and tried filtering by including engineering undergraduate degree as a requirement and "professional engineer" as a preferred requirement, to no avail. If Silicon Valley wants to call everyone off the street a software engineer, that's fine, but I need a job title to use in hiring for safety critical software projects.
Thanks for your response.
I feel ambivalence about the use of "engineering" in software. We do have "sound engineers" and "special effects engineers", consistent with a vernacular use of engineering to mean "the ingenious use of technology" (made up by me). Within that context, the term software "engineering" really isn't especially outrageous. I think that the public is not threatened by this use of the word, since they are not confused by the difference between a sound "engineer" and a licensed structural engineer. However, software "engineering" could slip into that grey area.
One thing that makes me worry less is the restructuring of the FE exams to reflect the body of knowledge in the various fields. For instance, Industrial Engineering is now substantially different from Mechanical even at the FE level. Another interesting thing I learned is that certain fields are just title based - I believe that this means you can't represent yourself as an "Industrial Engineer" in a professional context if you aren't a PE, but there isn't a practice restriction (at least that is how I interpreted it, because I don't do either it doesn't really affect me).
But one other thing I would like to mention - while I phrased my argument in the context of not wanting PE to gain control over software licensing, I do agree with you about the term "engineering". I do agree that you should have a background in those things you mentioned to be using the title where "engineer" implies this sort of background, and it is hard earned.
So I'd agree that software engineers may be grabbing a title they don't really have rights to, though I would still argue that software has far more in common with math (even math theory, like abstract algebra) than heat and mass transfer.
Oh one more thing - your description for the intended use of "software engineering" as "formally trained engineers who are working on software-intensive projects" sounds reasonable - it covers software for specific engineering systems. My worry is of scope creep - the initial process is limited, highly relevant, and justified, but it later morphs into an "I'm licensed and you"re not" situation. If that happens, I'd almost want to see some math body establish a degree requirement and math background (including things like abstract algebra and real analysis), along with very intensive algorithm questions, as a counterbalance (au contraire, mon frere, you're not licensed).
I read Milton Friedman's bit on "abolish the AMA" and enjoyed it, but ultimately, I support limited licensing and credentials to protect the public - however, I do feel that scope creep really is a serious risk here.
I feel ambivalence about the use of "engineering" in software. We do have "sound engineers" and "special effects engineers", consistent with a vernacular use of engineering to mean "the ingenious use of technology" (made up by me). Within that context, the term software "engineering" really isn't especially outrageous. I think that the public is not threatened by this use of the word, since they are not confused by the difference between a sound "engineer" and a licensed structural engineer. However, software "engineering" could slip into that grey area.
One thing that makes me worry less is the restructuring of the FE exams to reflect the body of knowledge in the various fields. For instance, Industrial Engineering is now substantially different from Mechanical even at the FE level. Another interesting thing I learned is that certain fields are just title based - I believe that this means you can't represent yourself as an "Industrial Engineer" in a professional context if you aren't a PE, but there isn't a practice restriction (at least that is how I interpreted it, because I don't do either it doesn't really affect me).
But one other thing I would like to mention - while I phrased my argument in the context of not wanting PE to gain control over software licensing, I do agree with you about the term "engineering". I do agree that you should have a background in those things you mentioned to be using the title where "engineer" implies this sort of background, and it is hard earned.
So I'd agree that software engineers may be grabbing a title they don't really have rights to, though I would still argue that software has far more in common with math (even math theory, like abstract algebra) than heat and mass transfer.
Oh one more thing - your description for the intended use of "software engineering" as "formally trained engineers who are working on software-intensive projects" sounds reasonable - it covers software for specific engineering systems. My worry is of scope creep - the initial process is limited, highly relevant, and justified, but it later morphs into an "I'm licensed and you"re not" situation. If that happens, I'd almost want to see some math body establish a degree requirement and math background (including things like abstract algebra and real analysis), along with very intensive algorithm questions, as a counterbalance (au contraire, mon frere, you're not licensed).
I read Milton Friedman's bit on "abolish the AMA" and enjoyed it, but ultimately, I support limited licensing and credentials to protect the public - however, I do feel that scope creep really is a serious risk here.
> We do have "sound engineers" and "special effects engineers", consistent with a vernacular use of engineering to mean "the ingenious use of technology" (made up by me).
And railroad engineers! Can't forget them! :)
> One thing that makes me worry less is the restructuring of the FE exams to reflect the body of knowledge in the various fields.
I don't know anyone that took their discipline-specific FE exam instead of the general one. Way back in undergrad, it was suggested that the general exam was easier. Do you know what the advantage is of the discipline-specific FE exam?
> Another interesting thing I learned is that certain fields are just title based - I believe that this means you can't represent yourself as an "Industrial Engineer" in a professional context if you aren't a PE, but there isn't a practice restriction (at least that is how I interpreted it, because I don't do either it doesn't really affect me).
That's certainly the case for systems engineering, which feels related to IE, but IE has a PE exam and systems engineering doesn't. You look at the projects that systems engineering is applied to, and they're certainly the sort of critical things (like aerospace) that you would want oversight over. I guess those in charge see the systems engineering trade association handing things fine without NCEES getting involved. Long live the industrial exemption I guess.
I'm curious to see what happens to software consultancies, and if perhaps principals are going to need a PE like you would see at other engineering firms even if they're not handling safety or mission critical projects. A PE certainly helps in qualifying as an expert witness. This point goes towards your concern over scope creep, certainly a valid one.
And railroad engineers! Can't forget them! :)
> One thing that makes me worry less is the restructuring of the FE exams to reflect the body of knowledge in the various fields.
I don't know anyone that took their discipline-specific FE exam instead of the general one. Way back in undergrad, it was suggested that the general exam was easier. Do you know what the advantage is of the discipline-specific FE exam?
> Another interesting thing I learned is that certain fields are just title based - I believe that this means you can't represent yourself as an "Industrial Engineer" in a professional context if you aren't a PE, but there isn't a practice restriction (at least that is how I interpreted it, because I don't do either it doesn't really affect me).
That's certainly the case for systems engineering, which feels related to IE, but IE has a PE exam and systems engineering doesn't. You look at the projects that systems engineering is applied to, and they're certainly the sort of critical things (like aerospace) that you would want oversight over. I guess those in charge see the systems engineering trade association handing things fine without NCEES getting involved. Long live the industrial exemption I guess.
I'm curious to see what happens to software consultancies, and if perhaps principals are going to need a PE like you would see at other engineering firms even if they're not handling safety or mission critical projects. A PE certainly helps in qualifying as an expert witness. This point goes towards your concern over scope creep, certainly a valid one.
The FE exams changed very recently - I'm not sure if there even is a general FE exam anymore, though there probably is an FE common core to each exam.
http://ncees.org/about-ncees/news/ncees-announces-changes-to...
http://ncees.org/about-ncees/news/ncees-announces-changes-to...
Hi geebee, its Hung, CEO of Workshape here.
Thanks for taking the time to write in. I'm glad you liked the post. Your response here is fascinating! You've introduced an additional dimension that we hadn't explored: power
Its certainly interesting to compare chartered or regulated professions with software engineering. I share with you opposition to the idea that there should be any body determining who can be called a 'software engineer'. What might have once been a method of quality control, is now simply a method of constraining labour supply, and thankfully wouldn't fly in today's open source era.
The use of job descriptions as a tool for negotiating space and remit is equally interesting! I can see the value as defensive artefact, though it must be pretty tough to continue to be motivated to work in an environment where such a move would be needed. In reality, I suspect most developers would take advantage of a buoyant market and simply leave before ever a move like this ever required.
I think you might under play the risk that job descriptions will not be used aggressively by negative employees. In organisations that have strong employee protections in place, tightly specified job descriptions can be used to the detriment of others. I imagine that certain industries and sectors are often so slow moving precisely because of workers invoke their right not to stray beyond their job description, safe in the knowledge they can then stay behind that signed document and remain immune from management influence.
Thanks again for the comment - lots of things to think about!
Thanks for taking the time to write in. I'm glad you liked the post. Your response here is fascinating! You've introduced an additional dimension that we hadn't explored: power
Its certainly interesting to compare chartered or regulated professions with software engineering. I share with you opposition to the idea that there should be any body determining who can be called a 'software engineer'. What might have once been a method of quality control, is now simply a method of constraining labour supply, and thankfully wouldn't fly in today's open source era.
The use of job descriptions as a tool for negotiating space and remit is equally interesting! I can see the value as defensive artefact, though it must be pretty tough to continue to be motivated to work in an environment where such a move would be needed. In reality, I suspect most developers would take advantage of a buoyant market and simply leave before ever a move like this ever required.
I think you might under play the risk that job descriptions will not be used aggressively by negative employees. In organisations that have strong employee protections in place, tightly specified job descriptions can be used to the detriment of others. I imagine that certain industries and sectors are often so slow moving precisely because of workers invoke their right not to stray beyond their job description, safe in the knowledge they can then stay behind that signed document and remain immune from management influence.
Thanks again for the comment - lots of things to think about!
> What might have once been a method of quality control, is now simply a method of constraining labour supply, and thankfully wouldn't fly in today's open source era.
At least for the US, a professional engineer is personally and professionally liable for their work. I think that's a good thing for safety critical projects.
At least for the US, a professional engineer is personally and professionally liable for their work. I think that's a good thing for safety critical projects.
Sure - I was thinking more along the lines of accountancy, law and other professions of that type, rather than engineering. Point taken though!