Hacker News new | past | comments | ask | show | jobs | submit login

I can relate to this, but I can also relate to the other side of the question. Sometimes it isn't me, its you. Take someone who gets things done and suddenly in your organization they aren't delivering. Could be them, but it could also be you.

I had this experience working at Google. I had a horrible time getting anything done there. Now I spent a bit of time evaluating that since it had never been the case in my career, up to that point, where I was unable to move the ball forward and I really wanted to understand that. The short answer was that Google had developed a number of people who spent much, if not all, of their time preventing change. It took me a while to figure out what motivated someone to be anti-change.

The fear was risk and safety. Folks moved around a lot and so you had people in charge of systems they didn't build, didn't understand all the moving parts of, and were apt to get a poor rating if they broke. When dealing with people in that situation one could either educate them and bring them along, or steam roll over them. Education takes time, and during that time the 'teacher' doesn't get anything done. This favors steamrolling evolutionarily :-)

So you can hire someone who gets stuff done, but if getting stuff done in your organization requires them to be an asshole, and they aren't up for that, well they aren't going to be nearly as successful as you would like them to be.

The other risk is of course the people who 'get a lot done' but don't need to. Which is to say they can rewrite your CRM system and push it out to the world in a week but only by writing it from scratch.

Word f'ing up. I was recently fired from a remarkably relatable situation where a hot ninja startup had no effective intake process, so for orientation I had one pair-programming episode regarding an intensely technical internal aspect of the application before being sent off to fend for myself in their repository. Couple this with an office and project management style predicated on "who can interrupt the loudest?", having multiples of these conversations occur simultaneously, and an absolutely open office plan.

But hey, the CEO had sold a previous company for good money so this means he knows what he's doing. I'm sure they'll be a huge success.

I'm not saying that I'm God's gift to college-dropout programmers, but I'd never had a problem succeeding in a job until this one. In reaction to this state of affairs I had considered that maybe I need to be at a huge company that has better processes, but your Google tale says maybe otherwise.


I feel you. I had an identical experience last year around this time. Wasn't a startup situation, just a very small shop run by a hot ninja who was trying to palm off a quarter of a million lines of undocumented byzantine code without bothering to mentor or even explain the business processes this thing was designed to satisfy. Bleh.

I was able to land a gig with a small shop doing work for some incredible clients filled with brilliant people that know their product back-to-front and management that polls the developers for input throughout the project life cycle. Needless to say I've never been happier.

Indeed. In my 10+ years of working at various companies I've found that company size doesn't really indicate how well they do process. The good thing about smaller companies though is they're a lot more agile, i.e. able to improve process, than the larger ones. Don't bet on huge companies either. My plan now is to formulate the most incisive interview questions I can if I go for other jobs, to try and get as good a feel as I can for somewhere's culture and process. It's not easy though as sometimes a company's interviewers are as full of BS as the recruiters selling you to them. :/

since there seem to already be quite a few employees when you started I think most of the problems there was a culture clash. coupled with the fact that they did not properly educate you on how they operated. I'm not judging different cultures but there are plenty of steps a company can take to make sure new hires fit.

If by "quite a few" you mean "less than 10," several of which had previous worked together, I'm not sure that it qualifies as anything more than process ignorance.

So you can hire someone who gets stuff done, but if getting stuff done in your organization requires them to be an asshole, and they aren't up for that, well they aren't going to be nearly as successful as you would like them to be.

You've sort of nailed it. Also what I see is, how much people are addicted to the NIH syndrome. They have a ways of working which they won't change, adapt or even agree debate for their own good.

The way I see, too much or too little process are both equally dangerous. The key is neither to over play nor under play the game. Too little management leads to wandering in the wild with no goals, plans, tracking and destination. Often overly delayed projects.

Too much management gets in the way of achieving what would have been even easily possible.

After all the analysis I can say, sure you may want to hire every smart guy on the market. But you must also know to manage them. Bunch them together, create a positive environment and enable them to be as much productive as they can be. Good people need to be taken care of, Senior developers/architects even though not managers need to have some people skills. Its simple, if interacting with people is a part of your job.. People skills become part of your job.

To be good alone is not sufficient, if you are good alone you can probably get a maximum of 9 hours worth of job done everyday. But if you can manage 10 such brilliant guys you can deliver 90 hours of such work every day. But that requires spotless planning, tracking, course correction and most important creating an environment where such people can be productive.

Nothing big in software these days can achieved without team work. If a person is not good with teams, may be its time for him to look somewhere else. Being a jerk, rude and arrogant with junior developers may help you give a false sense of superiority but that won't bring you success.

"Google had developed a number of people who spent much, if not all, of their time preventing change...The fear was risk and safety."

I think you nailed it here. But something to realize is that this is not unique to Google, this is true in any large corporation.

The issue is that as people develop careers within the corporation, they become interested in what is most politically expedient for said career. This means they become very averse to any situation where the individual might personally look bad.

This means that aggressive projects which could have a high level of reward and equivalent risk for the company get waylaid disproportionate to their overall risk/reward ratio.

I think your point about people not understanding the systems that they are working on compounds this idea, as it makes the risks of changing a system appear higher (because they do not know the system).

Even worse is when an entire company's strategy revolves around risk aversion. Risk management is one thing, but avoiding any possible loss in any area can make for a pretty soul crushing job experience for people who like innovation and change.

On the whole I really agree with the writers stance. But in the spirit of getting shit done, you gotta start somewhere. I personally have a tendency to do too much or start something that should never have been started on in the first place.

A start-up environment and Skynet are quite different with different objectives.

"So you can hire someone who gets stuff done, but if getting stuff done in your organization requires them to be an asshole, and they aren't up for that, well they aren't going to be nearly as successful as you would like them to be."

So very true. I'm in this situation at my current job: I was hired as a dev, was told to fix organisational things by senior management and am now meeting resistance and roadblocks for various reasons. I'm a dev, and I'm not an asshole, and I also have no authority to steamroll people. At first I felt empowered but lately I've just felt bogged down. It's a sucky feeling.

@ChuckMcM: I guess you've nailed it.

It pretty much depends on what are you looking for: a procedural executant or a project developer. A project developer can execute very well for the first couple of times, but expect from one to get bored with the same speed.

You have to find the right tasks for these "very smart people" instead of hiring them to do the wrong job. The alternative is to hire really dumb people, at least they'd never be able to do anything more or better than what they're told.

I 100% agree with this. Sometimes it is the wrong manager or the wrong environment which makes a productive person less so. In this case the person and their manager either need to work it out, or the person may need to leave the team, group, or company and find a home where their talents can really shine (or, if the manager does this to everyone who works for them, hopefully their manager realizes this and fixes it).

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact