# Risk

A measure of how extensively an entity is threatened by a potential circumstance or event, based on adverse impact and likelihood of occurrence.

This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles.

## When the team plays, Pix pauses: what the World Cup teaches us about outliers

DevFeed: [When the team plays, Pix pauses: what the World Cup teaches us about outliers](<https://devfeed.tech/articles/when-the-team-plays-pix-pauses-what-the-world-cup-teaches-us-about-outliers-41439.md>)

Original publisher: [Read original article](<https://building.nu.com/when-the-team-plays-pix-pauses-what-the-world-cup-teaches-us-about-outliers/>)

Author: Nubank Editorial

Published: 2026-09-17T15:17:19Z

Content type: article

Language: en

Sources: [Nubank](<https://devfeed.tech/sources/nubank.md>)

Topics: [data](<https://devfeed.tech/topics/data.md>), [context](<https://devfeed.tech/topics/context.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [reliability](<https://devfeed.tech/topics/reliability.md>)

Tags: [ai-research](<https://devfeed.tech/tags/ai-research.md>), [context](<https://devfeed.tech/tags/context.md>), [data](<https://devfeed.tech/tags/data.md>), [data-science-machine-learning](<https://devfeed.tech/tags/data-science-machine-learning.md>), [patterns](<https://devfeed.tech/tags/patterns.md>), [payment](<https://devfeed.tech/tags/payment.md>), [transactions](<https://devfeed.tech/tags/transactions.md>)

### AI overview

The article uses World Cup matches as an example of how coordinated changes in everyday behavior can create outliers in payment data. It explains that instant-transfer volume drops during a match, returns after the final whistle, and may show a halftime pattern, emphasizing that anomalies must be assessed against the normal rhythm of transactions and their context.

### Source excerpt

How World Cup matches turn everyday payment patterns into outliers and what those anomalies can teach us about data, risk, and reliability The post When the team plays, Pix pauses: what the World Cup teaches us about outliers appeared first on Building Nubank.

## Match Software Quality Controls to Customer Impact and Technical Risk

DevFeed: [Match Software Quality Controls to Customer Impact and Technical Risk](<https://devfeed.tech/articles/quality-controls-storytelling-reps-and-weekly-readings-39824.md>)

Original publisher: [Read original article](<https://refactoring.fm/p/quality-controls-storytelling-reps>)

Author: Luca Rossi

Published: 2026-09-07T07:03:38Z

Content type: opinion

Language: en

Sources: [Refactoring](<https://devfeed.tech/sources/refactoring.md>)

Topics: [Risk](<https://devfeed.tech/topics/risk.md>), [Software](<https://devfeed.tech/topics/software.md>), [Architecture & Design](<https://devfeed.tech/topics/architecture-design.md>)

Tags: [essay](<https://devfeed.tech/tags/essay.md>), [risk](<https://devfeed.tech/tags/risk.md>), [software](<https://devfeed.tech/tags/software.md>)

### AI overview

This commentary argues that software quality controls should reflect a change's customer impact and technical risk. It describes a maturity path from individual quality advocacy to team-wide principles and processes.

### Source excerpt

Monday Ideas -- Edition #224

## NFR Brain: challenging the status quo of risk management with data

DevFeed: [NFR Brain: challenging the status quo of risk management with data](<https://devfeed.tech/articles/nfr-brain-challenging-the-status-quo-of-risk-management-with-data-41436.md>)

Original publisher: [Read original article](<https://building.nu.com/nfr-brain-challenging-the-status-quo-of-risk-management-with-data/>)

Author: Nubank Editorial

Published: 2026-09-04T14:18:41Z

Content type: opinion

Language: en

Sources: [Nubank](<https://devfeed.tech/sources/nubank.md>)

Topics: [risk-management](<https://devfeed.tech/topics/risk-management.md>), [data](<https://devfeed.tech/topics/data.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [Resilience](<https://devfeed.tech/topics/resilience.md>)

Tags: [critical](<https://devfeed.tech/tags/critical.md>), [data](<https://devfeed.tech/tags/data.md>), [data-analytics](<https://devfeed.tech/tags/data-analytics.md>), [data-modelling](<https://devfeed.tech/tags/data-modelling.md>), [data-science-machine-learning](<https://devfeed.tech/tags/data-science-machine-learning.md>), [governance](<https://devfeed.tech/tags/governance.md>), [models](<https://devfeed.tech/tags/models.md>), [risk-management](<https://devfeed.tech/tags/risk-management.md>)

### AI overview

Nubank describes NFR Brain, a platform for combining data, modelling, and expert judgement to make non-financial risk signals comparable and actionable. The article presents it as a way to support more consistent, transparent risk prioritization in business decisions without automating judgement.

### Source excerpt

Author : Mayara Zenati At Nubank, we believe the most meaningful problems for customers and for the business rarely come with ready-made answers. That is why we challenge the status quo: not to innovate for innovation's sake, but to remove complexity and build solutions that make important decisions simpler, faster and better. This mindset also [...] The post NFR Brain: challenging the status quo of risk management with data appeared first on Building Nubank.

## A Model for Understanding AI Success in Organizations

DevFeed: [A Model for Understanding AI Success in Organizations](<https://devfeed.tech/articles/tbm-431-the-denominator-that-matters-40057.md>)

Original publisher: [Read original article](<https://cutlefish.substack.com/p/tbm-431-the-denominator-that-matters>)

Author: John Cutler

Published: 2026-07-19T15:21:27Z

Content type: opinion

Language: en

Sources: [The Beautiful Mess](<https://devfeed.tech/sources/the-beautiful-mess.md>)

Topics: [Artificial Intelligence](<https://devfeed.tech/topics/ai.md>), [context](<https://devfeed.tech/topics/context.md>), [domain](<https://devfeed.tech/topics/domain.md>), [iteration](<https://devfeed.tech/topics/iteration.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [ai](<https://devfeed.tech/tags/ai.md>), [context](<https://devfeed.tech/tags/context.md>), [domain](<https://devfeed.tech/tags/domain.md>), [iteration](<https://devfeed.tech/tags/iteration.md>), [risk](<https://devfeed.tech/tags/risk.md>)

### AI overview

The article presents a multiplicative model for AI success based on technology understanding, problem understanding, practice evolution, and an organizational social contract. It argues that missing any essential factor can undermine the outcome, while resistance to AI mandates may reflect rational self-preservation and insufficient evidence.

### Source excerpt

Here's a simple model for thinking about AI success in organizations.

## NCMC design and technical limitations

DevFeed: [NCMC design and technical limitations](<https://devfeed.tech/articles/ncmc-design-and-technical-limitations-39787.md>)

Original publisher: [Read original article](<https://anuragbhatia.com/post/2026/ncmc-design-and-limitations/>)

Published: 2026-01-03T18:46:00Z

Content type: opinion

Language: en

Sources: [Personal blog of Anurag Bhatia](<https://devfeed.tech/sources/personal-blog-of-anurag-bhatia.md>)

Topics: [Internet](<https://devfeed.tech/topics/internet.md>), [Transactions](<https://devfeed.tech/topics/transactions.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [systems](<https://devfeed.tech/topics/systems.md>)

Tags: [card](<https://devfeed.tech/tags/card.md>), [dmrc](<https://devfeed.tech/tags/dmrc.md>), [internet](<https://devfeed.tech/tags/internet.md>), [ncmc](<https://devfeed.tech/tags/ncmc.md>), [npci](<https://devfeed.tech/tags/npci.md>), [payment-systems](<https://devfeed.tech/tags/payment-systems.md>), [payments](<https://devfeed.tech/tags/payments.md>)

### AI overview

The article examines India's National Common Mobility Card (NCMC), focusing on its offline-wallet design and how it differs from online UPI and card payments used in other transit systems.

### Source excerpt

I was in Mumbai a few months ago for the Equinix India Peering forum. The event happened to be very near the airport & I found that the airport, conference venue, hotel, and a few other locations I was visiting were all near the newly built Mumbai Line 3 (Aqua Line). To save on hassle with regular tickets, I went for an NCMC (National Common Mobility Card). Most people travelling in the Delhi metro would be aware of it by now, thanks to a bit of marketing push inside the metro train with announcements. Mumbai line 3 has a tie-up with SBI for the card, and thus, I got the SBI card. Ended up using it in Mumbai, Delhi and Chennai over the last few months. Lately, I have been reading about way NCMC works, the limitations of the Indian NCMC design compared to other mass transit systems. In many countries, mass transit systems simply use MasterCard/Visa/Apple Pay tap and charge directly from the respective card (credit/debit card, etc.), like the London tube, Stockholm metro, HK airport express, Singapore, etc. Indian deployment is bit different. Indian NCMC offline wallet concept The whole idea of NCMC is to have a single card which can make payment for public transport, including metro, buses etc across the country digitally. It has to be fast and reliable, and this is where the whole tech differs from systems like UPI or Visa/MasterCard/Rupay POS payments. In case of UPI as well as credit/debit card payments on POS machines - entire transaction runs online. Money goes from the person paying the amount to the receiver as part of a settlement facilitated by NPCI. I don't need to go in detailed steps involved there, but the key idea is that there's an active involvement of 1) Payer's APP 2) Payer's bank 3) Receiver's PSP 4) Receiver's bank 5) NPCI UPI switch, etc. All these have to work and most important - internet has to work. 😀 All this largely works well for casual payments across the vendors, but not for transit payments, especially at metro stations. It easily takes

## Introducing our new QR Friend app

DevFeed: [Introducing our new QR Friend app](<https://devfeed.tech/articles/introducing-our-new-qr-friend-app-40807.md>)

Original publisher: [Read original article](<https://www.bloco.io/blog/introducing-our-new-qr-friend-app>)

Author: Sérgio

Published: 2024-10-17T16:33:21Z

Content type: release

Language: en

Sources: [Blog - Bloco](<https://devfeed.tech/sources/blog-bloco.md>)

Topics: [QR Code](<https://devfeed.tech/topics/qrcode.md>), [App](<https://devfeed.tech/topics/app.md>), [Android](<https://devfeed.tech/topics/android.md>), [Google Play](<https://devfeed.tech/topics/google-play.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [android](<https://devfeed.tech/tags/android.md>), [app](<https://devfeed.tech/tags/app.md>), [dark-mode](<https://devfeed.tech/tags/dark-mode.md>), [google-play](<https://devfeed.tech/tags/google-play.md>), [projects](<https://devfeed.tech/tags/projects.md>), [qr-code](<https://devfeed.tech/tags/qr-code.md>), [risk](<https://devfeed.tech/tags/risk.md>)

### AI overview

Bloco released QR Friend, an Android app for scanning QR codes without ads or accounts. It supports WiFi, contact, GPS location, and barcode scans, with scan history, favorites, optional premium features, and link safety checks using Google's Web Risk service.

### Source excerpt

We released a new app for scanning QR codes: QR Friend.

## Developer Experience at Risk: Red Flags for Engineering Leaders

DevFeed: [Developer Experience at Risk: Red Flags for Engineering Leaders](<https://devfeed.tech/articles/developer-experience-at-risk-red-flags-for-engineering-leaders-39895.md>)

Original publisher: [Read original article](<https://mende.io/blog/developer-experience-at-risk-red-flags-for-engineering-leaders/>)

Author: tobi@techunicorn.builders (Tobias Mende)

Published: 2023-06-17T05:00:00Z

Content type: opinion

Language: en

Sources: [Tobias Mende](<https://devfeed.tech/sources/tobias-mende.md>)

Topics: [devex](<https://devfeed.tech/topics/devex.md>), [Developer experience](<https://devfeed.tech/topics/developer-experience.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [Tech Lead](<https://devfeed.tech/topics/tech-lead.md>)

Tags: [culture-developer-experience-developer-productivity-engineering-excellence](<https://devfeed.tech/tags/culture-developer-experience-developer-productivity-engineering-excellence.md>), [developer-experience](<https://devfeed.tech/tags/developer-experience.md>), [devex](<https://devfeed.tech/tags/devex.md>), [risk](<https://devfeed.tech/tags/risk.md>), [tech-lead](<https://devfeed.tech/tags/tech-lead.md>), [tooling](<https://devfeed.tech/tags/tooling.md>)

### AI overview

The article identifies warning signs that engineering leaders may be neglecting developer experience, focusing on engineers' behavior and coping strategies. It discusses job crafting and the risk that excessive work outside assigned roles can delay product evolution and create delivery pressure.

### Source excerpt

Developer Experience at Risk: Red Flags for Engineering Leaders Developer Experience is the most important driver behind productivity, engagement, and job satisfaction. Therefore, improving the perceived experience of their engineers should be the top priority for engineering leaders at all levels.

## Is "Not deploying on Fridays" an outdated practice?

DevFeed: [Is "Not deploying on Fridays" an outdated practice?](<https://devfeed.tech/articles/is-not-deploying-on-fridays-an-outdated-practice-39930.md>)

Original publisher: [Read original article](<https://mende.io/blog/not-deploying-on-fridays-outdated-practice/>)

Author: tobi@techunicorn.builders (Tobias Mende)

Published: 2022-07-09T13:25:00Z

Content type: opinion

Language: en

Sources: [Tobias Mende](<https://devfeed.tech/sources/tobias-mende.md>)

Topics: [Deployment](<https://devfeed.tech/topics/deployment.md>), [Development](<https://devfeed.tech/topics/development.md>), [Software Engineering](<https://devfeed.tech/topics/software-engineering.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [changes](<https://devfeed.tech/tags/changes.md>), [continuous-deployment-culture-practices-developer-productivity-engineering-excellence-software](<https://devfeed.tech/tags/continuous-deployment-culture-practices-developer-productivity-engineering-excellence-software.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [development](<https://devfeed.tech/tags/development.md>), [risk](<https://devfeed.tech/tags/risk.md>)

### AI overview

The article argues that avoiding Friday deployments is an outdated practice for teams using continuous deployments, feature toggles, and instant rollbacks. Small, frequent deployments reduce the risk and effort of fixing problems, while postponing releases can create larger batch deployments on Monday.

### Source excerpt

Is "Not deploying on Fridays" an outdated practice? Every person working in a field somehow related to software development probably has heard the term "Don't deploy on Fridays". For years, I considered this as a wise recommendation.

## Managing Employees During the Invasion of Ukraine

DevFeed: [Managing Employees During the Invasion of Ukraine](<https://devfeed.tech/articles/imperfect-7-managing-with-war-next-door-39457.md>)

Original publisher: [Read original article](<https://imperfect.substack.com/p/imperfect-7-managing-with-war-next>)

Author: Pedro Gil Carvalho

Published: 2022-02-25T10:32:45Z

Content type: opinion

Language: en

Sources: [Pedro Gil Carvalho](<https://devfeed.tech/sources/pedro-gil-carvalho.md>)

Topics: [Support](<https://devfeed.tech/topics/support.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [berlin](<https://devfeed.tech/tags/berlin.md>), [company](<https://devfeed.tech/tags/company.md>), [employees](<https://devfeed.tech/tags/employees.md>), [money](<https://devfeed.tech/tags/money.md>), [support](<https://devfeed.tech/tags/support.md>), [ukraine](<https://devfeed.tech/tags/ukraine.md>)

### AI overview

The article advises managers to support employees affected by the invasion of Ukraine, including by checking in, providing needed assistance, considering financial help and extraordinary time off, preventing hostility toward Russian employees, and adjusting expectations.

### Source excerpt

A message for managers of people who are affected by the invasion of Ukraine by Russian forces

## Crucial developer practices: Decoupling deployments and releases

DevFeed: [Crucial developer practices: Decoupling deployments and releases](<https://devfeed.tech/articles/crucial-developer-practices-decoupling-deployments-and-releases-39890.md>)

Original publisher: [Read original article](<https://mende.io/blog/decoupling-deployments-and-releases/>)

Author: tobi@techunicorn.builders (Tobias Mende)

Published: 2021-11-27T12:02:00Z

Content type: article

Language: en

Sources: [Tobias Mende](<https://devfeed.tech/sources/tobias-mende.md>)

Topics: [feature flags](<https://devfeed.tech/topics/feature-flags.md>), [Deployment](<https://devfeed.tech/topics/deployment.md>), [releases](<https://devfeed.tech/topics/releases.md>), [systems](<https://devfeed.tech/topics/systems.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [Testing](<https://devfeed.tech/topics/testing.md>)

Tags: [continuous](<https://devfeed.tech/tags/continuous.md>), [continuous-deployment-software-development-software-craft](<https://devfeed.tech/tags/continuous-deployment-software-development-software-craft.md>), [decoupling](<https://devfeed.tech/tags/decoupling.md>), [deployments](<https://devfeed.tech/tags/deployments.md>), [developer](<https://devfeed.tech/tags/developer.md>), [feature-flags](<https://devfeed.tech/tags/feature-flags.md>), [practices](<https://devfeed.tech/tags/practices.md>), [risk](<https://devfeed.tech/tags/risk.md>), [test](<https://devfeed.tech/tags/test.md>), [testing](<https://devfeed.tech/tags/testing.md>)

### AI overview

The article explains why growing systems should decouple deployments from releases. It focuses on release toggles, a type of transient feature flag that lets developers change application behavior at runtime, gradually roll out changes, roll them back, and test in production without breaking the system.

### Source excerpt

Crucial developer practices: Decoupling deployments and releases When systems are small and the risk of introducing defects when changing its behaviour is low, these changes can happen during deployment. However, when systems grow, the behaviour becomes more complex and more people are working on the system, it is essential to decouple behaviour changes, the releases, from deployments.

## You can use SwiftUI today

DevFeed: [You can use SwiftUI today](<https://devfeed.tech/articles/you-can-use-swiftui-today-39509.md>)

Original publisher: [Read original article](<https://rambo.codes/posts/2020-01-03-you-can-use-swiftui-today>)

Published: 2020-01-04T02:50:00Z

Content type: opinion

Language: en

Sources: [Rambo Codes](<https://devfeed.tech/sources/rambo-codes.md>)

Topics: [SwiftUI](<https://devfeed.tech/topics/swiftui.md>), [iOS](<https://devfeed.tech/topics/ios.md>), [Low-Code / Internal Tools](<https://devfeed.tech/topics/internal-tools.md>), [macOS](<https://devfeed.tech/topics/macos.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [internal-tools](<https://devfeed.tech/tags/internal-tools.md>), [ios](<https://devfeed.tech/tags/ios.md>), [macos](<https://devfeed.tech/tags/macos.md>), [risk](<https://devfeed.tech/tags/risk.md>), [swift](<https://devfeed.tech/tags/swift.md>), [swiftui](<https://devfeed.tech/tags/swiftui.md>)

### AI overview

The author argues that using SwiftUI immediately for App Store production apps is risky because the technology is new, has rough edges, and may change significantly. They nevertheless recommend that iOS developers learn SwiftUI through substantial hands-on projects, including internal tools, rather than only tutorials or small test projects.

### Source excerpt

Gui Rambo writes about his coding and reverse engineering adventures.

## Equity Allocation in Startups

DevFeed: [Equity Allocation in Startups](<https://devfeed.tech/articles/equity-allocation-in-startups-28330.md>)

Original publisher: [Read original article](<http://fuzzyblog.io/blog/startup/2019/11/10/equity-allocation-in-startups.html>)

Author: Fuzzygroup

Published: 2019-11-10T00:00:00Z

Content type: opinion

Language: en

Sources: [Scott Johnson](<https://devfeed.tech/sources/scott-johnson.md>)

Topics: [Risk](<https://devfeed.tech/topics/risk.md>), [RSS Feed](<https://devfeed.tech/topics/rss-feed.md>)

Tags: [equity](<https://devfeed.tech/tags/equity.md>), [funding](<https://devfeed.tech/tags/funding.md>), [startup](<https://devfeed.tech/tags/startup.md>), [startups](<https://devfeed.tech/tags/startups.md>), [vp-of-engineering](<https://devfeed.tech/tags/vp-of-engineering.md>)

### AI overview

An opinionated guide to allocating startup equity, arguing that ownership should reflect the risk and timing of each contributor's involvement. It recommends reserving equity for an employee option plan, using options rather than stock, and applying a long vesting schedule. The author illustrates these points with personal experience from Feedster.

### Source excerpt

Once upon a time, I was speaking with a company founder and they mentioned that they had a VP of Engineering to whom they have given a 1/3 stake in the company. I immediately commented that was too much and then said "I'll write this down in a blog post" - and then I never did. Last night, oddly, I woke up from a deep sleep with the desire to write this down. And that brings us to this post. Here's what I can remember from that conversation: Company Stage: Pre Funding Company Type: Medical Equity Split with the VP of Engineering: 1/3 Founder Title: Yes Did VP of Engineering Put in Cash: No You Need to Understand This One of the basic rules of the startup world is that on Day 1, you, the founder, own 100% of something that is worth absolutely nothing. The goal, by the end, is that you own a much smaller percentage of something actually worth something. As an example, owning 10% of something worth $10 million is actually much, much better. The Basic Rules of Thumb for Equity Allocations Here are my rules of thumb to use for equity allocation: The more risk you take, the more you get The earlier you join, the more you get Putting time in is one type of risk Putting cash in is a greater type of risk If you, the founder, give too much equity to someone else then you can be pushed out by simply having that other person align with the investor or investors You only have 80% of the equity to play with - 20% generally goes to an ESOP (employee stock option plan) Make damn sure that you give out options not stock and a long vesting schedule (incremental over say 4 years) The bottom line is that equity, in whatever form, is a reward for taking risk. And the earlier you are involved in a startup, the more risk there is. My Personal Experience from Feedster A long, long time ago, I founded a blog search engine named Feedster. I merged with another RSS search engine shortly after coming to market to address some technical limitations in my architecture. We did the typical nerd fo

## Talking to Technical People

DevFeed: [Talking to Technical People](<https://devfeed.tech/articles/talking-to-technical-people-36552.md>)

Original publisher: [Read original article](<https://berthub.eu/articles/posts/talking-to-technical-people/>)

Published: 2017-07-07T18:35:35Z

Content type: opinion

Language: en

Sources: [Bert Hubert's writings](<https://devfeed.tech/sources/bert-hubert-s-writings.md>)

Topics: [Job](<https://devfeed.tech/topics/job.md>), [Risk](<https://devfeed.tech/topics/risk.md>), [Website](<https://devfeed.tech/topics/website.md>)

Tags: [business](<https://devfeed.tech/tags/business.md>), [job](<https://devfeed.tech/tags/job.md>), [risk](<https://devfeed.tech/tags/risk.md>), [technical](<https://devfeed.tech/tags/technical.md>)

### AI overview

The article argues that communication with technical people should clearly state the desired outcome, constraints, timeline, and motivation instead of relying on hints or indirect stories. It also advises avoiding micromanagement while acknowledging that technical specialists may resist or misunderstand implicit instructions.

### Source excerpt

(Don't) drop the hint: communicating with technical people This post is a subset of the presentation "Escaping the data center -- tales from a recovering manager". Video, slides. When we communicate at the office, we frequently do not directly say what we mean. A common conversation might go like this "Hey John, we did a survey and it turns out people can't find what they are looking for on our website".

## Why businesses need a longer-term focus than quarterly goals

DevFeed: [Why businesses need a longer-term focus than quarterly goals](<https://devfeed.tech/articles/nearsighted-business-41040.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2008/06/05/Nearsighted-Business/>)

Author: Map

Published: 2008-06-06T01:26:27Z

Content type: opinion

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [Risk](<https://devfeed.tech/topics/risk.md>), [ibm](<https://devfeed.tech/topics/ibm.md>)

Tags: [business](<https://devfeed.tech/tags/business.md>), [ceo](<https://devfeed.tech/tags/ceo.md>), [company](<https://devfeed.tech/tags/company.md>), [employees](<https://devfeed.tech/tags/employees.md>), [focus](<https://devfeed.tech/tags/focus.md>), [growth](<https://devfeed.tech/tags/growth.md>), [hiring](<https://devfeed.tech/tags/hiring.md>), [ibm](<https://devfeed.tech/tags/ibm.md>), [limits](<https://devfeed.tech/tags/limits.md>), [risk](<https://devfeed.tech/tags/risk.md>)

### AI overview

The article argues that businesses often prioritize quarterly or yearly targets over long-term goals, leading to poorly timed hiring freezes and rushed recruitment. It contrasts this with smaller companies' more constrained spending decisions and questions whether private ownership enables a longer-term focus.

### Source excerpt

Adobe's former CEO, Bruce Chizen, when asked 'What advice do you have for new/young public companies?', gave a response of 'Go private'. While partially a joke he went on to elaborate something that many businesses seem to miss on. The main idea is that businesses are very nearsighted in their focus, they look at quarterly goals and in some cases yearly, but not where they want to be in 10 years. When companies become worried that head count is high they simply freeze hiring across the board without thinking of its ramifications. Good people, well great people are truly hard to find, and when a company enforces a blanket hiring freeze they miss out on those few great people that they truly need to grow. Meanwhile when they decide they have bandwidth for 1000 new employees they open the flood gates and let the first 1000 that can spell their name correctly in, because they can. This short term focus in the long run greatly limits the ability of what a company can achieve. In contrast a smaller company that is actually much more at risk of dying seems to have a better understanding of what their approach should be. While they may be understaffed and overworked, they firmly understand that they only have so many funds and therefore make wiser decisions when using them. The characteristics of the larger business and their short sighted focus leads to the cyclical performance that many experience over a few years, rather than a very steady growth they would like to maintain, and often leads to their end. A prime example would be IBM that laid off so many of their more talented people to lower their numbers years ago. As a result they lost their best workers and had many unexperienced individuals in there when they began hiring again. They are still working to catch back up to where they once were in the IT industry... In part I wonder if being a private entity is really the only way to have the long term focus and not worry about quarterly earnings. Personally I have never

## How Public Online Complaints Are Changing Business Etiquette

DevFeed: [How Public Online Complaints Are Changing Business Etiquette](<https://devfeed.tech/articles/changing-etiquette-41036.md>)

Original publisher: [Read original article](<https://www.craigkerstiens.com/2008/06/02/Changing-etiquette/>)

Author: Map

Published: 2008-06-02T13:16:31Z

Content type: opinion

Language: en

Sources: [Craig Kerstiens](<https://devfeed.tech/sources/craig-kerstiens.md>)

Topics: [Publishing](<https://devfeed.tech/topics/publishing.md>), [Website](<https://devfeed.tech/topics/website.md>), [Users](<https://devfeed.tech/topics/users.md>), [Risk](<https://devfeed.tech/topics/risk.md>)

Tags: [publishing](<https://devfeed.tech/tags/publishing.md>), [rant](<https://devfeed.tech/tags/rant.md>), [risk](<https://devfeed.tech/tags/risk.md>), [users](<https://devfeed.tech/tags/users.md>), [web](<https://devfeed.tech/tags/web.md>)

### AI overview

This opinion article argues that business etiquette is changing as employees and former employees increasingly publish complaints and workplace experiences online. It also notes that employers may examine applicants' social media profiles, blurring boundaries between personal and professional conduct.

### Source excerpt

A recent conversation of someone that was offended when the were introduced to someone new, then was not greeted first since they were a female brought what follows to mind. The above is a train of thought that came from a 70 year old military wife. I do not believe this is common practice today and is quite rarely found as the common etiquette, but nonetheless I think what is proper etiquette in business is changing quite rapidly. Though I'm not sure if all of the older ideas and principles have gone away. I take as a first example zuckerburg, whom is a notoriously difficult interview. Not because he keeps things hidden, or is sealed tight about the company, but rather that his soft skills are not his strength. His strength is building a web product that millions of people find worthwhile to divulge hours of their day into it. Even two years ago when you were disgruntled with a company you may have gotten a few drinks in you and talked to a friend about your displeasure. But it certainly was not made fully public for anyone to see. At best you could only hope you were simply privy to things that would be brought to the publics eye from a larger misdoing either legally or that a mass-crowd found a problem with. But for simply being overworked, underpaid, or in some other odd way mistreated there was no politically correct outlet to speak through. However in the past years it has become extremely common for those that are still employed, or were employed to voice their complaints and bring to light the details that were once hidden. I think of Zed Shaw's rant on rails which calls out specific companies, or an older blog the diary of a mac genius, who gave detailed behind the scenes information of an apple customer support genius bar. While I'll concede for the mass majority if it's published it's doesn't mean its consumed, so it's not a dramatic effect on any single business, I still find it hard to believe that this overall shift of users freely publishing is not go