The ability to stay focused is key to achieving your true self. In a world full of distractions, this ability has become more important than ever. Nir Eyal, author of "Hooked," offers us effective methods to eliminate distractions and maintain focus.

Why are we always so easily distracted? It turns out that distractions often have internal causes. We get distracted because we constantly seek to escape psychological discomfort. To avoid distractions, we need to address the issues from the inside out.

Identify Internal Triggers of Distraction​

Next time you feel your attention slipping, try to record your feelings and the reasons behind them. This way, you can understand the internal triggers right from the start. Afterward, you can avoid distractions by making tasks more enjoyable.

Prioritize Time for Yourself Before Scheduling Work​

Creating a plan can prevent distractions because you will clearly know your goals. However, prioritizing work time is not the best starting point. On the contrary, you should first plan for yourself and your relationships. By doing so, playtime is already scheduled, and you won’t interrupt your work out of a desire to play. In other words, work when it’s time to work, and play when it’s time to play.

Reduce Office Distractions and Learn to Organize​

There are often many external factors in the workplace that distract attention, such as email notifications. Try to let others know that you need to focus entirely on the task at hand so that they won’t disturb you. Additionally, learn how to effectively organize your emails to ensure that you only have a few to focus on each day. Besides emails, there are many other forms of distractions in the workplace; learn to manage them with minimal effort.

Use Pacts to Prevent Distraction​

One undeniable fact is that our struggle with distractions is not a one-day battle. You can use apps that block distractions. Alternatively, work together with others to stay focused. Also, imposing fines as a penalty for not meeting goals can be very effective; this practice has greatly benefited the author.

Foster a Healthy Work Culture​

An imbalanced work culture is the beginning of endless distractions. In an unbalanced work culture, employees are heavily burdened and may even be expected to respond to emails after hours. Employers should create a platform that allows employees to provide feedback safely without fear of being fired.

20% Time​

Engineers are allowed to spend 20% of their work time on any project they want to contribute to, without needing approval from their managers or others. This is highly valuable because:

1. As long as there are good ideas, no matter how bad they sound at first, there is ample time to develop them to a demo-ready state.
2. It allows managers to see activities they might not otherwise notice; otherwise, engineers might engage in "skunkworks" and work secretly.
3. It enables engineers to work on interesting projects, preventing burnout and motivating them to be happier. The output gap between motivated engineers and burnt-out engineers far exceeds 20%.
4. It encourages innovation; if others around you are working on 20% projects, you will be inspired to do the same.

OKRs​

Individuals and teams must publicly document their objectives and how they measure them.

• Objectives
  • Set quarterly and annual goals.
  • Individual and team goals should align with the larger group’s goals.
• Key Results: Measurable key results can quantify progress towards objectives, ranging from 0 to 1.
• Set OKRs high; generally, achieving around 0.65 is a good standard. If your results are often below this, your goals may be set too high; if above, they may be too low.
• Benefits
  • Everyone knows what others are working on, fostering mutual motivation.
  • Provides purpose to execution, making it easier to achieve goals.
• OKRs are not directly related to performance evaluations.

Should the Project Continue or Be Terminated?​

While the review process for major new releases is systematic, there is no definitive answer to whether a project should continue; some decisions are bottom-up, while others are top-down.

Reorganization​

Splitting and merging teams is common, seemingly optimizing efficiency.

My Evaluation​

The results of 20% time are positive, having incubated significant projects like Gmail and AdSense. In a competitive environment, encouraging talented engineers to spend time on new initiatives is highly beneficial. Promoting 20% time is also a unique strategy to attract talent when the company is small and needs to offer excellent benefits. I tend to view 20% time as a management style rather than a guaranteed path to success.

The distinction between OKRs and performance evaluations is crucial—this means separating vision from execution and goal management from performance management. For example, asking "Did you reach the destination?" compared to "Is the car you drove a good one?" are two different questions. Similarly, poor product sales and whether engineers produced a good product are two separate issues.

For regular engineers, maintaining good relationships with other teams in a large company, including those unrelated to your specific work, is important, as it increases your demand in the labor market. This way, in the event of a reorganization or other adverse events, you will have more options.

It is widely recognized that Google is a company with exceptional engineering capabilities. What are its best engineering practices? What insights can we gain from them? What aspects have drawn criticism? We will discuss these details gradually, with this article primarily focusing on development.

Codebase​

• As of 2015, there are 2 billion lines of code in a small number of Monorepo single codebases, with the vast majority of the code visible to everyone. Google encourages engineers to make changes when they see issues, as long as all reviewers approve, the changes can be integrated.
• Almost all development occurs at the head of the codebase, rather than on branches, to avoid issues during merging and to facilitate safe fixes.
• Every change triggers tests, and any errors are reported to the author and reviewers within minutes.
• Each subtree of the codebase has at least two owners; other developers can submit modifications, but approval from the owners is required for integration.

Build System​

• The distributed build system Bazel makes compilation, linking, and testing easy and fast.
• Hundreds or thousands of machines are utilized.
• High reliability, with deterministic input dependencies leading to predictable output results, avoiding strange, uncertain fluctuations.
• Fast. Once a build result is cached, dependent builds will directly use the cache without needing to recompile. Only the changed parts are rebuilt.
• Pre-submit checks. Some quick tests can be executed before submission.

Code Review​

• There are code review tools in place.
• All changes must undergo review.
• After discovering a bug, you can point out the issue in the previous review, and relevant personnel will be notified via email.
• Experimental code does not require mandatory review, but code in production must be reviewed.
• Each change is encouraged to be as small as possible. Fewer than 100 lines is "small," fewer than 300 lines is "medium," fewer than 1000 lines is "large," and more than 1000 lines is "extremely large."

Testing​

• Unit tests
• Integration tests, regression tests
• Pre-submit checks
• Automatic generation of test coverage
• Conduct stress tests before deployment, generating relevant key metrics, especially latency and error rates as load varies.

Bug Tracking Tools​

Bugs, feature requests, customer issues, processes, etc., are all recorded and need to be regularly triaged to confirm priorities and then assigned to the appropriate engineers.

Programming Languages​

• There are five official languages: C++, Java, Python, Go, JavaScript, to facilitate code reuse and collaborative development. Each language has a style guide.
• Engineers undergo training in code readability.
• Domain-specific languages (DSLs) are also unavoidable in certain contexts.
• Data interaction between these languages primarily occurs through protocol buffers.
• A common workflow is essential, regardless of the language used.

Debugging and Analysis Tools​

• When a server crashes, the crash information is automatically recorded.
• Memory leaks are accompanied by the current heap objects.
• There are numerous web tools to help you monitor RPC requests, change settings, resource consumption, etc.

Release​

• Most release work is performed by regular engineers.
• Timely releases are crucial, as a fast release cadence greatly motivates engineers to work harder and receive feedback more quickly.
• A typical release process includes:
  1. Finding the latest stable build, creating a release branch, possibly cherry-picking some minor changes.
  2. Running tests, building, and packaging.
  3. Deploying to a staging server for internal testing, where you can shadow online traffic to check for issues.
  4. Releasing to a canary environment to handle a small amount of traffic for public testing.
  5. Gradually releasing to all users.

Review of Releases​

User-visible or significant releases must undergo reviews related to legal, privacy, security, reliability, and business requirements, ensuring relevant personnel are notified. There are dedicated tools to assist with this process.

Postmortem Reports​

After a significant outage incident, the responsible parties must write a postmortem report, which includes:

1. Incident title
2. Summary
3. Impact: duration, affected traffic, and profit loss
4. Timeline: documenting the occurrence, diagnosis, and resolution
5. Root causes
6. What went well and what did not: what lessons can help others find and resolve issues more quickly and accurately next time?
7. Next actionable items: what can be done to prevent similar incidents in the future?

Focus on the issue, not the person; the key here is to understand the problem itself and how to avoid similar issues in the future.

Code Rewrite​

Large software systems are often rewritten every few years. The downside is the high cost, but the benefits include:

1. Maintaining agility. Markets change, software requirements evolve, and code must adapt accordingly.
2. Reducing complexity.
3. Transferring knowledge to newcomers, giving them a sense of ownership.
4. Enhancing engineer mobility and promoting cross-domain innovation.
5. Adopting the latest technology stacks and methodologies.

My Comments​

Google's single codebase and powerful build system are not easily replicable by small companies, as they lack the resources and capabilities to make their build systems as fast and agile. Staying small, simple, and fast allows small companies to operate more smoothly and focus more on core business logic.

Build systems are often customized, and your knowledge may not transfer or scale. A powerful build system can even be detrimental to newcomers, as it raises the cost of gaining a holistic view.

The inability to transfer and scale knowledge is also an issue with well-developed in-house tools. Throughout my career, I have tried to avoid using non-open-source internal tools, such as Uber's Schemaless, which are tailored for specific scenarios and not made public for broader use; in contrast, LinkedIn's Kafka is a good product with openness and scalability of knowledge.

In the open market, there are excellent tools available for the entire development, testing, integration, and release process. For example, in the JS community:

Process	Tools
Codebase	Github, Gitlab, Bitbucket, gitolite
Code Review	Github Pull Requests, Phabricator
Pre-submit checks, testing, and linting	husky, ava, istanbul, eslint, prettier
Bug Tracking	Github Issues, Phabricator
Testing and Continuous Integration	CircleCI, TravisCI, TeamCity
Deployment	Online service deployment with Heroku, Netlify, mobile app deployment with Fastlane, library publication with NPM

Finally, I may have an insight: companies that do not focus on the automation of these engineering processes will lose significant competitive advantage. I even set up a JS full-stack development framework OneFx for good engineering practices. The difference between fast and slow, high quality and low quality is often exponential because — typically, speed allows you to do more and faster, while poor quality leads to less and worse outcomes.

Every aspiring entrepreneur knows that creating something no one wants is a fatal trap. This is why we must conduct the right data analysis. The book "Lean Analytics" provides entrepreneurs with some good metrics for evaluating success.

Moving in the Right Direction, Then Data-Driven​

Data is vital for business. Entrepreneurs need to use data to persuade others. Sometimes, entrepreneurs tend to overestimate their success, but data does not lie. It can help founders stay grounded. However, personal judgment on which data to pursue is also important. Entrepreneurs should not simply become slaves to the numbers.

What Are Good Metrics?​

To collect data, you need to find metrics that can provide meaningful information. Good metrics have three characteristics:

• Comparable: A good metric can be compared across different time periods and consumer groups.
• Understandable: Good metrics are simple and easy to comprehend.
• Ratios: Metrics are often ratios because they are effective and comparable.

The Five Stages Startups Will Experience​

• Empathy Stage: Identify people's needs and define your niche market.
• Stickiness Stage: Discover how to meet those needs with products that keep users coming back.
• Growth Stage: Add features that attract users.
• Revenue Stage: The business starts generating income.
• Scaling Stage: Expand or penetrate new markets.

Focus on One Metric​

To achieve success, founders must focus on the most critical metric. Knowing what the most important metric is can prevent you from getting lost in the world of data.

What Are the Best Metrics?​

There is never a one-size-fits-all best metric. The best metrics vary across different industries. For e-commerce companies, the most important metric is revenue per customer. But for media websites, the most important metric is click-through rate.

Every aspiring entrepreneur should always be aware of the deadly pitfall of building something that nobody wants. That is why the right kind of analytics becomes so necessary. The book Lean Analytics introduces good metrics for start-up founders to navigate through the unknown and assess their success.

Data-driven in the right direction​

Data is vital to business. Entrepreneurs need data to convince others that their ideas will work. Sometimes, entrepreneurs tend to overestimate their success but data will not lie. Data helps founders to stay grounded in reality. However, personal judgement of what data to pursue is also important. Don’t be just a slave to numbers.

What are good metrics?​

In order to stay data-informed, you need to find some metrics which can provide meaningful data. Good metrics have three characteristics:

• Comparable: a good metric can be compared to different time periods, groups of consumers and so on
• Understandable: a good metric is simple and easy to comprehend
• Ratios: ratios are effective and comparable

Five distinct stages by the Lean Analytics framework​

The Lean Analytics framework suggests a start-up will go through five stages:

• Empathy — identify a need that people have / identity your niche market
• Stickiness — figure out how to satisfy the need with a product
• Virality — add features that attracts people
• Revenue — the business starts to grow and generate revenue
• Scale — expand or break into new markets

Focus on one metric​

To achieve success, founders must focus on one metric that’s most critical. Knowing what is the most important metric prevents you from getting lost in the data world.

What’s the best metric?​

There is no best metric in general. In different industries, the best metric differs. For E-commerce companies, the most important metric is revenue per customer. However, for media sites, the best metric is the click-through rates.

Between 2014 and 2018, Uber built several "wheels," such as the service discovery tool Hyperbahn, the task queue Cherami, the MySQL-based NoSQL Schemaless, the resource scheduler Peloton, and the service deployment platform uDeploy, among others. Now, with layoffs affecting even engineering teams and stock prices falling below 15-year valuations, were these "wheels" a success or a failure? Should startups hire people to build wheels, or should they adopt existing solutions?

Management is a pyramid; it’s people lifting people, and individuals rise through the support of others. The first lesson in political acumen for any manager is to recruit as many people as possible. Hiring a large number of engineers in VC-funded companies is also an interesting metric because investors, lacking technical knowledge, often believe that companies with more heads naturally perform better.

Thus, many individuals have a motivation to hire more people. But how do we measure the legitimacy of this motivation? This is relatively straightforward for mechanical work, such as in factories, where output is directly measurable. However, it’s less clear for intellectual work, especially coding. Bill Gates once said that measuring development progress by lines of code is akin to measuring aircraft manufacturing progress by weight. I’ve even heard that Google has dedicated teams to calculate each group's contribution to the company.

Managers like to hire, while engineers enjoy building wheels. On one hand, creators inherently relish the joy of creation; on the other hand, engineers may develop an undesirable ego, feeling that using others' technology implies their own skills are lacking. Managers provide the "what they want," while engineers provide the "what they want to do," resulting in products that are a product of these two forces.

For instance, a traditional retail company hired a new CTO from Silicon Valley, who began hiring a large number of engineers for projects and insisted that once good talent was found, useful projects would follow. He also wanted to package some internal software as a service, even though these services still ran on a mainframe. The CTO genuinely believed in this approach. The key question here is whether these efforts yield a positive ROI (return on investment).

If ROI cannot be known in advance, how can we effectively balance hiring on demand and avoiding resource waste? The answer lies in focusing on "building prototypes for proof of concept (POCs)." Test the waters with minimal investment; if it works, hire more people; if it doesn’t, don’t hire.

If ROI can be known in advance, then the answer becomes a simple arithmetic problem. For example, if HipChat charges $5 per person per month, and Uber has 60,000 full-time employees and contractors, then the monthly service cost would be$300,000. In contrast, hiring one engineer to modify open-source Mattermost would only cost $30,000 per month. Thus, "building wheels" could save about one-fifth to one-tenth of the original cost.

There are also companies that have built many wheels while thriving, where strong management and engineering culture play crucial roles. They advocate for simplicity and technical responsibility. If external wheels offer specialized, mature solutions, they will adopt them; if external wheels are overly complex and uncontrollable, they will build their own. I recall that one significant reason Uber did not adopt Cassandra immediately was the lack of internal experts on Apache Cassandra, leading to technical unpredictability.

The principle of simplicity does not conflict with attention to detail. For example, you might first choose an expensive, cumbersome ERP from Microsoft, SAP, or Oracle, and then write some services yourself for areas that require special handling closely tied to your business, ensuring those services are concise, efficient, and easy to maintain. Conversely, many new-generation startups fail in ERP because they neglect details, even failing to implement the most critical "audit" functions, such as double-entry bookkeeping in accounting.

When you know where you should go, it is too late to go there; if you always keep your original path, you will miss the road to the future.

Charles Handy makes an analogy as his road to Davy's Bar. Turn right and go up the hill when there is half a mile to the Davy's Bar. However, when he realized he was on the wrong way, he arrived at Davy's Bar already.

The growth curve is usually in an "S" shape, and we call it S-curve or sigmoid curve. To keep the overall growth rate high, you have to develop your second S-curve before it is too late to invest your time and resources.

Intel's CPU, Netflix's video streaming, Nintendo's gaming, Microsoft's cloud are all excellent examples of the second-curve-driving businesses.

How to find and catch the second curve takes vision and execution. You have to input more information and continuously sort them to identify the best opportunities. And then, once a chance identified, you need a reliable team to fight the battle and figure out whether it really works.

What makes you succeed may not make you succeed again. There is always a limit to growth. The second curve theory helps us reflect on why and how to embrace the change and live a more thriving life.

When you know where to go, it is often too late; if you always stick to the original path, you will miss the road to the future.

Charles Handy illustrates this with the analogy of "David's Bar": on the way to "David's Bar," you should turn right up the hill when you are half a mile away. However, by the time he realized he was going the wrong way, he had already arrived at "David's Bar."

Growth curves are typically S-shaped, which we refer to as the S curve. To keep the growth rate consistently high, you must invest time and resources to develop a second S curve while there is still time.

Intel's CPUs, Netflix's video streaming, Nintendo's games, and Microsoft's cloud services are all excellent examples of businesses driven by this second curve.

How can you discover and seize the second curve? You need to input more information, discern good from bad, and identify opportunities. Then, once the opportunity arises, having a strong team to tackle the hard work is essential to determine whether you have truly found the second curve.

The reasons that made you successful in the past may not lead to future success; growth always has its limits. The second curve theory helps us reflect on why and how to embrace change for a better life.

Facebook's VP of Growth, Alex Schultz, once discussed with Mark Zuckerberg why they succeeded. The answer isn't that they are exceptionally smart or experienced, but rather that they work incredibly hard and execute effectively. Compared to execution, growth is optional. Everyone understands the reasoning; the difference lies in whether people can execute quickly.

Execution is challenging, and there are ten reasons why growth execution fails.

1. Not starting with retention. Growth without retention is like a ring of fire in a wheat field; it will eventually burn out. Without retention, there is no Product-Market Fit (PMF). A sign of achieving PMF is that the retention curve in cohort analysis flattens out.

2. Believing the product is everything. Based on this misconception, people tend to mistakenly focus on "doing more" with the product rather than "doing better" with the existing product. Growth is a process of "doing better." Builders love to create new things, but as a leader, you need to ensure they are at least partially accountable for the results.

3. Looking for a silver bullet. Great products are polished through time and effort spent on details, not conjured up like magic. Good ideas are a byproduct of having many ideas; you can't control the outcome of finding good ideas, but you can create a process that allows more good ideas to emerge.

4. Lack of focus. It's about cutting down one at a time, not chopping at everything in sight. How do you break through the threshold effect here? Remember two points: 1) Most companies' primary scale comes from a single channel, and 2) There are only a few methods to scale; choose one.

5. Insufficient data and analysis. The challenge here is that it's hard to quantify the output of data analysis, so you must firmly believe that this is very valuable, as it enables you to make the right choices.

6. Not enough experimentation, far from it. HubSpot ran thousands of experiments in just six months.

7. Not asking why. When an experiment ends poorly, they just move on to the next one without asking why.

8. Not doubling down on successes. If you find a channel that works exceptionally well and hasn't been fully utilized, continue to invest in it. Zynga discovered that a virtual gift in one game was highly profitable and that viral marketing worked exceptionally well, so they immediately added this feature to all their games.

9. Insufficient resource allocation. Growth requires dedicated teams to focus on it.

10. Unable to embrace change. A company's growth typically goes through three stages: Traction, Transition, Growth. The reasons for success in one stage won't necessarily help you succeed in the next stage.

Question: For Hubspot's freemium and fully automated (touchless) software business, how can one achieve the highest growth in the least amount of time while being VC-backed?

Solution: The Four Fits Model identifies four interrelated elements that drive company growth: product, market, channel, and model. The author believes these four factors are interconnected and must align with each other.

PMF: Product-Market Fit. There are two types of companies in the world: tailwinds companies and headwinds companies, with the distinction being PMF. Achieving PMF means your product has a group of users who repeatedly engage over time, generating enough profit to support continued growth; it means your product has sticky users, resulting in a retention curve that may decline over time but ultimately levels off.

PCF: Product-Channel Fit. The attributes of the product itself determine the best channels for promotion. Simple, universal products correspond to inexpensive, mass-market channels, while complex, niche products correspond to specialized channels.

CMF: Customer Acquisition and Business Model Fit. On the ARPU ↔ CAC spectrum, high ARPU corresponds to high CVC; low ARPU corresponds to low CVC. The concern is that if ARPU is set too high, low CAC users cannot afford it, and if ARPU is set too low, there won't be enough revenue to sustain high CAC.

MMF: Business Model and Market Fit. Our goal is ARPU × total consumers in the market × the proportion of consumers you can capture >= $100 million. If this equation does not hold true, you need to adjust your business model to increase your pricing or target a broader user base.

When using this growth model, there are several key points to consider:

1. The premise is a target VC-backed $100 million business.
2. If you want to change one element, you must adjust others accordingly.
3. The elements themselves are constantly evolving.
4. It is best not to change too many elements at once; if you are unfamiliar with the related fields, you may struggle to manage the changes.