Comment by fingerprinter | Hacker News Reader

Comment by fingerprinter | Hacker News Reader

Parent Full thread

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.

Michael 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.

I 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.

>>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.

> According to me anybody who claims to lead a group must be the best among that group, in the job that group performs.

I'm sorry, and this is going to sound harsh, but this is awful, awful advise. And pitifully shortsighted.

So, a manager that leads developers should be the best developer?

What about a director that manages developers AND architects? Or developers AND QA? Does the director have to be the best at both those functions? Or some "best of the combination" of the two?

What about the VP? Now the VP of engineering likely leads (in a large enough organization) directors of QA, engineering, product, maybe some other roles like IS as well. In turn, they might lead managers or some function directly. Is this VP the uber of all those roles?

And then we get to the CEO.

No, this is terribly short sighted. Amazingly so.

In sports is quite commonly known that the best players usually make terrible managers. There are quite a few theories on why, but the end result is that very few great players have been great managers (oddly enough, MLB has more ex-player managers than the other leagues, and is more immune to the above criticism...again, many theories why). In fact, quite a few of the best managers in some sports are typically borderline players, if they played at all. Using your "best should lead" theory, only the best ex-basketball, ex-football, ex-baseball players should be running teams in the NBA, NFL or MLB.

No, the best leaders should lead. Doesn't matter if they are not the best developers And how good a developer one was becomes irrelevant past "team lead" or manager at best.

> 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.

>>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.

> How is appointing a competent guy creating a destructive work environment, and appointing an incompetent guy not creating a demotivating environment.

Because you based it on competition.

Holding that position, which presumably comes with better pay, perks and a résumé line item, is a zero sum game.

Everything good that programmer A does for the company now directly disadvantages programmer B and vice versa.

Do you think this creates conditions conducive to cooperative efforts like developing and maintaining complex software?

If you want to pick a leader, pick a leader yourself. Boohoo, it's hard and you might hurt people's feelings. Well too bad. Picking leaders is itself an act of leadership. Too many senior managers shirk the responsibility of growing a cadre of good managers by connecting it all to numbers that encourage destructive behaviour. It's the lazy and gutless way to lead.

See Measuring and Managing Performance in Organizations for a full enumeration of why having people compete for a tech leadership job would easily destroy any small company.

You would be correct if compensation of any individual in our society would be independent of their title/position in the hierarchy. Unfortunately its not.

Either way competition is inevitable- If its not from the inside, it will be far worse- from the outside. And in most cases companies have to acqui-hire people or purchase out an entire product line because they just can't get innovation out of their own people.

But the sad fact is its not current employees are at fault here. Unless you are super foolish, why should you ever work hard when some guy who isn't doing 1/10th work you do or is 1/100th as competent take all the credit, money and power stealing your work? The net result is no one contributes, the company struggles and buys their life saving kits every now and them from the outside.

And no competent person will accept a incompetent person over them, especially when getting a job or doing a start up/side project is so easy these days. How many times have we seen companies that claim to hire all super candidates with all those algo/ds questions routinely acquire start ups at big prices, yet they can't get something half decent out of their super star regular hires.

If you look down below, you will see it all gets down to incompetent middle management.

>>Too many senior managers shirk the responsibility of growing a cadre of good managers by connecting it all to numbers that encourage destructive behavior.

No, they do it because they know competent folks will grow and become a threat do their positions.

I really think you should read that book I mentioned. It's by Robert D Austin, published by Dorset House.

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.

Why are you doing this? Most "higher ups" I've worked under have nearly zero interest in highly-technical explanations of what I'm working on. Interacting with managers should be an exercise in plain English.

> 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.

Seen way too many of these kinds of management structures. The management decides to appoint the crony as the lead, because picking the best developer is "wasteful" and creates a "destructive work environment". The amount of cringe inducing perversion of logic in the comment above is a tragedy because of its pervasiveness. On the flip side, these kinds of organizations are not too hard to avoid, doomed startups and successful behemoths - both fit these criteria. A smaller company with decent growth is probably the better bet.

What about my remarks is equivalent to "I suggest you pick cronies instead"?

Reply on news.ycombinator.com