Developers don't need ping-pong tables

栏目: IT技术 · 发布时间: 4年前

Today, a software development company’s office reminds an amusement park, rather than a workplace. There is no need to visit Disneyland anymore, because ping-pong tables, golf fields, game consoles, and color chairs are spread across the office rooms, connected by roller coaster rails and water slides.

Developers don't need ping-pong tables

Yesterday I had a conversation with one hiring manager I know. He’s been complaining that it’s very hard to attract good developers because the competition is too tight. Then I asked him:

Why should developers choose your company?

For the next half an hour, he’s been proudly telling about “exciting” projects, competitive salary, and a fancy office in the city center. During his elevator pitch, he was not shy to mention disruptive technology, innovation culture, and dynamic environment, also known as “our management can’t stop changing priorities”.

When I asked him what motivates software developers, he shrugged.

Developers don't need ping-pong tables

Companies waste millions on building the environment they think makes developers happy, without understanding what actually makes developers tick.

Unless your goal is to win a ping-pong tournament, remember: when developers change jobs, the last thing they care about is your fancy office and table tennis. Developers need autonomy, mastery, and purpose.

Developers don't need ping-pong tables

amazon.com amazon.de amazon.fr amazon.es amazon.it amazon.co.uk

Autonomy

Autonomy is a certain amount of freedom every developer needs. Here is how companies destroy autonomy:

Product Owners decide on requirements and priorities. Architects make key technical decisions. Managers decide who will work with whom. People you’ve never seen before suddenly become your colleagues. You’re not allowed to work remotely unless the world is at risk of extinction.

Modern corporate offices only provide an illusion of autonomy. Open spaces are not that open, because invisible electrical fences are installed everywhere. Permission, consensus and strict adherence to the process is required at every step, which reduces creativity and innovation levels down to zero. Product Backlog is God; don’t question priorities; your ideas can wait.

To promote autonomy:

  • Lead through vision and empowerment, instead of giving detailed instruction. The idea is to give people the information they need, the authority to take action and figure out implementation details. It’s called Mission Control.

  • Design full-cycle teams, where a team is responsible for the full software life cycle: analysis, design, development, testing, deployment, ops, and support. Eliminate cross-team dependencies and unnecessary consensus.

  • Allow personalization of work. Let Mike attend daily standup from Starbucks. Let Kate move and work remotely from Barcelona. Let Jeff try out his new idea now, not at the next Hackathon.

Autonomy doesn’t happen automatically. Organizations must be carefully designed with autonomy in mind.

Mastery

Mastery is our desire to improve. When professional growth slows down, developers dust-off their CVs and become “open to job opportunities”. A good developer will never trade mastery for money, perks, or a pompous office. We built a modern computer in the garage.

To promote mastery:

  • Pick team leaders wisely. A team leader is not an average developer with secretary duties no one else wants to carry out. A team leader is an inspiring master craftsperson; the role model; a person other teammates aspire to become. A team leader promotes technical excellence, spreads optimism, mentors people, and gives away the most interesting tasks to others.

  • Amplify learning with pair programming. By pairing with colleagues and regularly switching pairs, people pick up new coding tricks every day, learn to listen, learn to explain, come to work prepared, open up, build relationships. To grow well-rounded developers, consider not only pair programming but pair testing, pair ops, pair speaking, pair interviewing.

  • Demand mentoring at all levels. Make knowledge sharing and mentoring a prerequisite for a promotion: you can only grow if you grow others. How many successful developers your seniors have been able to grow? Of these developers, how many keep growing the newcomers? Of these developers, how many believe in themselves and have the confidence to speak at conferences?

Don’t promote smartasses. Promote mentors.

Purpose

Purpose transforms a group of people into a team. Purpose makes you code until late night and wakes you up at 6:00 am excited and ready to rock.

Unfortunately, developer work often reminds playing Fruit Ninja: you cut through a never-ending stream of random

fruits

tasks falling on you from JIRA. The faster you cut, the faster new tasks appear. That’s how companies turn passion into depression.

When the work is meaningless, it’s only a question of time when developers will find the true meaning of work. The culmination will be your corporate blog re-implemented using a reactive microservice architecture.

It doesn’t matter if you send rockets to space or keep a legacy accounting software alive. To reinforce the sense of purpose:

  • Develop psychological ownership. Psychological ownership is when an individual feels psychologically tied to something. Working in a stable, long-lived team builds a sense of belonging. Responsibility for a single codebase builds a sense of ownership. Serving one customer grows into meaningful relationships, empathy, and trust. Caring for things that matter to us is endowed with purpose.

  • Use goals or missions. Even a good old Scrum recommends defining a Sprint Goal because a sprint is not just a bag of random tasks. Sprint Goal is what the team plans to achieve during the sprint. All tasks must adhere to the goal, otherwise, people end up working on unrelated tasks, which downgrades the team into a group of people. The goal is what mobilizes, unites, and gives a sense of accomplishment.

  • Let developers see the impact of their work. If you build software for traders, go to the trading floor. Meet real people, see customers using and enjoying the stuff you built. Forget about B2B or B2C. We are in P2P business, where people build things for people. Let customers go to the engine room and see craftspeople at work. Celebrate ups and downs together. Engineers shall not eat pizzas alone.

Summary

In this crazy hiring race, we have lost sight of what really matters. In an attempt to attract and retain the best talent, money is being wasted on modern offices, perks, parties, ping-pong tables, and promo videos showcasing that all.

Leaders and people in charge of hiring must understand what motivates developers, and start designing organizations accordingly. Instead of building a fancy place to work, give people a reason to come to work. Otherwise, you’re just putting lipstick on a pig.

Developers don’t need ping-pong tables; they need autonomy, mastery, and purpose.


以上所述就是小编给大家介绍的《Developers don't need ping-pong tables》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 码农网 的支持!

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

银行3.0:移动互联时代的银行转型之道

银行3.0:移动互联时代的银行转型之道

[澳]布莱特·金(Brett King) / 白 宫 施 轶 / 广东经济出版社 / 2014-12 / 88.00元

银行未来会怎样,银行下一步该怎么做?银行如何在客户行为变化、科技变化,以及新的非银行竞争者不断涌入等时代变化的形势下,在未来取得成功? 这是第一本透彻深入地全面呈现当今银行业的内外形势与状况的书,内容涉及技术变化、客户行为变化、涌现的外部竞争者,银行现有组织架构、流程模式、制度思维、人员结构、互动渠道、营销方式等。具体包括低网点化,ATM、网站、呼叫中心的落伍,以及智能手机、社交媒体、移动支......一起来看看 《银行3.0:移动互联时代的银行转型之道》 这本书的介绍吧!

HTML 编码/解码
HTML 编码/解码

HTML 编码/解码

html转js在线工具
html转js在线工具

html转js在线工具