What is a Job Description(JD)?
The job description is a detail of expectations to be fulfilled through the job role. It is a comprehensive list of tasks and requirements the person appointed for the job is expected to fulfill. Usually, these details are hard to put into a few lines of requirements for the JD.
In the software domain, the origin of the job opportunity is in the software system being built. But the details of the software system or components are rarely shared in the Job description. The software engineer appointed for the job would likely do much more than just what is mentioned in the job description. Sometimes, it may be very difficult to fit the actual work related to building the complex software system into exact requirements which can be fulfilled by one person. Hence, usually only the basic and most important requirements for the job are added to the JD.
JD usually includes
- A title
- Number of years of experience
- Must have skills
- Knowledge and experience of some important tasks to be performed by the candidate
It is really not known how the generic JD is prepared and how it originates and evolves. But since its origin is at the source - “Software being built”, the JD travels through various life stages and through various groups and departments within the organization.
It would be nice to hear from the people in the organization where the JD is actually born. By ‘born’, I don't mean ‘written down on paper but I mean where the first set of requirements originated and formed. The following questions are worth pondering over.
- Is JD just a Snapshot of the requirements?
- Seldom written by the owner (of requirements)
- possible reasons (lack of time, lack of interest, the lowest priority task, this is not my work/KRA)
- Leakage in capturing the requirements
- Who are all the stakeholders at JD’s birth?
- Who is responsible for taking care of the newly born JD? Is it Human Resource (HR) or the Hiring Manager / Hiring Team?
Whether the hiring team takes care of the newly born JD or the Human resource, it surely gets a name.
- Lucky ones get standardized names like "Software Development Engineer," "UX Designer" or "Backend Engineer"
- Rare ones (niche skills) get specific names like "Query Optimization Engineer" or "Compiler Engineer"
- And then there are common names like "Solutions Architect." Unless there is strict binding between title and requirements in the JD, interpretations may go wrong
Solution: Can the hierarchical approach help in the case of such titles? E.g.
- Solutions Architect
- Pre-sales Solutions Architect
- Post-sales solutions Architect
- Software Solutions Architect
- Product Manager
- Inbound Product Management
- Outbound Product Management
There are some JDs that get names like ‘Data Engineer’ but the requirements mentioned in the JD would point towards thinking that the role is for a ‘Backend engineer’ with strong programming experience. Some JDs get the name of the team for which the candidates will be working. Such JDs require a deeper level of understanding of the actual requirements and sometimes need to be re-christened at a later stage.
Infant JD is the most flexible one. It is the best time to revisit JD and understand the gaps in the requirement and check whether the requirements are clear.
- Nurtured by cross functional (non-parental) teams
- Original requirements are embedded in a format (so that it looks like a JD)
- Put on layers of generic words (related to culture and ethics) e.g.
- empathy has become a hot requirement, isn't it? believed! If not, then can it be mentioned as the first item on the mandatory skills? OR in the title itself like “We are looking for an empathetic Software Architect”.
- How to interpret good to have skills?
- Are they good to have or the necessary ones?
Solution: Can we have two sections in the JD?
- Mandatory Skills
- Good to have Skills
- In resultant, JDs become subsets or supersets of the original requirement | At times they completely lose their originality/identity
It is really important to know whether the JD reaches the intended candidates most suitable for that Job. Once it is posted, it traverses a stage where it is either interpreted or misinterpreted by various stakeholders including Talent sourcing members who find the candidates suitable for the JD, Human resources who approach the candidates, and the candidates who read the JD.
- JDs are on a path (they are hosted/ posted/ circulated)
- Interpreted by different stakeholders in the process
- At times (or a majority of the times?) overlooked by prospects for the primary requirements
Solution: If reading takes too much, can there be audio/ visual JDs precisely talking about
- Who we are
- what we are looking for and
- What will you do (get to do) if you join us?
Young or dead
Some fortunate JDs have a long life because the requirement keeps evolving along with the stakeholder’s understanding and the JD lives longer and gets better. Some unfortunate JDs do not live up to the expectations of all the stakeholders and are never updated.
- A JD revisited and reviewed as per the changing requirements can live longer
- JD without maintenance would become obsolete soon
- please find out if anybody did a performance analysis of a JD where performance is measured in terms of response to the JD
It is really important to know the significance of JD in the life of its various stakeholders. Some candidates would be interested to ask for the JD and they seriously read it in order to understand the requirement and to find out whether the work would be of their interest.
These questions can be worth answering
- "I give you a JD, you give me a resume" -- handshake, is that the primary goal in the life of a JD?
- Who reads the JD? The guy you reached is doing product management for over 15 years, why is he asking for JD? He knows what a product manager does.
- Everybody expects a perfect match, however precise description of a perfect match is rarely written down. Well-written JDs are a rare breed. What is your preference? A lean JD, a Fully Featured one, or No JD?
At least I would like to see a JD! - this would be an ask from the candidate. So is that the only reason for writing a JD? So that some JD can be shown to him to keep the conversation thread going?
It is important to check whether the requirement captured in JD is really what is gathered at the beginning. Is the JD reflection of the understanding of requirements of all stakeholders and mainly the hiring committee where the JD originated? Some JDs evolve with time. Shouldn't they be updated from time to time?