自下而上
上周开会，老大说了一句话「很多事都是自下而上的」，印象很深刻。之后就时不时在想：什么事该自下而上，什么事该自上而下？一般情况下，作为老大，眼界见识一般都会更高一层，获得的信息也更全面更及时，能自上而下的做一些战略性的或重大问题的决策。但是当老大自上而下推动某个事，但下属并不认同这个事，该怎么办？抑或相反，首先老大坚持的一般一定是“对的”，下属就要想想该怎么调整自己完成上边任务。再说“自下而上”，很多具体的问题是需要自下而上的去反馈和推进的，但应该怎么做其实比较麻烦、考验你的处事能力。另外作为下属 是不是该自下而上 提出或推进一些重大问题，这个更难把握，把握好不要给老大留下眼高手低的感觉。
如何沟通与做事
举例：
某某沟通能力极好，非常会照顾别人的想法，绝不会直接否定别人，也不会说出让别人感觉不愉快的话，会向别人提出自己的建议，但没有一点强制或让人不悦的语气。
遇到问题或矛盾，习惯性的口头禅是我们先聊聊，或我们找某某人、某某老大先沟通沟通看看。
在各种会议等场合都能表现得积极主动，顺应场合里的老大或重要人物的意见，再提出自己的建议。能迅速看清形势，把握动向，顺势而为。
在推出新东西、或改变现有方案时，会预先积极、多次的找相关负责人沟通再沟通，哪怕那个负责人其实并不是很懂、也不太关心这个东西。。
这样的同学看起来似乎很完美，表现积极，处事恰当，很容易受到上级的关注与肯定。在团队里一般也能马上担当起小组长角色、分配任务带领队员干活，是大多数一线同学的榜样。
技术保守 vs 技术激进
曾经自己是技术激进派，学习和使用技术都是一味求新，而不管太多其他东西。但现在更看重的是技术的使用场景、业务的可维护性。可以说是进入半保守、半激进状态了。
保守
如果你从一开始做技术就是保守派，不热衷探索或学习新技术，那么真不应该选择做技术这条路。很明显，技术保守派都是“被动”的技术学习者，因为他们的重点不在于技术，只把技术当成是实现产品的工具。另外，不少技术保守派是由激进派转变而来的，比如：
- 对某技术的基础、原理、多种架构模式等掌握的很扎实，会认为许多新技术不过是“换汤不换药”罢了。
- 年纪大了、事情多了、能投入技术的时间少了；想做点跟人打交道的事儿，不想整天默默对着code了，转管理了。
总之一旦技术上松弛下来，就变保守或半保守了。
激进
举例：
某某想法很多，天马行空，不遵守项目代码整体做法规范，标新立异，结果他那一部分项目代码可维护性很差，接手人去填坑，吐槽却又可能被不明真相的老大怀疑这个接手人有问题？
技术激进的“挖坑人”通过各种途径不断向同事兜售自己的新想法及相应实现库，得到老大的注意与好评，甚至把其推出的东西作为部门重点产出来推广。但其实创新(特别是很特立独行的创新)成功的概率比较低，结果就只是看起来或听起来很美，实际不好用，而这些只有身处第一线实际使用的人最有真切感受，脱离第一线的老大的感受或判断很大可能是不对的。
这里并不是完全否定这位激进派挖坑人，他这种创造创新精神还是很好的。可能只是因为他创造出来的东西，在别人眼里并不是像他自认为的那么好。他还需要耐心地好好打磨，或者他这个东西本来就是个败笔、该直接停掉，而不是自认为很不错、着急的马上推出来。（但在KPI压力下，即便是注定失败的东西，也需要含泪做下去，不然就是没结果，后果很严重）
另外对于激进派来说，可能因为要实现自己的“创新”想法，比较容易就忽视这种情况：在某个业务上使用的技术应该保持一致性，最好的可维护性，尽量低的维护成本。创新想法可以在一个新的项目里得到实施，但不应该在已经架构好的项目里横插一杠，导致维护成本攀升。
关于创新
技术上的难题都不算什么，难的是如何改变别人的固有观念并让别人接受新思维新方法。
不要让已经熟知的东西，成为自己前行的障碍。
以上两句话没有错，不革新没创新就不会有持久的活力。但感觉有些前提：
- 像你从没自己从混乱中尝试实现过组件化，就直接把react组件化方式奉为圭臬。
- 像你从没使用过svn，但听说别人使用git非常的好，就认为不用git就是落后。
- 像你从来没用过或只是很简单地用过rest而从没深入挖掘，但听说某某技术代替rest能做的更好，就开始盲从甚至深信不疑。
这种「求新、用新」，并不是创新，反而很可能会限制你的思维，限制你的创新。
因为你会觉得这些新的东西都做得很好，都把问题解决了，潜意识里你认为这是最好的解决方案，而实际上它只是解决方案的一种。
因为你一开始就使用上了最新的东西，所以从来不曾真正碰到过、更别说实际感受过老的问题。感觉到的问题少、可能就直接导致你很难有更好的创新了。