“Doing the right things, doing things right” in Management

How to make a choice between “doing the right things” and “doing things right” is an interesting topic people would like to discuss. In a nutshell, “doing the right things” focuses on defining visions, whereas “doing things right” focuses on the process of implementing the visions. Obviously, there are strong relationship and coherence between these two conditions. However, most articles around this topic assess and evaluate them respectively, instead of critical discussing. In other words, these articles emphasise the importance of one of them, while the view of taking less consideration on another also be implied. Such biases often exist in companies or project teams.

snapshot by Agile Software Development: It’s Not About Code. It’s About Business.

The Youtuber Development That Pays has presented a straightforward and specific situation when discussing the quality of code and the business value of a software product. He analogies the business objectives as a barrier on the way to success, and treats the software product as a ladder for crossing the barrier. In this manner, two potential results can be foreseen. A product with elegant code quality (or good design) may lead to “certain death”. Conversely, a product with not so good or even well-crafted quality may bring “untold riches” in a correct direction.

On the positive side, firstly, he has proved the importance of visions in business. As Peter Drucker wrote in The Practice of Management, visions could be analogised as compasses for navigation at sea. Only if setting the target, then the ship can move towards the correct destination without being affected by unexpected factors from environments. Secondly, the creator of the episode has clarified the priorities of different roles in a company or project from the perspective of software developers and market managers. A developer is responsible for the quality of products. And a marketing manager needs to find ways to improve the value of products in markets.

But I do not agree with the way of presenting this situation showed in the episode in order to the reason that “better ladder” and “more value” should not be compared as two independent sides. It would lead to ambiguity in understanding, as long as there is an explicit vision, the goal can be achieved by comparatively appropriate approaches or processes. This means that this idea may suggest people reduce or even neglect the requirements for one of them when choosing another side. Basically, this point is about how to make a choice between “doing the right things” and “doing things right” as well. In other words, the answer showed in the episode is “I am doing the right thing, while I’m doing it not so well, but it’s ok!”

The main cause is there is no unique vision. Drucker believes that human groups must be based on common beliefs, and must use common principles to symbolise everyone’s cohesion. Otherwise, the organisation will be paralysed and unable to function, and employees cannot work hard to get the performance they deserve. For a company or a project team, the “right things”, as well as the overall visions, must be identified clearly. Then, it is necessary to successfully express these visions to each employee, such as writing the visions on a large board and pasting them on the wall (like Kanban board). It could help the employees or team members grasp what value they can contribute by their work. So that employees in different positions not only simply pursue the “right things” determined by their responsibilities, but also contribute to the overall visions. The cases of software products are much more complicated than described above in practice. If the market manager focuses on profiting from the market simply and ignores product quality, or developers only care about code quality or product quality as “right things” in their minds, neither the overall nor the independent visions can be achieved then. This is also an inevitable result of not having a unique overall vision. From this perspective, if the “right things” are not set correctly, companies or project teams cannot do the “things right” then.

As mentioned above, “doing things right” has equal importance as “doing the right things”. First of all, it should be clear that companies or projects should create visions accordingly, that is, to determine which ‘things’ are ‘right’. Due to various factors from the marketplace, economic environment and so forth, that would bring uncertainties, there is no effective approach to verify that the visions are appropriate when creating them. The results would emerge from the market in the future only.

Drucker also supports this perspective and he suggests that economic and technological development lengthens the intervals required to verify the effectiveness of decision-making and its success continuously. Therefore, selecting appropriate methods or processes would help the organization to inspect visions and reduce risks constantly. I suppose it coincides with agile’s mindset.

In conclusion, I believe that “doing the right things” and “doing things right” play the identically important roles in management. The manager should demonstrate the visions of the organisation to each member explicitly and comprehensively. And everyone inside the organisation should keep them in mind and take responsibility for contributing to the visions, just “doing them right”. In addition, “doing things right” is an efficient and effective way to assess if the “things” are “right”. However, it would be meaningless without visions, even though there is the most effective working process.

关于如何在”doing the right things”和”doing things right”做出选择,一直是大家乐于讨论的一个话题。用另一个更简单的方式来说,”doing the right things”指的是对确立目标的思考,即为”what”,”doing things right”则为实现目标的方式的判断,即”how”。显而易见的是,这两个问题具有顺序性且关联紧密。但是,多数围绕这个话题的文章都把这两种情况分开讨论,而不是对其辩证思考。或者说,它们的确侧重强调了其中一方的重要性,可在读者眼里看来,同样带来了弱化对另一方的重视。更糟糕的是,这种偏见经常存在于公司或者项目团队中。

Development That Pays 在讨论代码质量和商业目的时描述了一个直接且特殊的情况。他将商业需求类比成通往成功过程中的一个壁垒,用于跨越这个壁垒的梯子则是软件产品。其特殊性表现在,它描述了一种即使具有优雅的代码质量(或者说优秀的产品设计),却导致”certain death”情况。相反的,一个代码质量不高的产品只要方向正确,最终达成了”untold riches”。


但我不认同的是他对于这种情况的表达方式,主要原因在于并不应该将”better ladder”和”more value”作为对立项进行比较。这将会导致出现理解上的歧义,认为只要方向正确,即使使用的方法或者途径并不理想,也可以实现目标。这就意味着他的答案正引导读者在做出选择时必定要舍弃或者降低对另外一方的要求。从本质上来看,这个表达方式就是在” doing the right things”和”doing things right”之间的硬性选择。换句话说,他的答案就是” I am doing the right thing, while I’ll do not so well, but it’s ok!”。这显然不是正确的。

导致这种情况的主要原因是在于没有统一的目标。德鲁克认为“人的团体必须以共同的信念为基础,必须用共同的原则来象征大家的凝聚力。否则组织就会瘫痪而无法运作,无法要求成员努力投入,获得应有的绩效”。对于一个公司和项目的”right things”,也就是目标必须明确。并且,需要将这一整体的目标成功传递给每个员工,比如把企业或者项目目标写在一张大纸上并且贴在最显眼的墙上,让公司员工或者项目成员熟知他们的工作将会帮助整个公司或者项目实现什么样的价值。从而让处于不同岗位的员工不只是单纯追求其职责所决定的”right things”,而是将这些标准服务于整体的目标。关于软件产品的案例在实际中远远没有上面描述的那么简单,若市场经理一味追求从市场中获利这个目标而忽视产品质量,或者开发者只把代码质量或者产品质量作为他们心中的”right things”的话,那么无论整体的还是独立的目标都无法实现。这也是没有统一整体目标的必然结果。从这个角度来看,如果没有正确设定统一的”right things”的话,那么一个公司或者项目团队也不可能做到”doing the things right”.

当然,我们不可否认”doing things right”的意义。首先必须要明确的是,公司和项目需要有根据地设定目标,也就是预估哪些things是right。由于来自市场环境、经济发展等多方面因素导致未来的不确定性,导致没有办法保证预设的目标是否正确,只有通过市场的检验才能知道答案。德鲁克同样证实了这一观点,他认为经济和技术进步使证实决策的成效和收获成功所需的时间不断延长。因此,选择合适的恰当的方法或者手段将会使通过预设目标的航线线路更加顺畅,从而有利于组织不断检查目标,减少风险。我想这跟agile的思想不谋而合。

因此,我的观点是:在团队管理中,” doing the right things”和”doing things right”不管对于任何角色而言都具有相同的重要性。管理者需要将组织整体的目标传递给每一位成员,并且每位成员的工作需要为整体的目标服务,” doing them right”。除此之外,” doing things right”是验证things是否right的最有效的手段。但是,即使是最高效的工作方式,一旦离开了目标就毫无意义可言。

I have realised I did mistake his thought when I watched the next episode Agile Software Development: Without Code There Is No Business. So the opinions we express are actually the same.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.