This team is small and one member has been working at this company for 7 years. He was transferred from a few areas and ended up in this team, where management mostly left him alone.
On one hand, he requires a lot of handholding if you want to ensure good deliveries. You have to communicate extremely well or the tiniest uncertainty will push him into creating a really complex solution (this happened a few times in a couple of months). In this regard, he displays the knowledge of a junior engineer.
On the other hand, he has many years of experience and the "senior" title. The problem is he doesn't know what he doesn't know and just assumed things. Often, he will figuratively go into his cave and come out with something that lacks tests, documentation, doesn't meet performance, will require a lot of babysitting when it's deployed to production, etc... and he gets angry when people start asking questions (that's my job so he's angry at me often).
So he's an advanced beginner, for a lack of better term.
Any advice? How much time should I give for him to adapt?
Everybody doesn't know what they don't know.
Don't be a junior manager. You were hired to manage the team. It's hard work. That's why the company gives you a paycheck. Holding an a team member in contempt is an indulgence in an unprofessional behavior.
But management is the art of making other people's jobs easier, not making your own job easier. Give the report everything they need and more. That's good management.
The proof of the work is not test coverage. It's the profitability of the company. Test coverage is not the proof of good management. The proof is team dynamics. If you don't respect your direct reports, they are not the big problem.
Good luck.
It's a small team that is known to be in trouble. Does the team know this?
Go to the team and explain the situation and ask for input about what they think should be done. Guide the team to a shared sense of the values you're all going for. Is it delivering on time? Best quality? Calm work environment? Surviving til retirement? ...
These values will lead to agreed to team standards. Anyone not getting on board with the team standards needs to go. You're involved in a team effort. Team members will show they're on board through their work.
It sounds like you have a particular problem reviewing/accepting work. Establish a procedure. It's best if you can point to best practices, such as
https://www.codingblocks.net/podcast/googles-engineering-pra...
Depersonalize the process. It's about the work. Either the work passes muster or it gets held up until it is acceptable. Since your team has not been performing, expect any non-performer to argue that the reason they're not getting stuff done is that you are a perfectionist or some such.
This guy gets angry. That is a problem, is completely unacceptable, and shows a real lack of maturity. Make sure you remain calm and do not respond to it. You should make sure to document this behavior, let him know it is unacceptable, and make sure your management knows you're dealing with a person with anger management issues.
The worst combination is someone who has been out there but still cannot be relied upon. They usually are not coachable by now. Usually.
So I am afraid you can't do much here except letting them go. If you don't have authority to fire, then you need to talk to your management and have an honest conversation. After all, you are hired to fix this team.
Also, be honest about the situation. It comes off as partly that you absolutely do not get along with him. But you only mention performance defects. To the degree that it makes it sound like you are looking for more of them to list to distract from your personal disagreement.
Either he can be fired, put on another team, you move to another team, or you resign. Need to discuss with your boss.
This way then you can point out anything that he missed and select a practical solution.
However, ideally, you would want everyone to write RFCs for any larger project or that engineer will feel targeted.
Given what you know about him, it's your job to hold him accountable, keep an eye on him, and make sure that _all_ aspects of the project are being accounted for. It's not going necessarily going to be fun or comfortable for anyone, but you should err on the side of micromanagement until he is performing at a high level.
You probably also need to be very clear about the totality of what is expected - yes, a cool design is great, but it must have tests, it must be communicated to others (be that by documentation, a presentation, training, etc)... and no amount of "design" or "don't have time" excuses will substitute for these aspects.
Without referring to the article, my advice is to set hard quality criteria for his work. Also you could insist on test coverage and write acceptance criteria for his tasks. However, I try to never judge anyone easily and I believe even the most stubborn person can be helped to improve. If you could show him what he lacks - in a nice way of course - you might be surprised how much people can improve and advance.
I view the "Beginner Expert" not as a failure of character but more like a long term depressive episode
1) Fire him. 2) Convince him to join another team within the company (which is presumably how he ended up in his current position). 3) Do the work to manage his work.
Here's the common way to work through this scenario:
Introduce Definition of Done for all coding tasks
Introduce NFRs
Introduce 2-week Sprints
Introduce product owners, standups, demos, retros
I’ve been in your situation, and IMHO there’s no amount of time that will fix it. He’s reached his ceiling.
Do the hard thing. Or transfer him to a yet another team.