Ask HN: Direct report is a senior beginner
14 comments
[Random advice from the internet]
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.
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.
I dunno I'm kind worried about this for myself. I was a Senior Engineer, I went to get bachelor's at a top-10 during the Pandemic. I'm about to graduate and I'm stuck in no mans land. I got grilled just the other night in my first interview in a long time and it sucked. I've been doing freelance and other work to keep my skills sharp but it isn't the same as working everyday of the week full time on code. I've been in school 3 years. It sucks to be the Senior Jr. anybody in the position should just be a senior or Jr. not this ungodly crossbred experiment. I'm for cutting the dude a bit a slack, but that's from someone stressed out in his position.
You were brought in to make the team perform. What does that mean to the people who brought you in? How will they measure it? What tools did they give you to make it happen?
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.
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.
If everything is really true and you have been able to assess correctly, this person sounds like someone who doesn't have X years of experience but more like 1 year of experience X times. Huge difference.
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.
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.
It sounds like you've already made up your mind. Maybe you should talk to your manager about why you haven't fired him already. Maybe he has more seniority than you in a way.
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.
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.
One idea might be RFCs. Instead of telling him to go solve a problem, ask him to investigate and write a proposal for fixing it. Add some requirements such as proposal should have one ideal fix and two alternatives that require less resources. Engineers want to do ideal solutions even if they are cost prohibitive.
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.
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.
You can't let him "go into a cave" and then come out with something lacking after a bunch of time has passed.
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.
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.
The phenomenon has a term: https://daedtech.com/how-developers-stop-learning-rise-of-th...
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
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
It can be challenging to manage a team with diverse skill levels. Patience and clear communication are key when dealing with a team member displaying both junior and senior traits. Setting clear expectations and providing guidance are essential to helping them grow. To channel their expertise effectively, consider mentoring or pairing them with experienced colleagues. As a result of time and support, they can develop into a valuable member of the team.
It seems you have three choices:
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.
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.
Can you elaborate on what you mean by "really complex solution"? It is well-written/designed, but over-engineered? Or is it poorly done and subsequently hard to read + maintain? Or is it moreso an issue of documentation?
What exactly is your plan OP?
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
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
Sounds like a company where they don’t like PIPping or firing people.
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.
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.
I’d start with the reason he doesn’t ask questions, not with “time to adapt”. For some reason he trained to sit in his cave and solve a puzzle based on uncertainties provided. This can be a sign that previous problem staters were incompetent and non-communicable. I can see what it might do in 7 years. “Did what followed from your stupid requirements, now figure out yourself” mode.
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?