4 ms·

understand temporary solutions and the priorities that necessitate them, but don't accept a decision that you feel is wrong without raising the issue and gettin

understand temporary solutions and the priorities that necessitate them, but don't accept a decision that you feel is wrong without raising the issue and getting a better understanding. This is your company (your garden) and if you let people pull in the wrong direction the entire plan will fall into disarray. i'm interested in hearing experiences about what happens when you actually achieve this level of control. I love my garden so much, and have been given sufficient responsibility over it, that I care very much when people pull in the wrong direction. Refusing to accept incorrect decisions -- decisions that will absolutely cause technical debt, overtime, and significant stress and a smaller bonus for us all later in the product lifecycle -- can lead to some interesting and complex social dynamic and this is the biggest thing I struggle with today. Its actually even more complicated because while I feel I am usually correct (who doesn't), there are times when I'm wrong and there are other times where I don't realize I'm wrong.

greghinch 13y ago
I believe Steve Jobs said the reason he took on the role of CEO when he came back to Apple was so no one would be above him when it came to making decisions about the products. My experience has been, when a company is built around a product, everyone at the company wants to think they know what is best for the product, regardless of their actual role and abilities. Installing yourself at or near the top is the only way to actually take control. If you can't get high enough up the ladder in the place you are at, and this is frustrating you, it's time to jump ship and move somewhere you can. Else you will likely become a poisonous influence on the team around you.
nbm 13y ago
This is something I've often struggled with before I joined Facebook, and it's something I occasionally grapple with there too. Like you, I felt I was usually correct, but had come to the realisation that not only was I occasionally wrong in short-term hindsight (just after the fact), but sometimes only in longer-term hindsight (ie, after I'd learned some lessons further down the road). Ultimately, it comes down to trust and teamwork. I had a much longer post, but: a) Make sure you are doing what you believe to be the right thing for the company as a whole, and that you're armed with as much information as is easily obtainable about it to inform your strong opinion. b) Then, if you are able to believe that the people around you are doing what they believe to be the right thing for the company as a whole (even if you might need to remind them that they should do that) based on the information (and you might need to help them understand what you have discovered) and experience available to them, then your life will be a lot less stressful than if you're the guy that feels they always need to steer the ship. It's also something I've learned more and more about leadership and mentoring: a) It's hard to learn lessons if you're not making mistakes. Telling people how to avoid mistakes in one case doesn't help them learn how and whether to try avoid them in future. b) Choose your battles - expend your influence capital on the most important thing, and don't transform from that person that's been a great help in the past to that person who just tries to meddle in everything.
CGamesPlay 13y ago
The best thing I can say is that when interacting with other people, subtle course correction early on has a big effect in the long run. When I've tried to influence other people to change practices (in my case it was building more testable code), I've found that making the right path the easiest path is the best way. There are a lot of ways to do this. Code review is an easy one if you're not doing it already. It gives everyone the power to have influence over the code before it lands in the repository [1]. Building tools that make the right thing easy is also useful. I spent about a year making development tools to enable rapid testing of some of our JS modules, as well as doing a little bit of static analysis to automatically detect and fix certain classes of errors. By doing these things, every engineer gets guided to the right path without needing to reach out to anyone and without a huge cognitive overhead (like reading an interface guideline or something like that). [1] http://www.phabricator.com/docs/phabricator/article/User_Guide_Review_vs_Audit.html#advantages-of-review http://www.phabricator.com/docs/phabricator/article/User_Gui...

greghinch 13y ago

I believe Steve Jobs said the reason he took on the role of CEO when he came back to Apple was so no one would be above him when it came to making decisions about the products. My experience has been, when a company is built around a product, everyone at the company wants to think they know what is best for the product, regardless of their actual role and abilities. Installing yourself at or near the top is the only way to actually take control. If you can't get high enough up the ladder in the place you are at, and this is frustrating you, it's time to jump ship and move somewhere you can. Else you will likely become a poisonous influence on the team around you.

nbm 13y ago

This is something I've often struggled with before I joined Facebook, and it's something I occasionally grapple with there too. Like you, I felt I was usually correct, but had come to the realisation that not only was I occasionally wrong in short-term hindsight (just after the fact), but sometimes only in longer-term hindsight (ie, after I'd learned some lessons further down the road). Ultimately, it comes down to trust and teamwork. I had a much longer post, but: a) Make sure you are doing what you believe to be the right thing for the company as a whole, and that you're armed with as much information as is easily obtainable about it to inform your strong opinion. b) Then, if you are able to believe that the people around you are doing what they believe to be the right thing for the company as a whole (even if you might need to remind them that they should do that) based on the information (and you might need to help them understand what you have discovered) and experience available to them, then your life will be a lot less stressful than if you're the guy that feels they always need to steer the ship. It's also something I've learned more and more about leadership and mentoring: a) It's hard to learn lessons if you're not making mistakes. Telling people how to avoid mistakes in one case doesn't help them learn how and whether to try avoid them in future. b) Choose your battles - expend your influence capital on the most important thing, and don't transform from that person that's been a great help in the past to that person who just tries to meddle in everything.

CGamesPlay 13y ago

The best thing I can say is that when interacting with other people, subtle course correction early on has a big effect in the long run. When I've tried to influence other people to change practices (in my case it was building more testable code), I've found that making the right path the easiest path is the best way. There are a lot of ways to do this. Code review is an easy one if you're not doing it already. It gives everyone the power to have influence over the code before it lands in the repository [1]. Building tools that make the right thing easy is also useful. I spent about a year making development tools to enable rapid testing of some of our JS modules, as well as doing a little bit of static analysis to automatically detect and fix certain classes of errors. By doing these things, every engineer gets guided to the right path without needing to reach out to anyone and without a huge cognitive overhead (like reading an interface guideline or something like that). [1] http://www.phabricator.com/docs/phabricator/article/User_Guide_Review_vs_Audit.html#advantages-of-review http://www.phabricator.com/docs/phabricator/article/User_Gui...