4 ms·
This is totally off topic, and might be considered a rant, but I see this from time-to-time in startup land. Not understanding titles. First, this is for a "v
by fingerprinter 13y ago
This is totally off topic, and might be considered a rant, but I see this from time-to-time in startup land.
Not understanding titles.
First, this is for a "vp of engineering" that is "hands on". Are you really looking for an architect that codes? Perhaps a Sr. Engineer/Team lead? Do the engineers directly report to this "vp of engineering"? What happens when the team gets to big?
Second, you are locking yourself into something prematurely. If you want someone hands on with management experience and capacity to grow into a future leader, state that and start looking. Make your interview quick on the technical assessment, heavy on the social and ask "what would you do in ..." or "how would you handle this ..." type of questions. See if the person has 1. experience 2. common sense or 3. good intuition on process/people.
Lastly, what does the rest of the company look like when the VP of Engineering clearly has an inflated title. Are all the C level/VP level people equally inflated?
Anyway, sorry for the rant. It seems a common occurrence in Startupsville to see people running around with titles that mean nothing for the sake of having the title.
"Oh, cool. I'm the VP of engineering at blah blah".
"nice, what do you do everyday."
"Oh, you know, code reviews".
Whatever.
- jacques_chester 13y agoMichael O'Church observed that if you're at or near the ground floor of a startup, titles are easier to get than money or equity. Which seems harmless, but if and when money starts flowing, something primitive in the status=money&equity hindbrain clicks and such a title makes it easier to negotiate for a better deal.
- bgilroy26 13y agoI agree, an organization that views titles as cheap/free either does not have the imagination to forsee the scenario you describe or they do not seriously expect to grow.
- deleted 13y ago[deleted]
- kamaal 13y ago>>First, this is for a "vp of engineering" that is "hands on". Are you really looking for an architect that codes? Sorry but why can't a VP of engineering be somebody who should code(even if occasionally) or some who could be competent at a code review. Its precisely this kind of attitude that gives ammunition to the MBA culture of appointing people who are clueless about their current job to manage the best people under them. The net result is getting people appointed who know nothing about the people they managing, or the line of work. And just take blanket common sense based decision which most of the times are wrong with regards to the domain they lead. Regardless of who you are- architect, VP or whatever fancy title. If you claim to be the leader of a group of people with some specific skills you should be somebody who at the very least has mastered those skills. According to me anybody who claims to lead a group must be the best among that group, in the job that group performs.
- jacques_chester 13y ago> According to me anybody who claims to lead a group must be the best among that group, in the job that group performs. I think this is an error. Taking your best coder and then spending their time on not-coding is wasteful of their talents. Furthermore, insofar as you create competition to hold that position, you're creating a destructive work environment. Software development is a cooperative activity that can't be efficiently partitioned.
- kamaal 13y ago>>Taking your best coder and then spending their time on not-coding is wasteful of their talents. Or the way I look at it, such a guy in a leader ship position can mentor young passionate folks to be just like him. >>Furthermore, insofar as you create competition to hold that position Having competent guys compete for a position is far better than promoting a total idiot to lead such guys. >>you're creating a destructive work environment. How is appointing a competent guy creating a destructive work environment, and appointing an incompetent guy not creating a demotivating environment. Most demotivating part of my day is when I spend time with my higher ups, explaining them some very basics things like SQL or regular expressions or about network call latency which most of the times they have no clue of. Many times its so bad, you really have to talk to them like you talk to your 9 year old nephew and even after hours of explaining things are so bad they can't really get simple things like the difference between a DOM parser and a SAX parser. I am not saying the guy must code like a champion 24x7. But he should have atleast been some one who has built a thing or two under tough demanding deadlines. Some one who has leaned stuff doing it by experience and not just some guy whose only known accomplishment is being at the right place at the right time, riding an economic wave or being some god father manager's yes man. >>Software development is a cooperative activity that can't be efficiently partitioned. Exactly that is why we need one of us to lead us.