We need a senior developer but ideally we’d like to save some money by grooming a junior developer who’s getting close to senior. That would also give us the advantage of making our senior developer someone who really knows our product inside and out. For anyone who’s done this before, what do you look for to confirm that your junior dev is ready to step up to senior?
Here's a paraphrased model I've seen used before. This is for a larger organization - dozens+ of devs and a product with years of development under it. See if it helps.
In general, you'll see an expansion in scope and influence as you go up. Transitioning from mid to senior in this model is transitioning from performance being judged by "what I do myself" to performance being judged by "how I influence what others do".
If your guy is already doing the stuff under the senior category, promote him. If not, tell him what's under there and wait for him to grow into it. Then promote him.
Edit: Actually - I made a mistake. Promo usually happens when the dev shows about 50% of the qualities required for the next level.
Junior: "Give him a spec, he'll get it done."
Competent coder and/or shows aptitude to become great. Needs some guidance on translating specs to code and to make sure tech decisions fit in well to the overall design of the product. Will participate in product level discussions relating to his/her areas.
Mid: "Give him a solid idea of what's needed, he'll figure it out."
Excellent coder. Can make informed design decisions that fit in well with the overall design of the product. Will start making technical decisions related to his/her areas. Begins to influence design discussions made in related areas of the product. The buck stops here for their pieces of features.
Senior: "We're pretty sure this is what we want, give it to him to figure out the details."
Makes implementation decisions deeply influencing his/her areas of expertise, which encompass major feature areas. Starts to make decisions influencing the future direction of areas of expertise. Is sought out as a resource by those who own related areas for consultation and advice. The buck stops here for their features.
Architect: "The guy the seniors go to see what's coming next"
Has product level technical influence. Makes technical decisions that can make or break the product. The buck stops here for their everything they touch.
I have done this before. You have articulate what you want in terms of leadership and maturity Before you search. We elevated a phenomenal Jr to Sr who was well regarded by his peers and management for the quality of work but he had not internalized how the roles were different and while it did not end badly we had to work through months of drama in all directions. Had we really grasped the leadership skills better we would have either made a different decision or worked closer with him earlier to groom those skills. They must know his is a leadership role not a coding role only. They must have respect of the peer group and one that others seek out for advice and guidance.
Since I was promoted twice to the senior developer (in two different companies) and also twice to the team leader, I will tell you from my perspective of software developer. The few main reasons that I got promotion was my:
It would be easier for you if you split developer aspects in following manner (this is something that senior should have)
Tech skills: profound knowledge of technology, design patterns, architecture designs , services designs etc.
Tools: knowledge of using (and even set up) of development tools. For example for Continues Integration and/or continues deployment (e.g. Jenkins, Sonar, BitBucket, Fisheye etc.)
He or she needs to be able to finish 90% of average tasks he/she is assigned to (for 10% there is need for brainstorming with architects or solution designers).
Someone will say that communication skills are not crucial to senior developer. I wouldn't agree. As a senior developer, one should communicate effectively with clients, Product Owners, business analysts etc. If senior notice challenge or risk, he/she needs to address that as soon as possible. I saw a lot of developers that report this kind of thing too late (sometimes they don't tell anything until day or two before sprint ending). Senior should know that if you going to fail, you need to fail fast.
This is from software developer perspective. I can imagine that it is similar for hardware developer also, or for any other developer.