对于自己熟悉的事物，人往往更容易注意到其缺点，忽视其优点。与此同时，对于自己所不熟悉的事物，人往往更容易注意到其优点，忽视其缺点。俗话说“距离产生美”，讲的就是这个意思。一个实际的例子就是很多在美国生活久了的人会觉得国内特别好，都是优点，而相比之下美国几乎一无是处，“比中国好的也就只有空气了”。

再举个例子。去年我们家买了个新房子。看房子的时候我们主要关注的是上一个家的几个主要痛点在新家是不是都解决了：洗衣房要在二楼，方便把洗好的衣服拿到衣帽间去；主卧要在房子背向街道的那一次，那样更安静；地段要方便，上下班的路要跟大多数人的方向相反，避开traffic。

等到搬进新家住了一段时间后才发现，新家有那么几个缺点还挺明显的，但看房子的时候完全没有留意到。而且这几个缺点在上一个家里都是没有的:

• 缺点一：新家的手机信号很差。AT&T和Verizon还行，至少有两格。但T-Mobile就不行了，新家里面基本上都是No Service，只有站到窗口才能有一格信号。而我们家都是T-Mobile的，为的是去温哥华、惠斯勒、回国、去墨西哥和欧洲玩的时候国际漫游方便。解决办法只能是装了个T-Mobile的Personal Hotspot。但一旦停电，这个Personal Hotspot就挂了。可是停电的时候正是最需要手机的。
• 缺点二：新家厨房的橱柜都是白色的。很好看。但不如之前家里的棕色橱柜耐用。白色橱柜特别容易沾颜色，烧个什么红烧的菜，翻炒的时候常常会甩出一两滴来。就算不是酱油，就算只沾了一点橄榄油，也是很明显的。上一个家里的棕色橱柜就耐用多了，根本不用操心沾上几滴橄榄油酱油什么的，沾了基本看不出来。
• 缺点三：新家的灶头边上没有一个切菜的区域，切菜要在中间的中岛上干。中岛大是大，但跟灶台中间隔了一个小走道。把切好的菜下锅，都要越过这条走道。这个过程中难免经常掉一点在地上，每次烧完饭都要打扫一下过道的地板。上一个家里切菜的地方就在灶头边上，切好菜直接就边上下锅了，就算漏了一点，也是漏在桌上。打扫桌面比打扫地板还是要轻松不少的。

换句话说，我们在上一个家住了五年，但它的几个优点被我完全忽视了。

知道存在“容易忽视熟悉的事物的优点”的认知陷阱以后，就能够相应的补偿。比如，经常提醒自己现在这份工作的优点，提醒自己现在生活的城市的好的方面。这样比较容易提高幸福感。

//the end

I used to be a M2 and manage a 30 people team. But in 2014, I became a M1 and only manage 3 people. It was a deliberate choice I made. I have been asked many times why I made such a choice, since such a choice seemingly hurts my career. I guess it’s a good idea to write the answer down if it's asked repeatedly.

Here it is:

Azure shifted to the combined engineering model in 2014. Before that shift, we were in a functional model: I was the test manager and I had 30 people, including SDETs and test leads. I reported to a Director of Test, who reported to a VP of Test. The dev manager that I partnered with had 60 people, including SDEs and dev leads. He reported to a Director of Dev, who reported to a VP of Dev. After the shift, all individual contributors were now SWEs (Software Engineer). Their managers were Engineering Managers, who reported to Group Engineering Managers, who reported to a Director of Engineering, or a VP of Engineering.

Back in 2014, when the leadership pulled the trigger to make the combined engineering shift, I sat down with my dev manager. I told him that in my view, the best way to implement that change is to simply merge our two teams, put the SDEs and SDETs who used to work on the same projects and components under the same engineering manager, who might be the previous dev lead, or the previous test lead. That way gives us the best continuity, minimum tribal knowledge loss and minimum disruption to the projects.

The question was where I would be after the merge.

First to decide is whether I would remain in the team or not. For the benefit of the team, I chose to stay. Two reasons. For one, I had quite some tribal knowledge, as I was quite a hands-on manager (but not micro managing). If I leave right after the merge, those knowledge will be lost. For two, my staying in the team would demonstrate my commitment and support to this paradigm shift of combined engineering. That will help the team maintain the morale level and keep attrition low. These all serve the team’s best interest.

Now I had chosen to stay. The next question: what should be my team size.

I applied two principles. They are, not in any particular order: first, only one chef in a kitchen; second, less layers. If I remain in the same team and continue to have a large team, there would be only two choices: a) I remain as a “sibling” as the dev manager (now group engineering manager), b) I report to the dev manager. The choice (a) violates the first principle. The choice (b) violates the second principle, since managing a large team means I would have a couple leads. Therefore, in order to stay in the team and not violate my two principles, I should have a smaller team.

Last question: why only 3 engineers.

That’s at the low end of how many people a M1 usually manages. After the combined engineering shift, the top-down guidance was around 10-12 engineers for each M1. I went for a lower number for two reasons. First, I wanted to lower my managerial work load since the combined engineering was a new thing to me. That’s similar to that when I first came to US in 2010, I started with managing only one person. I picked up more after I got familiar with the new country, new culture and new working environment. Second, these 3 engineers were all top performers. I wanted to see what it is like to have a Navy SEAL team: small in number, but each team member is highly capable. That was intriguing as I never had such a chance before.

That’s the whole story.

I left that team in a year. By the time I left, knowledge had been shared, everybody had settled in their new roles and the transition to the combined engineering model was completed successfully a while back. Since then, I have been focused on a different area under the same VP. The choice I made in 2014 did disrupt my career growth a little bit, but I got back on track soon. In my current role, I still only manage 3 engineers. That’s mainly because it’s the optimal resourcing model for the problem space that I am working on. That will be a story for another day.