Ask HN: Should Vice Presidents still be coding/in the weeds?
I work for a company that has an Engineering department with about 100 folks total. I am a team lead and am 3 levels below the CTO (CTO -> VP -> me -> my reports). My team is starting a new project next week and my boss (the VP) just announced he will be a developer on the project. He has been involved in the project since the beginning approving all the stories, architectural diagrams, designs, etc (he expects everything to be ran through him first). I haven't work for many other companies so I don't know if this is normal VP function to be this into the weeds. He is like this in other teams at the company, inserting himself into their projects. Is this normal at other companies?
17 comments
How good is he? If he’s VP tier hood at coding, maybe. If he just got promoted up like most, then probably not.
Sounds like the role may be mislabelled if this is what he's doing routinely. I think the key question for me is whether he has responsibilities that are expected of him that he is unable to perform because he is doing this work instead.
Also, does your company have a separate formal architect role? Is it hard gated approval (this doesn't move without my stamp) or is he just keeping an eye on things?
Also, does your company have a separate formal architect role? Is it hard gated approval (this doesn't move without my stamp) or is he just keeping an eye on things?
The CTO seems publicly happy with him since the CTO leans on him more and more. He is doing his VP work during the day, coding for projects on the evening and weekends. Some services, he completely owns. He codes, QA, and deploys them without any other people's inputs.
The only person with an architect title is the VPs right hand man. They were hired at the same time (10+ years ago). The architect never questions the VPs design/decisions.
Yes, its hard gated. This project has been delayed 3 weeks already from starting because the VP has not have the time to approve the designs, etc.
The only person with an architect title is the VPs right hand man. They were hired at the same time (10+ years ago). The architect never questions the VPs design/decisions.
Yes, its hard gated. This project has been delayed 3 weeks already from starting because the VP has not have the time to approve the designs, etc.
Ok, that sounds like a disaster, and the 10 years part sounds like this was a temporary setup for a start-up that has outgrown it.
He's undermining the team's authority on their portion of the work, and it sounds like he's keeping the architect on a leash so tight that career growth is impossible. Additionally, the 3 week delay is inappropriate and evidence that he needs to butt out and learn to delegate.
As there's support from above on this, it sounds like it's unlikely to change until something goes badly wrong, sadly.
He's undermining the team's authority on their portion of the work, and it sounds like he's keeping the architect on a leash so tight that career growth is impossible. Additionally, the 3 week delay is inappropriate and evidence that he needs to butt out and learn to delegate.
As there's support from above on this, it sounds like it's unlikely to change until something goes badly wrong, sadly.
It all depends, I worked for New Relic, and Lew Cirne was known as the "Coding CEO":
https://allthingsd.com/20131024/you-wont-believe-what-new-re...
The real question with title is less what your job responsibilities are and more how broad your impact is. A High level person can be good if the project is tough in some way - requires a lot of cross team collaboration, lots of market risk, specific technical domain etc. New things are hard, think about the fact that a high level execs at one company could be software engineers or "low level" IC's at a young startup. But it should definitely be intentional.
https://allthingsd.com/20131024/you-wont-believe-what-new-re...
The real question with title is less what your job responsibilities are and more how broad your impact is. A High level person can be good if the project is tough in some way - requires a lot of cross team collaboration, lots of market risk, specific technical domain etc. New things are hard, think about the fact that a high level execs at one company could be software engineers or "low level" IC's at a young startup. But it should definitely be intentional.
There are as many different ways to do things as there are people. My take is he is keeping a close eye on you, and if you do well you'll get a lot more autonomy going forward.
But you just can't tell, this might be because he loves the game, it might be because your job is hanging by a thread. Or it might because his job is hanging by a thread. Or the company is on the line and the CTOs job is hanging by a thread.
No matter what, your best path forward is to make this project a success.
But you just can't tell, this might be because he loves the game, it might be because your job is hanging by a thread. Or it might because his job is hanging by a thread. Or the company is on the line and the CTOs job is hanging by a thread.
No matter what, your best path forward is to make this project a success.
Keeping a close eye on me is probably correct. We have had our differences in design philosophies. I prefer simpler design while he likes using all the latest and greatest technology for coding. He always believes his design is the correct way and gets his way since he's the highest person with technical knowledge (CTO is not technical).
Probably you get paid to not have those differences with your boss because everyone rowing in the same direction is better for the company.
Generally in an uncertain and urgent context picking a way of doing things and sticking to it is better than the distraction of debating how it should be done.
A very real possibility is that your boss feels the need to be involved because there’s a likelihood they will be around when you are gone.
My advice is to do things the way your boss wants them done without the friction of your personal opinions getting in the way.
Sounds like you are being managed.
Good luck.
Generally in an uncertain and urgent context picking a way of doing things and sticking to it is better than the distraction of debating how it should be done.
A very real possibility is that your boss feels the need to be involved because there’s a likelihood they will be around when you are gone.
My advice is to do things the way your boss wants them done without the friction of your personal opinions getting in the way.
Sounds like you are being managed.
Good luck.
CTO is not technical?
CTO worked an e-commerce website 20 years ago. Politician since.
No, it's not normal imo - you have 100 people in your engineering department, that's too many for the VP to be touching any code. If your company was only a handful of people, it would have beeen understandable. At tens of employees the VP should know that their time isn't best spent coding, or maybe they shouldn't be a VP.
Maybe the VP wants to code or misses it.
I would take it as an opportunity to have a conversation with them. Discuss the tech stack, and processes you/they dislike or want to do more of. Let them know your expectations too, standups and retros participation are obvious ones.
I hope, you are on your way to making an ally, a more powerful one!
I would take it as an opportunity to have a conversation with them. Discuss the tech stack, and processes you/they dislike or want to do more of. Let them know your expectations too, standups and retros participation are obvious ones.
I hope, you are on your way to making an ally, a more powerful one!
Your VP in particular sounds like a micromanager, though leadership should practice some scuttlebutt every now and then (skip meetings should be semi regular at the very minimum).
Yes, he is a bit of a micro manager. He expects to be included in all design/architecture meetings and expect us not to start/reschedule unless he is there. He wants to review all design/architecture before allowing the project to start. He will randomly call out existing code in our repos and expect us to rewrite it to his standard. He has had us rewrite existing production applications (even though business is happy with it) because the design/code is not to his standard.
Yikes.
I recently talked to a CTO of a large company. He told me that he does where he thinks his impact is greatest. Up in board meetings or with developers - who sometimes are confused a CTO is attending - in architecture meetings. As a CTO for 10+ years I thought up to that point you should never code as CTO. I changed my opinion.
I thought X.
I saw Y.
"I changed my opinion".
Excellent!
Excellent!