Ceci n'est pas un job
So, for all this discussion about full stack developers, front end developers, software engineers, webmasters and ninja guru rockstars who should you actually hire and what should their titles be?
After all, the job title is not the job.
I think this is where we can easily get distracted by social media chatter about job titles.
Public discourse has a bad habit of reducing the role of context to almost nothing. It’s far too easy to express an opinion that was formed in context, but is interpreted generally.
Instead, think about the questions below and you’ll be well on the way to cutting through the FUD. This is what you can say after ‘it depends’ in response to someone asking for your opinion on full stack developers.
Where is your product or project in it’s life cycle?
Early-stage experimental stuff may be better suited to fast-moving generalists, but an established, stable product in maintenance may benefit from some specialised, focused improvements.
What constraints are inherent in the architecture and development environment?
A monolithic Node.js application may be better suited to full stack developers than a complex micro-services architecture utilising multiple programming languages and environments.
What’s the current distribution of skills in the team?
If you already have very clear lines between skill sets in the team, does it help to maintain this or is now a good time to review it?
What’s the scope of design roles?
Another oft-forgotten impact is the role of designers. Do they get deep into front end code or are developers responsible for implementing UI designs? And is this something you want to change?
What are the leadership and management reporting lines?
Front end developers working in product organisations often find that they have multiple stakeholders to answer to: engineering, product and design leaders can all be involved, and sometimes marketing, sales and customer support too.
Are there separate ‘platform’ teams? What about a design system team?
The presence of cross-cutting platforms teams can also have an impact. Once you move beyond a single squad responsible for a whole product, there comes a point when it makes sense to have these horizontal teams. They tend to focus on back end platform systems and developer tooling, but increasingly design systems can be included in this bucket. This will have an impact on roles in product delivery teams.
What’s your company’s hiring culture?
Are your teams 100% co-located or full remote? What support is there for those with dependents? What’s the training and personal development policy? All these things can have an impact on how you hire and how you present roles publicly. Job ads with a giant list of must-haves can put off people from under-represented groups.
What’s the employment market like?
If you are based in a small town and are looking for 20 local rock star unicorn full stack developers to work on-site with a limited salary offering, you’re probably going to be out of luck. It pays to do some research into the hiring market you are in to understand where the challenges are.
These are just a few things that can impact job design and hiring.
First, consider these questions, then create a role description and a person specification. Appropriate job titles should emerge from that.
Realistically, you may have very limited control over resourcing and hiring policies and job titles. In that case, raise these questions with your manager or HR department.
OK, that’s a long email for a Friday. Have a great weekend!
All the best,
– Jim
