VC: How a great entrepreneur deals with complexity(freddestin.com)
freddestin.com
VC: How a great entrepreneur deals with complexity
http://www.freddestin.com/blog/2009/11/how-a-great-entrepreneur-deals-with-complexity.html
2 comments
Push for quality, push for creativity, and push for time -- in that order.
I think its easy to try to push to get things done fast first, especially for non-technical managers, but this can be really counter-productive because it starts to disenfranchise developers as the work becomes more drudgery and harried tedium. When you push for quality features and creative solutions first and only then push for time, the deadline crunch can really kick most people's minds into high gear, and they can generate elegant and satisfying results.
I think its easy to try to push to get things done fast first, especially for non-technical managers, but this can be really counter-productive because it starts to disenfranchise developers as the work becomes more drudgery and harried tedium. When you push for quality features and creative solutions first and only then push for time, the deadline crunch can really kick most people's minds into high gear, and they can generate elegant and satisfying results.
Yes, lying is always terrible. However, when I read that phrase I think about leaders who inspire a team to achieve better quality. Better design, better user experience, and so on.
Lots of people respond well to that kind of atmosphere.
Lots of people respond well to that kind of atmosphere.
I agree with this one:
"Ignore the first request for everything. If it's really important then they will ask again"
"Ignore the first request for everything. If it's really important then they will ask again"
It may be true, but it is a technique predicated on a certain lack of respect for your subordinates. I don't much like that.
I'd say it's just a way to identify a degree of necessity.
Humans are not machines - when a request times out, we don't just resubmit and try again, there are other consequences to this failure to respond.
The lack of respect for your peers and subordinates is one.
The lack of respect for your peers and subordinates is one.
You don't want very passive people working for you. You want people who can route around what you're busy doing and manage their own projects.
If you are absolutely critical to whatever they need to do, they have to be managing you about it, not just sticking more work on your lap and waiting for it to bounce off. Which means more than sending an email and never following up.
If you are absolutely critical to whatever they need to do, they have to be managing you about it, not just sticking more work on your lap and waiting for it to bounce off. Which means more than sending an email and never following up.
i am only refering about requests that involve more than one person and not about multiple requests from one person. E.g. A feature request by more than one person.
This works great for programmers as long as it makes sense and you're brutally honest with them. As soon as programmers realize they're being "gamed", it stops working and will never work again.
I once had a leader who constantly moved deadlines up to push us. Being the aspiring overachievers the we were, we always did whatever it took and never missed a deadline.
Then the leader had to push a deadline out 30 days for reasons unrelated to us, but he never told us. He just figured that we'd push as hard as usual and be done 30 days early. We learned the new deadline from a third party and hit the real deadline, not the "30 day early" one. After that, there was nothing he could ever do to push us again.
Leaders, beware. Once you blow your trust with us, all your tricks become worthless.