我目前任职的公司在近几个月持续扩编，因此有不少新同事加入，其中有表现好的、有力求表现的，也有还在观察的。这让我想起自己刚进公司的情况，也想起每次换工作后，自己总会度过一个「一副菜样」以及出包时期。

这篇想来聊聊：不管是职场菜鸟还是老鸟，刚加入新公司、刚到职时，该用什么样的「姿态」与「个性」展现自己。

筑招网小编以下总共会列出3 句「加入新公司时，不适合说的话」，并一一以实际情况举例，并且说明为什么不适合，以及该如何调整成相对安全的「新手onboard 起手式」。

但！一样要打个预防针，以下纯粹想要分享个人看法，不一定适用于各行各业，只是想写出来给需要的人作为参考，至于实际上该怎么做，还是得看所处的工作环境与风气啰！

1.「那我应该怎么办？」

（❌）消极应对

（⭕）带着答案问问题

虽说标题提到「不管社会新人还是职场老鸟」都能适用这篇内容，但以个人经验看来，1. 的问题较会发生在职场菜鸟身上。

初入职场的时候，难免继续把自己当学生，有问题就想直接问老师（主管），但进入职场后，如果只有一种「我是来学习」的态度，公司不一定会觉得你积极向上，反而会疑惑：「那你可以带给公司什么？」

所以，尽管公司对于菜鸟新鲜人有容忍度，但如果新鲜人能主动表现出「我有很多需要学习，但我也会努力贡献所学」的积极态度，通常公司会对此更加青睐。

遥想我的第一份工作在公关代理商，很多时间都在写客户的方案，客户会说：「我们下一季要推新品，想办个发表会」，或者也可能很模糊地说：「我希望媒体可以多报导我们家品牌」，然后公关小精灵们就要熬夜变出方案，思考如何达成客户的愿望，比如想个包装的亮点，然后办记者会、办媒体餐叙（请记者吃饭＆送他们新品）、发新闻稿等。

说来简单，但写方案真的很困难。刚开始，不少新人都会问：「那我应该怎么开始写？」然而，与其这样问，其实可以先百度「怎么写方案」，至少帮自己理出一个框架。
若是更想挑战自我的人，也可以藉由不断透过自问自答的方式，借此培养自己逻辑思考的能力，并把方案架构列出来。像客户已经表明「希望办个发表会」了，再来得想的应该就是「怎么办」。这就包含发表会的「人事时地物」了，比如：需要谁来参加、要有哪些环节、要办在何时、要办在哪里、要发表的东西是什么。

列出「人事时地物」 — — 也就是想完“how” 之后，再往更源头追溯，就是“why”？客户为什么要办这个发表会？是因为产业趋势吗？比如在这个市场中，这个产品很夯？还是因为客户的竞品都在办？所以是因为要输人不输阵吗？还是因为客户公司的内部策略？那公司希望达到什么目标呢？

想完这些“why” 后，又可以再列出产业趋势与竞品分析。所以，现在有了产业趋势与竞品分析，也有发表会的人事时地物，这份方案就有架构了！

不管用了哪个方法，想出大致的解法后，如果不确定自己这样做对不对，比起直接问「怎么办」，更好的做法是跟主管说：「关于这份方案，我目前大概想了个架构，我可不可以先列出来再麻烦你过目？如果没问题，我再继续往下细写。」

也就是「带着答案问问题」，表达一种「我有思考解法，但不确定是否正确，所以想来请教看看」的态度。

为什么要这样做？换位思考看看吧：今天换作是自己要教新人东西，会希望这位新人当伸手牌，还是先做功课呢？

至于这样做的好处是：可以增加自己组织思考与解决问题的能力。随着资历渐增，换工作时应该会渐渐发现，许多公司要求应征者是“independent thinker”（独立思考者），或者具有“problem-solving”（解决问题）的能力，而这能力在典型台湾教育的框架之中很难被培养，所以若能在职涯早期就开始养成，对未来或许有不小的帮助。

2.「为什么不试试看别的作法？」

（❌）力求表现

（⭕）静观其变

这点有点微妙，毕竟上一段才说「不要当伸手牌」，这边怎么又说「不可以力求表现」呢？其实就是得找平衡，要「稍微」积极主动，但又不能锋芒毕露。

先举个比较好懂的例子，比如吃汤面会先确认会不会太烫，避免烫到舌头（这例子会不会太生活化），工作也是这样。做为新人，不管是职场菜鸟还是老鸟，不论公司录取的原因是想要「从新开始养新人」还是「希望有经验的人为公司带来新气象」，只要是到职的前一、两个月，都建议以「观察」代替「行动」。

也就是先把自己的工作内容顾好，并借此观察公司目前的运作方式、既定流程、既有文件等，等自己熟悉产业与公司文化后，再提出自己希望调整的地方。
因为在没有掌握整件事情的来龙去脉之前，做出的决定很有可能不够周全，甚至影响到同事们对自己的第一印象。

举例来说，我刚开始加入这间公司时，有时候会跟工程对接到一些项目，觉得需求传达得好像不太顺，加上在前公司有跑敏捷开发，所以我在到职没几周后就跑去问工程师：「我们有考虑导入scrum 吗？我在前公司跑过sprint，觉得这样开发速度比较快，产品迭代也跑得比较顺。」

先不论工程师的答复，现在回头看来，这个问题其实很白目的。

一来，我当时不是产品经理，也不是工程团队的人，更不够了解新公司的产品开发流程，只是稍微觉得不顺，但并不知道到底是「我不够了解这套流程的运作逻辑」还是「这套开发流程真的有瑕疵」，如此冒然直接提出建议，其实很不尊重工程团队。

二来，即使对于开发流程有建议，也可以更委婉地表达，用「请教」而非「质问」的方式，比如：「我们当初怎么决定采用现在这套开发方式的呢？」、「如果公司有资源，你觉得开发流程还可以怎样做得更好呢？」若直接用「取代、替换」或「推翻、砍掉重练」的方式为切点，这样别人只会觉得太有侵略性。

最近公司又来了一批新人，身为PM 的我被问了各种问题，比如为什么建筑人才网网站没有XXX 功能、为什么某个功能不能XXX 使用、为什么不做别的建筑招聘平台也有的XXX 工具……什么问题都有。

但这些问题不一定是公司以前没想过，有的功能其实已经有了，只是发问者找不到；有的功能之前的确有做过，但因为使用率低或者难以管理而拔掉；有些事情则正在规划中，有些事情是讨论过，但与公司方向不同，所以最后没执行。

但也强调一下：不是不给问！是希望做过功课再问。如果只用「为什么不试试看」的口吻作为切入点，别人会很容易认为发问者根本没做功课，进而产生不好的观感，甚至影响到后续的共事默契。

如果真的有问题想问、需要帮忙，可以参考先前的文章〈如何开口请人帮忙？让双方都舒服的求助话术〉，里面有些沟通话术也适用此场景。

3.「那我建议这件事情可以由别的同事负责进行」

（❌）颐指气使

（⭕）亲力亲为

如果在规模不是太大的公司，即使是主管级，也有很多时间必须要协助，甚至主要负责第一线的业务。像我目前是产品团队的主管兼产品经理，不只负责人事管理与参与主管会议，平时也得花时间解决一般产品经理的庶务，比如对需求、画wireframe、开票、测试等。

尽管有时真的快轧不过来，但我觉得从事这些庶务仍是利大于弊，一来是可以维持第一线做事的手感（况且我也还是菜鸟PM，有很多要学习），二来是可以知道第一线的同事们会碰到哪些实务问题。

然而，这并不是说刚到新公司就该做到死，而是要适时分配工作，不能把所有事情都往外推，但也不能都揽在自己身上

老话一句，还是得找个平衡才行。

如果把事情全部都分派给其他部门，大家只会觉得「这个新来的也太会踢皮球了吧」；而如果把事情都分给下属，组内也可能觉得这个新主管「只剩一张嘴」，且事情都分出去了，自己就很有可能不熟悉第一线业务的运作情况，实务能力若备受挑战，提出的策略又与第一线现场脱节的话，也可能因此难以得到同事或下属的认同，甚至与第一线同事沟通时产生鸿沟。

为了怕这些事发生，我刚开始接手产品主管的角色时，会先自己多抓一点事情来做，不论大小功能，尽量把产品开发流程抓在手上。虽然那时的加班时间明显变多，但也是因为这样，让我可以更快熟悉第一线业务，进而培养和各部门沟通的默契，也能在部门内和其他PM 与设计师更顺畅沟通。

等到彼此共事熟悉了，再把任务分派出去，这样如果同事有问题，自己也有足够的经验能回答，不会沦为打高空，甚至和第一线脱节。

结论

不知不觉又打了很多……这3 点看起来可能简单，但实践起来却有很多眉角，总之，大方向的建议就是不要躁进，不要想说到了新公司就要力求表现、让老板知道「雇用我有多值得！」；但也不能太被动，不要总是等同事派给你工作才去做、主管提醒后才发现自己漏掉很多细节。

总而言之，还是一句老话：得慢慢在做中学，这样才能找到做事的平衡点