DNA-like culture

Continuously learning and evolving
Creating great products that will impact every person in the world is an immense task. Success requires a culture of professionalism, consistency, learning and rapid change. We define our DNA, and we change it as we learn new and better things. Our DNA is our shared memory for how to do things right.

Be consistent

• with yourself
• with your peers
• with existing work methods
• with existing codebase
• with the industry, if no Bright Data internal method exists

Code style

We are radically precise in keeping our codebase perfectly consistent with our coding conventions. When none exists, or the specific case is not covered, we use the existing current codebase style as a guide.

Email style

Email consistency, just like source code consistency, will help you handle large amounts of email efficiently.
That’s why we keep our email styling consistent with our email style guide. Although the guide is thorough, look for additional conventions. It may seem unusual at first but you’ll learn to love it once you get used to it and its efficiency.

Create procedures

When we do something new, or something un-documented, we stay consistent by creating a procedure. This documents the task we are doing, to ensure consistency the next time this, or a similar task is carried out.

Radical efficiency

Learn

When we do a task which is not standardized, we first try to find out if and how others did it previously. We will also provide you with general knowledge you need while doing specific roles in Bright Data. If more information is needed, there’s always Google!

Learn from unwritten de facto standards

Not all aspects of tasks you will be given will have a written standard or procedure. So how do you learn to do them correctly – by seeing how others did it previously, and learning from them.

Learn by imitation

Imitation is a very powerful learning tool. Look at the highly productive veterans in the company, and try to emulate their working habits, large and small – they’re you’re best resource.
If you choose to imitate the veterans who best fit your character and style of work, you will see that your efficiency and productivity will be upgraded.

Teach

Be an enthusiastic agent of the DNA – spread the word, refer to it in your communication, ensure that your daily activities are in line with it, teach others about it, and help new employees get to know it – it will be like showing tourists around your own city, you’ll rediscover it again and again.

Kill obsolete features

Old features hold us back. They prevent us from moving fast into the future.

If you see procedures that are no longer needed, features in the product that are no longer in use, or no longer relevant, unnecessary documents etc. – remove them! Removing obsolete procedures/code/features significantly simplifies our product and daily work, makes it easier to change things going forward, makes us leaner, more agile and efficient!

At Bright Data, we try to get rid of outdated and unused stuff, be it big modules and services that no longer add value or small pieces of code.

We go the extra mile to remove code/modules/features that are obsolete and no longer in use, as well as ‘future use’ code that was never used.

For example: If ‘future use’ code is still unused, with no signs of anyone having worked on it for the past two weeks, it clearly should no longer be there. We either release it or remove it from our source code. We don’t accumulate things that may be useful someday; either use them now or forget about them. This is what radical efficiency is all about.

Our users come first

Our users and customers are the reason for our existence – our most significant asset. We try to constantly understand their needs, find out their pain points and solve them. We constantly innovate, improving our services, features, and products – we do everything we can to bring them significant value. We should aim to be liked, and even loved by our customers by doing things that are net-benefit for them. When evaluating our business decisions, we ask ourselves ‘would this decision make our customers love us more?’.

Why it is essential to put customers first

Mindfulness: think before you act

We strive to be unswervingly self-aware, which fosters being intentional about how we act, what we do – and how to ensure that we are constantly improving.

Our behavior and actions should have a well-thought out set of assumptions, that are based on concrete data, customer feedback or accumulated observations we’ve made. We build our solutions on top of these underlying assumptions, making sure they are also well-thought through from the beginning, on to the full flow and the final result.

Having a well-considered set of assumptions up front helps us make our actions more consistent. If the action is later found out to be flawed or incorrect, it allows us to find the root-cause in the underlying assumptions that was used and improve it for future actions.

Mindless actions are a barrier to future improvement, because they were not derived from sound reasoning.
Even hacks should be well-considered.

Even hacks should be well planned. Especially hacks!

Hacks are a very powerful tool to quickly solve real problems, and implement real features with great value. But in return, they require a thorough thought process before you get started. This is essential – make sure the hack is worthwhile, and is not going to cause damage, by tracking its performance and treating every hack as an experiment that can be rolled back quickly

We are a professional team

We’re a team – like a pro sports team made of champions. Bright Data hires and develops smartly, so we have stars in every position. That includes you!

Who we recruit to join the team

We look for people who share our values: ambitious pros who love to get stuff done, love to learn and love working with colleagues who share these values. They are smart and masters of their craft. Having these types of ‘stars’ in every position makes it a pleasure to work together.
However, any interview process is limited and cannot be fully predictive. We hire candidates  who show traits of being a star. If we are not 100% sure that they are a perfect DNA fit, we transparently share our concerns with the candidate – then we go ahead and hire for the bootcamp. This gives a chance to learn the company DNA and become a productive team member. The first weeks together serve as a mutual get-to-know-each-other period.
We rarely let people go after they successfully practice the company DNA, because by then the person has shown great capabilities and ability to let them flourish at Bright Data.
Our best new employees were those who made an effort to learn and implement the “Bright Data way”, on their own and with the assistance of their mentors. This is especially true and important as the company grows and hires new employees faster than ever.

Joining the team – Bootcamp

Congratulations on being selected to join the team! Professionals like you are rare, and are what excites the rest of us at Bright Data. We look forward to you becoming an integral part of our team. The 3 week Bright Data bootcamp is your first step from candidate to a fully-fledged team member, where your mentor will guide you to success. You will learn the workflows, start with simple tasks and move up to mini projects. Initially you will receive tasks that don’t require background knowledge of our products, allowing you to focus on the workflows, make your first commit on the first day, or that you are solving a support tickets on the first day, or adding a new customer to the CRM (or anything else that you can do on the first day, depending on your role), and start contributing from day one! Your first day at work will include developing a small feature and releasing it to millions of Bright Data users! The tasks will get deeper into our technology as you advance.
We will provide you with a list of items to dive into prior to bootcamp, including: information about Bright Data, its products, DNA, coding conventions, basic tools and methods of work, and of course access to your mentor for any questions you may have in advance.

Becoming a team Veteran

Congratulations on successfully completing the bootcamp! You are now on your way to becoming a Bright Data Veteran. The goal of this process is to fully integrate you into the Bright Data team. Here’s the process you’ll be going through:

• Bright Data Starter (first 3 to 6 months): During this period, you will be assigned larger tasks that will allow you to make significant contributions while actively learning about the company’s DNA, software architectures, and work methods. You will still have code reviews for most of your commits, while in some cases you will be approved to commit without a pre-commit review session – your code will only be reviewed after the commit, and sometimes even only after deployment.
• Bright Data Junior (first 1 to 2 years): Now you are well on your way becoming a major contributor to Bright Data’s products, developing specific domain knowledge in fields that are of interest to you within Bright Data. You may commit directly to the product tree without prior review, and you will see your contributions going live to millions of users within hours of being developed. At this phase you are still internalizing Bright Data’s DNA and best practices, and should welcome feedback about your commits from Bright Data Veterans.
• Bright Data Veteran (after 1 to 2 years): Congratulations! You are now a Bright Data Veteran – well and truly part of the Bright Data Team. You are a major contributor, a knowledge center, and a person who can help starters and Juniors get up to speed on the Bright Data DNA and best practices through mentoring, and code reviews. You’ve come a long way, well done!

Bright Data Veterans are core to the team. You will make enormous contributions to our products, our business and our values.
We will make your work environment the best it can be, we will care for your work/life balance, your compensation, your happiness and your career, allowing you to move between tech groups to work on things you care about. We will do everything we can to make Bright Data the best place for you.
If you choose in the future to check out other opportunities outside of Bright Data, we will always welcome you back as we’ve done in the past.

Radical Transparency

We communicate openly, clearly, truthfully and with precision. Radical transparency allows for radical efficiency! We share all information within our team, as well as in our ecosystem (customers, partners, market) – unless there is a compelling reason not to. We have an open-door policy across the company, you can knock on anybody’s door, all the way up to the CEO, should you require input or advice.

All open, no secrets

Except for compensation packages, all work-related information is open to everyone at Bright Data; from source codes and working hours, to project status and reports. This includes future plans for the company, which are usually addressed in the monthly All-Hands sessions.

As a matter of fact, every single day Bright Data’s CEO sends out an email, company-wide, called Fast5 – these are 5 quick takes on where the company stands, from daily P&L, to new joiners and more.

Avoid BCC in emails

Try to avoid adding BCC (blind carbon-copy) recipients – it is usually a sign of non-transparency.

No black-boxes: Share all info!

We each provide clear information on areas of responsibility and expertise, our current tasks and activities. We do so, to allow anyone to get access to the full view of ‘raw data’ and to be able to question or improve our decisions and actions in our area. After all, transparency and team collaboration are two sides of the same coin.

  Q: What did you do today?
A: Helped customer integration.

  Q: What did you do today?
A: Helped customer 'greatprice.com' integrate python code snippet version 2.7.5. It took around 3 hours.

  Q: Why did the site go down?
A: Sorry, my mistake. Won't do it again.

  Q: Why did the site go down?
A: I deployed code that caused DB to be 30% slower, making the site to go down.
I reverted it already, and now it is all OK.
Site downtime during this was 2 minutes.
To prevent this happening in the future, I added metrics and alerts on DB response times. I also added a unit-test to validate DB performance, and in the future I will also test in small scale DB schema changes that may cause performance problems.

  Q: Do you have the list of people who were already migrated to Windows 11?
A: Sure. I have the list on my laptop, I can show you.

  Q: Do you have the list of people who were already migrated to Windows 11?
A: Sure. The file is located in our shared IT folder. I'll send you the direct link. Around 65% were already upgraded.

  Q: Let's add an 'invite a friend' feature.
A: It is complex to implement, and will bring little value.

  Q: Let's add an 'invite a friend' feature.
A: It's complex to implement: I estimate it will take me around 2 weeks, because the tracking DB module will need adjustments. On the other hand, I think it will bring little value: I estimate its response rate will be 2% or less - which is not significant.

Privacy

Information is open to everyone at Bright Data. This transparency is provided to allow you to get your work done without requiring permissions, which would slow you down. However, accessing information that is not directly required for your work is forbidden. Also, to protect our user’s privacy and our trade secrets, it is absolutely forbidden to share internal Bright Data information with anyone outside of Bright Data. Any such sharing of internal information will lead to immediate termination and further consequences.

Communication should focus on clarity not politeness

It’s important for us to communicate clearly, delivering direct feedback. Critiques allow for self-improvement. Political correctness prohibits conveying messages successfully. Of course, we absolutely do not condone being aggressive or disrespectful.

Feedback

We provide direct feedback. People who are not accustomed to it, may consider it blunt. Remember that this is not a reflection on your abilities but on a specific result, and that the goal of this feedback is to allow you to learn. When Steve Jobs was asked about his sometimes “harsh” feedback, this was his response:

  When you've got really good people, they know they're really good, and you don't have to baby people's egos so much. And what really matters is the work. And everybody knows that: That's all that matters is the work.... And the most important thing, I think, you can do for somebody who's really good and who's really being counted on is to point out to them when their work isn't good enough.

So we provide feedback about the work itself, not about the person doing it.

  You do lousy work!

  This report is useless to me/the client/the problem because you did not make the connection between the clicks on our PPC campaign to the actual product sales we made as a result.

We do not use cynicism or sarcasm in our communication. We do talk about the problem directly, with clear facts. With the ultimate aim of learning/teaching not to repeat the problem.

  Is this because you didn't bother to do any QA?

  Finding out these problems in production shows that proper QA was not done. You should check all relevant sites on production after deploy.

Identical internal and external communication

Our internal communication should be identical to our external communications, since ultimately this is the language that we will use with our customers and partners out of habit.

Be precise, clear, and specific

Be exact in your communication; avoid vagueness and jargon. If you are too generic, you leave too much space for ambiguity; specific communication ensures messages are delivered correctly and expectations are met. High level terminology or jargon, moreover, can antagonize the recipient or a client, complicate relationships unnecessarily and will delay the resolution of a difficult issue.

Specific

We communicate precisely, with a level of detail that mitigates any room for misunderstanding – vagueness does not instill trust, vagueness is the antithesis of what we do and who we are. Here are some situations to demonstrate the type of detail we’re after:

Easier for the writer

  Hey guys - take a look at fast-stream.com

Easier for the readers

  Hey guys - take a look at fast-stream.com.
It's a review of the video streaming market, showing that P2P tech is taking off in APAC. Consider if or when this gets added to our offering.

• Save reader’s time (Mindful of coworker’s time) – provide a summary: It’s a review of the video streaming market
• Point readers to what’s interesting in the article: showing that P2P tech is taking off in APAC
• Specify actions (Action-oriented) you want them to take: Consider if or when this gets added to our offering

Another vice to look out for is high-level terminology. Sometimes high-level terms are only used as an excuse for not making an all-out effort to handle a difficult issue:

  We must make our users happier

while we prefer a more specific and less vague wording; in this case:

  I saw a 3.5% decline in daily usage. I checked it out, and it correlates with a 23% increase in response time. I will work on fixing this issue tomorrow, and update once fixed.

At Bright Data we make a special effort to always be specific when we communicate. Here’s an example of an email that we may want to send, and how we can improve it:

  I would be happy to hear more about the things you have written.

At Bright Data, the email we would send would be:

  Please share the unique visitor data for October 15 which led you to this conclusion with me. I'd like to publish that data in our next blog.

This email is more precise and specific, resulting in better communication.

Accurate

Explain your idea accurately and concisely, your messages should also be supported by good reasoning.

Provide data, facts and specific use-cases

In Data We Trust
The decisions we make are based on real world data. When communicating, the use of data helps our peers understand the exact issues you are trying to solve, and why we are trying to solve it. We focus on real issues, not on theoretical problems or rare use-cases. This principle is called Genchi Genbutsu (“go and see”) in the Toyota Production System.
We try to make mindful rational decisions, based on real world data, facts and use cases.

• “Better design”: With this type of a statement you need concrete facts on why this, what exactly does it solve, is what it solves really important enough to be solved, how much value will it bring, how much work and effort is required to implement this design change…
• “Very dangerous code”: Will it really cause a bug? How often? And if it does cause a bug – will the bug not be detected and fixed very quickly? How severe would the theoretical damage of such a bug be?
• “But what if the user clicked here, and then here?”: Give a use case on how and why this could happen. Is it really common for users to do this? And if they did, how bad would the impact be?

Providing concrete data will give your colleagues a firm basis for either agreeing or disagreeing with your idea. This scientific approach and scrutiny improves the quality and assurance in your ideas or suggestions, once they pass a healthy amount of questioning.

Think – don’t brainstorm

Think deeply about the subject, form a viewpoint, and present it as an actionable plan. This process leads to concrete action. Brainstorming is the opposite of constructive thinking. So in real terms, you’re welcome to bring in an extra set of eyes onto an idea, just make sure you’ve thought it through 100% before presenting it.

 If you don’t agree, challenge! Yet focus on getting things done

Stand up for your beliefs: challenge tasks that you believe are wrong or can be improved, even if it’s from the CEO!
But, this should not come at the expense of getting things done (GTD).
How to dispute while staying productive:

• Give your feedback immediately
• Before you express your objection, make sure you’ve thought it through – to make sure your objection has sound reasoning.
• Be specific and accurate in your reasoning.
• In the meantime, implement what you partially agree on, or something minimal that will partially satisfy the person requesting, and complete it once the disagreement is resolved.
• If the person requesting does not agree with your reasoning – then do as requested.

Immediate

We do things immediately, so that we can evolve, innovate and improve faster
A startup’s engine for creating better products is a constant Build-Measure-Learn loop. It’s unlikely to succeed on the first try; so we iterate on the product by experimenting, until it fits. The more responsive we are, the faster our products will evolve and improve.

Do small tasks immediately

We do quick tasks immediately, even when they’re not particularly important, to avoid the overhead of prioritizing and of reopening their context. It also feels good to finish your day with a lot of tasks completed!

Do small tasks yourself – don’t delegate

Quick tasks are not worth delegating. If the communication and management involved in the delegation process takes more effort than the task itself it’s simply better to do it yourself.
If you receive a small task that does not require any technical skills (for example, typo corrections), help the sender learn how to fix it himself. That’s how we all improve and ultimately, it’s beneficial to us all!
As the company grows, this may become more difficult, because there will be more people with potential overlaps in their ownerships. This is not a good situation but it can unfortunately happen. It’s crucial to identify such incidents as they happen (without clear ownership unnecessary delegation increases) and solve them on the spot by being transparent about them and determining clear ownership

Note: this doesn’t strictly apply to managers, since delegating efficiently is part of their role

Decide fast

We promptly discard new ideas that appear to be flawed and adopt brilliant ideas as soon as possible. If a new idea presents multiple pros and cons, and we don’t find it brilliant after a short discussion, we put it on hold or discard it entirely. As the company grows, deciding fast becomes more challenging, as more people are affected by any major decision. If a major decision impacts multiple employees, it’s the owner’s responsibility to quickly talk to each relevant stakeholder prior to making the decision, gather quick feedback, and adjust if necessary. This is in line with our radical transparency policy and will make the work day easier for all involved.

Manage your inbox

Email responsiveness and never losing an email (forgetting to respond) is critical for effective and reliable email communication. So we strictly follow the email handling guidelines, which include rules such as:

• Clean out your inbox constantly – never end your day with more than 10 unread emails in your inbox. Move emails out of inbox (to Archive/Trash) after handling – “Read” status should not be used as an indicator for handled emails.

Prioritizing incoming tasks

What’s a small task and what’s not?
When to act immediately and when to postpone?
The table below can help you plan your time efficiently:

Time to complete	What to do?
Up to 10 min.	Do it immediately, to avoid the overhead of postponing and reopening the task later and respond to the requester.
10-60 min.	If possible, try to give an immediate or partial solution/response. Log it in your work plan and respond to the requester that it will be done within the next 1-3 days. Notify the requester as soon as you complete the task, or if it gets delayed again.
More than 60 min.	If possible, try to give an immediate or partial solution/response. Log it in your work plan and update the requester on when you plan to implement it. Mark it in your calendar, and update the requester again if you decide to further delay.

It’s OK to change a schedule if other tasks come up or take longer than expected, but always update the requester with the new schedule.

Immediate Answers

Discussions with questions left unanswered lead to other discussions. To end discussions with results, all questions should be answered, even if the answer is an estimation. Estimations allow us to proceed with the discussion and take action. The actions can be adjusted later with the accurate answers.

  Q: How many clients didn't manage to download our extension?
A: Let me check and get back to you.

  Q: How many clients didn't manage to download our extension?
A: About 1K.

Provide ETA

When asked to do a task, provide the requester with an ETA. This helps the requester plan his other activities.
If you see you will not be able to meet the original ETA,it’s OK to change it, but update the requester with a new ETA as soon as you know you will miss the original one.

  Q: Write a case study for our new customer, XYZ media inc.
A: Will do.

  Q: Write a case study for our new customer, XYZ media inc.
A: Will do, ETA for 1st draft end of day tommorrow.

Incremental and evolutionary

We split large tasks into small tasks that give immediate value, so that we can make quick incremental improvements
We’ve learned the hard way that we do not know how a product works for customers, until they’ve been using it. It is incredibly frustrating and wasteful when we put in major efforts on an idea, only to find the whole direction was wrong for a reason we could have predicted.
We’ve learned over the years that you should release very early, and make incremental improvements.

Minimal Viable Product (MVP)

When you work on a product, feature, document, graphic design or any form of delivery (even a bug fix!), one of the most creative and important parts of the design is to design the smallest conceivable delivery that brings some initial value. Design it, make sure you have a proper way to measure and track it, and a way to quickly roll-back if needed, update relevant stakeholders with your plans/design/timeline, asking for feedback, release it, and then iterate on improving it.

Rapid experimentation

Fast evolution requires rapid experimentation.
We love experimenting with new ideas/features/technologies/solutions. We measure the experiment’s worthiness by the cost (building it, deploying it, cost of failure) and by the expected outcome. If the cost is too high, or the best expected outcome too low, the experiment is probably not worth doing.
We love cheap experiments that can lead to high outcomes (high return on investment).

Fast feedback loop

A fast feedback loop reduces the time it takes to build a feature as originally intended, by getting the feedback regarding a wrong direction early on, before completing the whole feature.

• Split up a feature into as many committable subtasks as you can, so that each subtask gets its own incremental feedback early.
• Done some initial UI? Even if the feature is not working, send a screenshot or animated GIF to demonstrate how it will look, to get early UI feedback.
• Basically working? Even if the feature is only partially working, call in the requester to play around with it (or remotely via a screen share).
• Completed (deployed)? Send the requestor a link to the feature, and a diff URL to show what has been done.

All examples cited above minimize iteration time and bring value almost immediately.

DONE is better than PERFECT

“A good plan violently executed now is better than a perfect plan executed next week” George S. Patton
Getting things DONE has a very high value. It solves the problem, and allows determining  which additional improvements are required.
PERFECT is the biggest single enemy of DONE: trying to do a task perfectly will in most cases prevent us from completing it.

Pragmatic Craftsmanship

We take pride in our work, and invest time in producing a quality outcome. However, we also take pride in continual progress and moving fast, so we make sure not to take craftsmanship too far before shipping.

Move fast and break things

Moving fast will ultimately be why we succeed.
Yes – we break things while moving fast, but we fix it even faster!

Listen to an interview with Mark Zuckerberg, Founder & CEO of Facebook, talking about moving fast and break things.

Gradual Release

Rapid experimentation should be paired with damage control.
We deploy new or improved features in stages (1%, 10%, …, 100%) so we can get valuable usage feedback quickly and limit damage if there are errors or design flaws that we didn’t think of.

Little better every day

Do only a little better every day, and you will be 37x better by the end of the year.

Incremental task handling

When starting a new task, we break it down into smaller tasks that can be released on their own, and can bring their own value. A good size increment is a few hours of work.

An example of that principle is this DNA document itself! When we understood that we wanted to formally define our DNA, a quick doc was written up in a couple of hours, with many naively stated points, and ‘please contribute more here’ types of ideas. That document was uploaded to our website under https://brightdata.com/dna for everyone to see, immediately and transparently. From that point on, many people read and improved, erased, and added to make this document better with every iteration. Even today, it is still a work in progress…

Give immediate partial results/response/value

Often, a question or call to action may be stuck in your inbox for a long time because you are not sure of the complete answer, and do not have the time to work on the whole ‘project’. It’s better to give an immediate partial results/response/value, and email the full results later. This enables the other party to start with something, and possibly shed light on the rest (for example, the rest might not be needed for the other person to make progress).

Split up large tasks

Split up large tasks into smaller tasks that give immediate value even before the large task is completed. Example: When developing a large new feature such as the stats dashboard for the CDN, define a small set that brings value that you can commit in one day (such as only start time and only for past 24 hours), go live, and improve iteratively from there with more commits every day.
You cannot complete the task within a day? Work is still in progress? No problem, commit the partial feature (disabled if necessary) and state it’s “Work In Progress” (WIP), so your code will be added to the codebase and every day shows progress.

Get something small DONE every single day

We make sure every day we personally get some task (big or small) completely DONE: do a commit, close a deal, solve a real problem…
Even if it looks like small progress, it will ensure your incremental contribution.

No branches

At Bright Data we deliberately avoid branches for improving transparency.
Branches hurt transparency, because there is no single shared view of all the info, since lots of info gets hidden into many branches that are not viewable in a plain, simple view. For example: try viewing Videojs Project in GitHub with all its 2900+ branches (forks), concurrently. It is simply impossible. If all forks were merged into one single top-of-branch best-of-all, all possible features of videojs & its branches (forks) would be easily available to all.
Branches contradict two other core DNA values: incremental and immediate:

• Immediate: We do continuous deployment, so commits are (nearly) immediately deployed. Branching contradicts it, because the commit is not immediately deployed (only if-and-when the branch is merged). Also, if we have branches, the commit is not immediately deployed.
• Incremental: Instead of having every commit incrementally modify our product, branches make ‘bulks’ of changes at the time the branch is merged back into the product.

Action-oriented

We choose to solve a problem over simply stating that it exists. We prefer action.
We can only bring more value to our customers and to each other through actions. Offering new, well thought-out ideas is great, but it must be followed with an action plan of how you get it done, so that your ideas turn into products.

Get things done

See David Allen’s Getting Things Done (online introduction) system: every commitment should be clarified until it is actionable, any project can only be completed by taking appropriate actions until it is complete, planning is a support tool for getting concrete, physical actions done.

Can do attitude

We’re winners by default. A winner always thinks before they act, to see if there’s a way to execute a task. A winner gets excited about a problem, especially if it looks impossible at first. After all, a challenge is just another opportunity on the road to success

It’s always easier to find why not, but real innovation comes when you understand that there’s someone in the world that can probably do it, so why shouldn’t it be you? We have all the resources to say “Yes, we’ll find a way”, so only say “No, impossible”, when it really is the case.

Issues, Problems and Bugs

Problems are everywhere. But they are opportunities for improvement. A Every product has an endless number of bugs and points to improve. Many things need to be changed. Get stuck in and solve the problem, you will be adding immediate value!

Translate issues solutions

Translate issues/opinions/suggestions/problems into actionable solutions.

  I think those guys are doing a great job on their onboardin is just an actionless opinion.

is just an actionless opinion. An actionable version of could be

  Those guys let the customer experience the value of their product within one click and 10 seconds of site landing. We can have a similar effect by putting an action bar in our home page. I will create a mockup for an MVP, and test it out.

Reality-based actions

We focus only on reality: on real customers, real use cases, problems that actually happened, and our actions are based on these real immediate issues. We avoid future planning, or solving problems that haven’t happened yet. Our experience showed us that any work we spent on theoretical issues always turned up in the end to be a waste of time. At Bright Data, actions based on future theoretical issues are called ‘over engineering’.
By handling only today’s problems, we place our trust in evolution to guide us to a successful future.

Research by delivery

Researching and learning in Bright Data is always carried out by action, by doing, by implementing, by delivery.

• New to nodejs? You will learn it at Bright Data by actually writing code in nodejs.
• Need to learn how to deliver code contiguously, over 20 versions a day? In bootcamp you will deliver your own code and learn by doing it yourself.
• Want to research whether to create a new product? Just create an MVP, release it, and learn from the reactions of the customers.
• Researching the right architecture to solve a performance problem? Just experiment by trying out small changes in the existing code, and see how they improve.

We research via real life experimentation, and by incremental steps to see if the direction of our solution is correct. We implement many small ideas in different directions and see what works and what doesn’t. This way, once we solve the problem, it will be a field-tested solution, already implemented and delivered in the real world. It’s efficiency at its best!

Solve it

If you encounter a problem, do not suggest how to solve it – solve it! Adding value through efficiency once more!

Make sure it is really solved!

You have resolved a problem or finished a task – great work and well done!
However, it is not truly DONE until you have communicated with your customer directly, and received their feedback.
Note that it can be a Bright Data customer or an internal one (one of Bright Data’s employees), for whom the task was done.

Do, don’t talk

“When you have to shoot, shoot – don’t talk”
Bright Data’ers are doers, not talkers. Actions, not words.
Products are created through coding, talking about them delays the progress.

Do yourself

The best work is done alone or one on one, not in meetings. The only scheduled meetings we have at Bright Data are the ‘all hands’ meetings every two weeks and they are limited to 10-20 minutes. Other than that, we don’t have meetings. We believe that while sometimes they can be productive, we encourage you to keep them to a minimum (both in terms of attendance and duration). Do one on one ad-hoc meetings in person or by video, pulling in an extra person when really needed.

What about situations where multiple stakeholders are required to completely solve a problem?

We’ve found that the deepest solutions, which are also usually most time-efficient, involve only one-on-one meetings. Here’s how: on their own, the owner of creating a comprehensive solution creates what they find to be the best overall solution. Then they incrementally iterate on it with each stakeholder separately, considering the new feedback received each time to make a better and better plan.

Avoid meetings

Meetings are the opposite of doing. When you are hosting a meeting with your peers, you are not: writing code, debugging, finding and solving problems, talking to customers…. Avoid meetings – just talk to whoever you need to ad-hoc, over lunch etc. And never set recurring meetings.

Convert discussion into action

After discussion, summarize to your peers the main points you had, which next actions need to be taken, and who is responsible for each action. Actions should be recorded in the work plan to make sure nothing is forgotten or overlooked. See GTD.

Actionable communication

Our communication is actionable, and the action is preferably for ourselves!
We don’t just email:

  Take a look at these conversion numbers

rather we email:

  I saw the conversion dropped two weeks ago (see attached graph). I am now checking which change that took place two weeks ago could have caused it. Do you know of any such change? In any case, I will take charge of fixing this issue.

Individual contributor

Those who complete tasks on their own from start to finish create the largest impact
The people with the largest impact are those who complete tasks on their own, from start to finish. Each manager at Bright Data spends at least 50% of his/her time on getting real tasks done.

Company as a collective of Peers

Bright Data is the sum of its team members. Each team member contributes, tangibly, in real-time to the final product.
Something you can point out proudly to your Mom and say “I did that!”.

Work Peer to Peer directly

Bright Data is a P2P company. But this is not limited to just our products. Our daily work method is also P2P: people in the company work directly with their peers. We do not work through “Managers” (a.k.a. “central servers”…), rather if you want to get something done, you just go directly to the relevant person who is responsible for that domain. Remember, this is in line with our open door policy too.
No managers needed!

Solve yourself, don’t create work for others

Each of us solves problems and tasks independently, from start to finish. If you did some work and passed it on, then just the overhead of the context switch within the company probably wasn’t worth it. Prefer to do the complete task. If you believe you will not be able to do a task  from start to finish on your own, rather pass it on in its entirety to someone who can.

Don’t pass on subtasks

We avoid passing on subtasks – namely, smaller parts of a bigger task – to others: it’s unfair to your peers (you wouldn’t want that done to you either!) and the overhead of context switch within the company makes it inefficient – it’s like switching horses in the middle of a river:

• Involving another person
• Describing the task again
• Passing on all relevant information
• Explaining the full context of the task
• Validating on completion that it was done as originally intended

No ‘half’ tasks

When each of us does a task, we do it end-to-end. No ‘half-baked’ tasks. No ‘helper’ to clean up after us. Even doing 80% of a task, and passing on to a peer the remaining 20%, will sum up to 200%, double than the original task size:

• You 80%: your original 80% work
• You 20%: preparing a good email to your peer describing the task
• Peer 15%: context switch time, learning the email, the task, understanding what’s needed and the background
• Peer 5%: asking you back some clarifications
• You 20%: giving him the clarifications
• Peer 20%: peer’s 20% work (what you passed on to him)
• You 20%: checking the task as a whole and seeing it still has a problem
• You+Peer 10%+10%: closing the final issues to get the task perfect

Total sum of 200%, instead of 100% due to the context switch and communications cost. The overhead of incomplete work is much higher that you would expect – that’s why we avoid it.

Be mindful of your coworker’s time – they’ll do the same for you!

It’s easy to feel like you deserve your coworkers’ time. 

For example, when you’re trying to improve a certain aspect of the company, and your coworker can help out with that, it means the whole company is better off. This is obviously great, But every interaction comes at a cost: your coworker’s time.

This fact is dramatically more important in creative and problem solving fields like computer science, where being in the ‘zone’ can mean the difference between a really productive day and a day where every line of code is a struggle to write.

Getting pulled out of the ‘zone’ can be jarring, and getting back into that mental mindset can take a frustratingly long time.

This goes doubly so for companies with remote workers. It’s easy to notify a coworker through chat or text message or IM that you need their help with something. Maybe a server went down, or you’re having a tough problem with a bug in code you’re unfamiliar with. If you’re in a global company, time zones can become a factor too.

Your coworker may be at home with their kids, or otherwise enjoying their non-work life.

Consider keeping a list of issues you’d like to discuss, and grouping them into one discussion or email to respect your colleagues’ time.

Before asking colleagues questions, try to find the answer yourself. You will find that in many cases, reading the source code, grep, google and our Intranet are your friends.

For example: Don’t ask a fellow engineer “What is David’s mobile number?” – look it up in the contact list.

Let me google that for you

We avoid asking our peers questions we can ask Google: Let me google that for you

Let me grep that for you

Just like Google is great at answering questions of public info, grep is an amazing at answering questions about our source code. The right grep can immediately give great answers.
We made it even easier to grep by our usability wrapper above it: rgrep!
If you can grep, grep!

Check our private Stack Overflow

Google and rgrep did not help? Check our Stack Overflow for Teams in which we provide answers for common (and uncommon) questions.

Writing mindful emails – taking time to save others’ time

We optimize emails we write to make them simple to understand and act on for the recipient. We take time to write the email carefully, then review and modify it before sending out, to make sure we are mindful of our co-workers’ time

  Check out this interesting article:
https://www.smashingmagazine.com/2016/04/html5-media-source-extensions-bringing-production-video-web/"

This email would require all readers to open the article, even if the article does not concern or interest them, and the message’s wording does not focus the readers on what is interesting about the article.

  FYI: this article explains well for those who don't yet know enough about MSE technology: https://www.smashingmagazine.com/2016/04/html5-media-source-extensions-bringing-production-video-web/"

Don’t have the time to write a great email? Better not to write it at all.

Do no harm

How do we move forward fast? By never going backwards!
When every single peer in the company contributes value every single day, a lot, or a little, the company as a whole will move forward rapidly.

Avoid degradation

Implementing a new feature? Trying to fix a bug? Modifying code? Improving the installation flow? Suggesting a new tool? Whatever you do, just make sure you do not degrade the existing situation.

• Every new version of the product must at the very least not degrade the product.
• Every commit must keep the build tree ‘green’.
• Every new tool must not degrade current ease of development.

Wasting peer’s time

A great company is composed of individuals who, on the one hand, are super productive and contributing on their own, and on the other hand do not set back other colleagues during their own work.
You should bring value to Bright Data – at the very least, do no harm:

• Losing a customer
• Releasing a bad feature
• Degrading the product
• Wasting other people’s time

The last item – wasting your peer’s time – is the most significant!
If you commit code that breaks the tree, other developers cannot check out and commit their own work.
If you code a great feature, but in the process you consumed a peer’s time by asking for help, you prevent your peers from progressing in their own features.
Our peer’s time is always more valuable than our own.

• Be mindful of your coworker’s time
• Don’t do half tasks and leave the rest to others
• Don’t write code that will require others to fix
• If asking for help, provide all information in summarized form, without requiring your colleague to search for more details. Make sure this assistance session does not take more than 5 minutes.
• If sharing information, provide it in full and concise form in a short text

Be an Owner, not a Renter

Revolutions aren’t won by paid soldiers; they’re won by true believers in the cause, patriots. Whereas renters are mercenaries, focused on short-term personal gain not deeply vested, owners optimize for long-term outcomes, bridge gaps in organizations, think and act beyond their job description.

Take ownership

By taking ownership, you will be committed to seeing whatever it is you are working on through to completion. Your commitment will be deeper. Add yourself to the Jdoc, then monitor and influence its progress.

Be solution-driven!

Complaints are words. Solutions are actions. Actions speak louder than words and only actions make a change.
Take ownership of problems, resolve them yourself – you can do it and you’ll feel great about it.

Manager? Do it on your own first!

If you need to instruct the sales team on how to sell the product, first sell it yourself. By doing a task yourself first, you will know it better and be able to give better instructions to others on how it should be done.
Listen to an interview with Brian Chesky, Co-founder & CEO of Airbnb, speaking on doing tasks yourself.

When to hire additional people to your team?

Hire an additional person to your team for a specific function only once that function is already working well in your team, and you just need one more person to do it. This function should have already been proven to work well by one of your existing team members.
Do not hire additional people to your team if you are hoping that an additional person will bring new value that your team is not yet bringing.
For example: You manage a marketing team, and you want to generate content for press, but have never made a real ‘machine’ that can generate content and get it published.
Do not hire a person to do this before proving it can work with the existing team. Rather, one of the team members should create a small machine that makes content (by writing it themselves), getting interest from publishers (by contacting them), and getting the piece published. This experiment will teach the team if its at all possible to create such a machine, what is needed to create such a machine, and what the exact requirements are for the person to be hired.

On-call

Bright Data is a global company that provides mission-critical services for countless customers and users. Therefore, we must ensure a very high level of reliability. Each engineer shares responsibility for keeping our services running smoothly 24/7/365.
Once you are familiar with the Bright Data infrastructure, you will join the on-call rotation for your team. Each shift has a 2nd and 3rd line engineer, so there is always help available if the problem is serious.
We strive to make on-call incidents rare: once every few months, per engineer. When possible, non-critical issues are handled on the next work day.

Craftsmanship

Each of us strives to be the best in our field, and reach perfection, make the smartest best possible decisions, and create the best products possible.

Egolessness

Achieving a high level of craftsmanship requires complete egolessness; focusing on the search for the ‘truth’, and understanding that our own ideas might not always be the best ideas around. We should be open to quickly accepting any other, better idea, no matter who suggested it. This will also empower you to speak up when you’ve thought (deeply) of a better suggestion. 
Great craftsmanship focuses on creating best results, not whether it was our own idea.

Quality

We strive to produce great products. If we see a glitch, we don’t just refresh the browser’s display and wait to view the result – we dig in to find what happened, even if the problem seems to have disappeared.
We try to recreate the problem, digging deeper until we find its root cause. Problems don’t just go away – they come back, more severe, at the worst possible time. Finding and fixing problems early makes and keeps our products great.

Starting out at Bright Data, or in a new role at Bright Data

It is possible to add incremental value even on your first day at the job. We do this by focusing on a very specific task, not necessarily the most important one, and executing it from start to finish. When a manager joins the company, he is expected to first solve a major problem on his own, improving a meaningful KPI, before doing any type of “strategic thinking”, “team-building” or “process changing”.
From a Google VP on starting off on the right foot in a new role: “The advice I give to everybody coming in, is whatever your first project is, no matter how much you hate it, spend your first six months executing flawlessly on whatever you do. Don’t pontificate. Don’t go for the bigger thing. Don’t go for the grand, strategic objective. That stuff can wait six months. Jump in with both feet. Respect the fact that your team has been around forever and don’t question everything. Figure out how they operate. Treat them all with respect. Learn as much as you can and execute like crazy, and that will buy you the option value to do whatever you want next.
Because, if people see you execute one thing, they’ll think that you can execute another thing, and another thing, and another good thing. There are very few people who come in and do that truly professionally, but the people who do end up setting themselves up super well.”

Amazing Team

• The more top talent we have, the more we can accomplish.
• If the company is trying to solve the right set of problems, then it can create an environment that is challenging to top talent, and is able to provide these talents top of the market salaries and bonuses.
• We look for these top talents wherever they may be. We are not limited to geography, race, or religion. In fact, some of Bright Data’s top contributing employees today are based outside of our main office in Israel.
• We look for these top talents wherever in the world they may be.. In fact, some of Bright Data’s top contributing employees today are based outside of our main office in Israel.
• We look for people who:
  • Share much of our DNA, and are open to figuring it out and adopting it.
  • Accomplish amazing amounts of important work
  • Focus on great results that are important to Bright Data
  • Exhibit bias to action over analysis
  • Don’t wait to be told what to do
• A great workplace is only great if you are surrounded by great colleagues.

Effective and productive

Each of us chooses the tasks that bring the most value, and chooses the most productive way to get them done.
We measure the effectiveness of an action in whether it contributed to the company’s core – creating products that truly WOW our customers. We measure our productivity in how fast and often we are effective.

• Consider an employee who is proud of a report that he generated and distributed amongst 10 other employees. At Bright Data, we don’t consider this effective. The product did not change or improve – products are built from code, not spreadsheets, emails and presentations. It was even counter-productive: it is time that could be spent more productively not just by the employee, but by the 10 recipients.
• Consider an employee who saw their relative use a Bright Data product with difficulty, created a quick mockup by drawing it on paper, estimating that it would take less than an hour to implement, so they quickly implemented and deployed it, then checked with their relative whether it made it easier to use. Was that effective? Definitely yes!

Work is only effective if it directly changes how we make a better product or better processes to eventually improve the product more efficiently.

Productive

A good start to measuring our own productivity is whether we were able to complete tasks (big or small), deliver and deploy something every single day. Delivery and task completion are good signs for productivity.

Maximize impact

As technology workers, we have the opportunity to affect positive change at an unprecedented scale and rate. We have that opportunity because our individual work can positively impact millions of users within hours of being committed. At Bright Data we strive to make the most of that opportunity and you are integral to making that happen.

Bring value

Choose tasks that bring great value. Prioritize your tasks based on the value they bring.
If you think you have a task that will not improve the customer value of Bright Data’s products, do not prioritize it.

Capabilities

If a task does not match your capabilities, and someone else can do it faster, ask them to take ownership.

Sane work hours

We do not believe in ‘crazy startup work’ – while the difference between 10 to 11 hours per day is 10%, the job burnout caused by working that extra hour results in more than 10% ineffectiveness, and a single mistaken decision will lead to 100% ineffectiveness.
This policy is based on our very personal experience: in Jungo and the first year at Hola we believed that long work hours bring success.
After the first year, we decided to shake things up, for the better: No working at night or on weekends. Everybody needs to choose the number of hours they feel comfortable with, a number that matches their work-life balance requirements in order to enjoy life!
Don’t work crazy hours at Bright Data, but during the hours that you do work, work at 100% . Less hours, more focus.
We make HUGE efforts so that people do not have to work like in the startup world. We therefore expect that in the extremely rare occasions where working crazy hours is essential for solving an urgent customer problem, our employees take up the challenge and put in the necessary amount of work.
To summarize: We don’t measure people by how many hours they work – we do care about accomplishing great work.

Working environment

At Bright Data we make it possible to work from everywhere!
We have invested a lot of effort in creating the right productive environment, the right tools, and the required procedures, so that you would feel no difference whether you work from our headquarters, offices from home or a local Cafe. All you need is an Internet connection to allow you to connect to our Cloud Office.

Cost effective

When suggesting a change/improvement, look for the ‘total overall cost’. For example, consider our DB has performance problems, and a developer may suggest we move to a different DB engine to solve the performance issues. When suggesting the move to a new DB, due to the suggested DB’s ‘pros’, developers don’t always take into account all its ‘cons’. The old DB may have problems, but the new DB may also have a different set of its own issues. The old DB may also have features we rely on, which are unsupported by the new DB. At Bright Data, we always try to look at the big picture, and we prefer evolution where possible, instead of ‘out with the old, in with the new’; namely, evolution instead of revolution. Back to the DB example, many times a small configuration change, patch, or schema change can solve performance issues, being a quick cost-effective solution to the problem.

Do not suggest to change things that have negative ROI

It’s the responsibility of the developer who suggests the change to work out the ‘total overall cost’ of the change, and to validate that the suggestion has a large positive ROI, and that no simpler/quicker/cheaper/faster options can solve the issue at hand. We avoid implementing changes when the cost of the change is higher than the eventual positive outcome. It makes simple sense.

Short Simple Fast

Rules of thumb when evaluating any action/task/solution/code/document…:

• Short is better than Long
• Simple is better than Complex
• Fast is better than Slow

Minimalism

We love extreme minimalism.

• We implement only what is really needed
• Work with tools only if they really help
• Ask questions only if we are really stuck
• Write code only if it solves a real problem
• Solve a problem only if it brings value
• Avoid over-engineering

This minimalism is deeply embedded in our daily work, and DNA:

• Email: Minimal recipients, Minimal signature, Avoid unnecessary greetings, Single line emails where possible
• Code minimalism and condensity: removing every possible redundant token, spacing, comment, unless it’s really needed. Choosing short concise names. Always favoring shorter code.
• Minimal Viable Product: implement minimal features to create a viable product.
• Meet only if needed

Email

Email is a mission-critical tool for us – that’s why we prepared very detailed strict guidelines on how emails should be written, sent, received, and handled.
Here are some highlights from our Email guidelines:

• Eric Schmidt’s 9 rules for emailing: Respond quickly, minimal words, clear inbox constantly, handle LIFO order, share if useful, don’t BCC, BCC yourself for follow up, forward yourself with search keywords.
• Minimal recipients
• Clear subject
• Avoid greetings
• Minimal signature
• Single line emails where possible
• Make discussions actionable
• Clarify action items

Summarize important discussions

When action items come up in a discussion with someone, or very important information is conveyed – immediately after the discussion send a summary email to that person (or make sure they send it to you), so that:

• you can make sure that you both understood it in the same way, and;
• so that you have a reference for the future on what was agreed

The time it takes you to write this summary will allow you to consider which additional actions this requires, and who else needs to know about it.

Task organization

Don’t trust your memory. Carry a pad and write things down. Systematically go over your list – it’s very satisfying to cross things off your list! At the end of a meeting or skype call, send a short summary email with action items.

“By example” design

We use specific examples rather than formal specification to define tasks and design features: mockups, wireframes, and textual examples.

  definition: break is a color turning "darker". E.g. moving from green to orange is a break

  "break": green→yellow, yellow→orange, orange→red, etc...

  Add control with payment plan options: $5 a month, $25 for 6 months, $45 for 1 year. Also emphasize that the 1 year option saves 20%.

  Select payment plan
(o) $5  monthly
( ) $25 every 6 month
( ) $45 a year (save 20%!)

Autonomous and responsible

We love working with people who are able to manage their time and take care of themselves. We find that a management style where micro-management is required, tracking working hours and micro tasks kills our productivity and creativity.
So, the perfect Bright Data team member is the person who finds their own tasks by understanding their surroundings and deciding what would be of maximal value, creating an MVP, sharing that with their supervisor and OK’ing the direction, and then getting that done productively.
We find that this is more productive, and let’s face it, more enjoyable for all.

Responsible

Take responsibility and ownership for problems and aim to solve them on your own. Responsibility means that you are going ahead with a change and seeing it through, while identifying the risks and making sure that they are worth the outcome.

No need for others to fix

A great delivery is one that does not require anyone else to get involved in your tasks. You can do this!

Check your work

No one will check your work – so do it well

You review your own code

We do not do code reviews (… except for new people, and they must very quickly do perfect commits, so we can stop reviewing their work for them).

Workflow: Write, Test, Review, Commit, Build, Deploy, Monitor

The flow of adding a feature/modification/bugfix is:

• Write: fully implemented change consists of
  • code of the change itself
  • unit tests
  • deploy procedures
  • zcounters and alerts for monitoring
  Not every change requires every item from the list above, but it is the implementor’s responsibility to do as much as the change warrants.
• Test: emulate the product by using zlxc, and test your changes
• Review: do the following before commit:
  • Run zlint on your code
  • Run zmocha on your code
  • Read full diff of your changes
  • New Bright Data team member Ask for a review from a peer
• Commit: concisely describe “what” and “why” in the commit message, and commit.
• Build: if BAT breaks – revert your change or fix it immediately (within 5 min).
  You already wrote the unit-tests for BAT during the Write phase.
• Deploy: get your code to the field ASAP
  You have already updated procedures for the deploy team during the Write phase.
• Monitor: keep an eye on a monitoring system.
  You have already added zcounters and alerts during the Write phase.

Never ‘lose’ emails, tasks & AIs

We are each totally responsible for our own tasks, nobody will follow us up. So we can’t let tasks get ‘lost’. We don’t ‘forget’ things.
How? With tools:

• Manage your inbox: this prevents emails from getting lost – minimal inbox, and archive/delete emails only once handled.
• Use work_plan & calendar for long term AIs: these are ‘long term’ memory tools, so that tasks are never forgotten.
• Pen & paper in customer meetings: always having a pen & paper whenever meeting a customer on skype, video call or face to face, will prevent forgetting meeting AIs. Do this also when you come to get feedback or advice from a peer inside the company – you are using your peer’s time for your task, so don’t miss any of the things you learned by not writing them down. Transfer AIs you don’t immediately implement to your ‘long term memory’ tools (work plan, calendar…).

Trust judgment over rules

Rather than relying on hard rules that dictate behavior, we give ourselves the flexibility to apply judgment at the time a decision is being made. This allows us to incorporate more context about what is happening, enabled by the trust we share in the decision-making abilities of our teammates.

Truthful

Communicate, look at problems and evaluate ourselves truthfully
We seek truth: What does the user really want? What is the best way to solve a problem? How can we make our customers happy?
When facing these questions, we put workplace politics and personal egos aside, and focus on the search for the best, most truthful, and correct answers.
We believe that seeking the real truth will contribute to making better products and a better workplace.

Pride in mistakes

Everyone makes mistakes, especially people who get a lot done.
Therefore, we’re constantly on the lookout for our own mistakes. Once we detect and fix them, we are on a better trajectory, both personally and as a group. Finding our own mistakes is an “AHA!” moment. We take pride in it, and we share it – along with the new conclusion – with our peers, since some of them probably had the same, wrong assumptions.
We learn the most from the mistakes we make: Let’s share them so that we don’t make them again, but rather improve as a group. We can share our own mistakes by sending a case study to all relevant parties. If you make a mistake, don’t try to hide it. On the contrary, understand what happened, fix the mistake, as well as the flaws in the system that made the mistake possible. Mistakes are a great learning opportunity that allow for improvement! We’re only human after all – that’s how we learn.

Correcting mistakes

Making mistakes is part of fast-paced culture, and we all make them. If our goal was to be 100% mistake-free, we would be slowing our progress at Bright Data to a halt. Imagine a waiter who has to make sure 100% that he never breaks any dishes he carries. He will carry less dishes, and walk very slowly – not very productive! If he were to be only 99% break-free, breaking a dish once in a while, he would be 10x more productive: carrying more dishes, and walking much faster. We prefer to be the latter.
When identifying a mistake we need to apply some deep thinking to figure out other areas that this mistake may have affected. Back to the waiter example, once a glass breaks you need to consider what the implications are – where may have the glass shards ended up, do you need to put in an order for a new glass, is there more fall-out to consider? An example from our work; a Biz Dev (BD) person signs up a new customer, and in the internal email misspells the name of the customer. Not a problem, but requires some thinking now – what are the actions that need to be taken? Send a corrective email, go to the finance department and verify that the customer was not entered into the financial systems incorrectly (to avoid mismatches down the road), go to IT to make sure that the customer was not activated under the wrong name, etc. The next step after correcting the immediate results is finding how to improve the overall system, to prevent these mistakes from happening again. In the waiter’s example, after a few dishes dropped he offered to have a rubber mat on the tray to avoid much of the jiggle, resulting in less broken dishes and even faster possible walking speeds.

“5 Solutions”: Solve problems in 5 ways

Every problem or mistake that we investigate is a side effect of a bigger, deeper problem.
We avoid solving problems in advance, but once a problem does happen, we make sure to thoroughly solve it in 5 different ways, with 5 different solutions, thereby preventing the future occurrence of not only this specific type of problem, but also of many other, related problems.
This is originally based on Toyota’s Ask “Why?” 5 times, but adapted to our action-oriented DNA of ‘solving’ rather than ‘complaining’.
We have many systems and procedures in place to prevent mistakes and catch them once they occur – these were all built as solutions for past mistakes. If a bug/mistake slipped through all traps, the purpose of the ‘5 Solutions’ is to create new mechanisms and work methods that will prevent the future occurrence of such bugs.
Most ‘solutions’ we implement are ‘traps’ that help us trap/catch/prevent the bug/problem/mistake:

• linter: will trap bugs even before you first run the code
• unittest: will trap bugs before commit, or in the BAT
• test procedures: will trap problems before release, in the deploy stage
• zcounters: will trap after deploy, but will minimize the impact, by alerting – thus it will quickly be reverted.
• procedures: modifying a procedure in a way that will better trap new kinds of mistakes. Such as the developer workflow procedure that we modify constantly to help trap more and more different kinds of common mistakes.
  The email procedure was also written as a result of mistakes in email handling – thus helping the rest of the team avoid those mistakes.

5 sound like too many?
Too hard to find many ways to address the same problem?
The number 5 is not a strict rule. The quality of doing 5-Solutions is by the quality of the solutions and action items, not the number.
Even if you only have 2 solutions for the incident, but the solutions suggested and implemented give great value for the company – then 2 solutions is enough!
Here are questions that will help you find more root causes, and thus more possible solutions:

• Why didn’t the current procedures/work methods/tools prevent this problem?
• What procedure/tool should I modify to prevent this in the future?
• Do others also make this kind of mistake?
• How can I help my peers avoid it?
• Even if one trap didn’t catch this mistake, what additional traps could I add that would have caught it from a different direction?
• Even if all traps didn’t catch this bug, what post-release monitor/alerting trap can I add to detect the bug in the field, enabling early detection and minimizing the bug’s impact?
• Why did this happen again? Why wasn’t the previous fix thorough enough?
• Why do my peers tend to repeat this mistake?
• How can I teach my peers how to avoid this kind of mistake?
• Why did people not follow the existing procedures that prevent this mistake from happening?
• How to make it easier for others to avoid such mistakes?
• What tools are missing that would help find/solve/prevent this?

Initiate ‘5 Solutions’ process

Problems and mistakes can happen in your domain, for which you have to execute a ‘5 solutions’ process, immediately once found, to resolve them.
It is also quite often that a Veteran, who was an eyewitness to a problem or mistake in your domain, will ask you to consider initiating such a process. In such a case, our Bright Data way of thinking is also to investigate ourselves by asking ‘How come I did not see it before?’

Following an incident (e.g. network outage) your report should follow the Incident Report email format

‘5 Solutions’ timeline

Once initiating a ‘5 Solution’ process, it should end in a timely manner, so such a problem or mistake will not reoccur.
Your actions should be fast:

• Invest 10 minutes to understand what happened and provide an initial feedback to all concerned. Then,
• Invest 1-2 hours to deeply understand the problem, provide a solution and report to all concerned about your findings, solution and execution

‘5 Solutions’ example

‘cdn bytes’ metric did not notify a critical problem – here is a ‘5 Solutions’ process description:

  From: arik
To: niv
Subject: crit system did not work

Hi,

Yesterday Nir did a commit and didn't check it out.
No CRIT jumped and no one noticed till I saw it today (screenshot enclosed).

What was done on it?

Arik

  From: niv
To: arik
Subject: crit system did not work

Hi,

Sorry, my bad.

Niv

  From: niv
To: arik
Subject: crit system did not work

Hi,

Sorry, will not happen again.

Niv

  From: niv
To: arik
Subject: crit system did not work

Hi,

It is because of Yuval's code, talk with him.

Niv

  From: niv
To: arik
Subject: crit system did not work

Hi,

You are looking for who to blame. I worked and sometimes when you work, things are
broken.

Niv

  From: niv
To: arik
Subject: crit system did not work

Hi,

Here is my 5 solutions:

- Why the crit was not seen?

  cdn_bytes' crit_min and crit_max were not adjusted per customer traffic
  behavior but set globally.

  Solution: Will go over all cdn_bytes limits and set it according to
  their customer's traffic behavior.

- Do we have other metrics which are set the same?

  Yes! origin_downloaded_bytes, zone_init and many more.

  Solution: Will go over all other important metrics and set it according to
  their customer's traffic behavior.

- If this metric was set correctly, was it handled correctly by our critical
  procedures?

  No! Deploy would have avoided it since the website actually worked as
  expected.

  Solution: Add to the 'Handle' procedure instructions to check pattern and
  verify it looks the same.

I'm starting the cdn_bytes adjustments - I'll report once finished.
I'll come over to verify the list of important metrics to adjust as well.
'Handle' procedure will be adjusted by the end of the day.

Niv

| From: arik
| To: niv
| Subject: crit system did not work
|
| Hi,
|
| Yesterday Nir did a commit and didn't check it out.
| No CRIT jumped and no one noticed till I saw it today.
|
| What was done on it?
| Consider having 5 solutions on this incident.
|
| Arik

  From: niv
To: arik
Subject: crit system did not work

| - Why was the crit not seen?
|
|  cdn_bytes' crit_min and crit_max were not adjusted per customer traffic
|  behavior but set globally.
|
|  Solution: Will go over all cdn_bytes limits and set it according to
|  their customer's traffic behavior.

Done.
Continuing with the procedure.

  From: niv
To: arik
Subject: crit system did not work

| - If this metric was set correctly, was it handled correctly by our critical
|   procedures?
|
| No! Deploy would have avoided it since the website actually worked as
| expected.
|
| Solution: Add to the 'Handle' procedure instructions to check pattern and
| verify it looks the same.

Done.
Continuing with all other metrics.

  From: niv
To: arik
Subject: crit system did not work

Hi,

All other metrics were set.
Below is a link to my commit:
http://web.brightdata.com/cvs/zon/pkg/system/db/monitor_rules.js?r1=1.11&r2=1.12

Niv

This thorough handling of a problem will not only fix the specific problem that occurred, but will also prevent/fix many related future problems of various types.

Answering ‘why?’

Sometimes you will be asked to explain why you took a certain action. Such a process of answering ‘why?’ gives us an opportunity to either enhance our procedures, in case it was a good idea, or completely fix an identified problem, in case it was a mistake.
In case a mistake was identified, you will be asked not only to fix this specific one but also take all required actions preventing others from doing the same mistake again (e.g. executing 5 solutions report).
Check our email conventions to see how to answer a why email.

Clean up yourself

Sometimes our peers discover our mistakes. In such cases, we should be thankful for the time and effort they spent on finding mistakes. As part of a good peer relationship, and honoring our peer’s time, we try to acknowledge the mistake as quickly as possible and “clean up the mess” ourselves – releasing our peer from any further involvement:

• We immediately email: “Thanks. FIXED” if possible to fix immediately, or “Thanks. Will be fixed by tomorrow” if the fix takes time.
• We think whether this mistake might have been repeated by us or others in the codebase, and we rgrep and fix all mistakes of the same class as this one. In our email back to our peer we will add “I rgrep’ed and found mistakes of this type made by me in 5 other places, plus 20 more mistakes of this type made by others, and I FIXED them all”.
  This will put your peer’s mind at rest that you made a thorough fix, not a shallow one, thus preventing him from having to send you an email such as “OK – you fixed this specific bug occurrence, but did you check the whole codebase for additional appearances of such a bug?”
• Once the fix is deployed, send another email updating your peer that the fix is live, so that he now has a chance to see if the fix puts his mind at rest.
• Prepare by yourself, on your own initiative, a 5 solutions report. This gives your peer additional confidence that you carried out an extensive fix of the root cause of the mistake he found, and keeps his mind at rest.

It’s very common that when someone points out a mistake, the receiver tries to explain why the mistake was made, why it’s not such a big mistake, that such things happen and so on. At Bright Data, we acknowledge making a mistake, thank them for finding it, fix the mistake and move on to the next big thing!

‘bad news’? Learn from it!

There is no ‘bad news’. News makes us learn. Consider that if we’ve done good so far, and now we know something that we’re not doing well (such as a bug, or a mistake in our strategy), then once we fix that problem we are on an even better path. Don’t categorize news into ‘good news’ and ‘bad news’. It’s all good news, because we learn from it.
For example; a customer tells us they are switching from Bright Data to a competitor. Is that bad news? No – this is a great opportunity to learn about where our service is not good enough for this customer and to improve it. Consider that after this our service will be better – we will retain more customers, and sign up new customers at a faster pace! If we hide this important information, for example by saying:

  the customer is switching to another vendor for internal political reasons which we cannot influence

(for guys not in sales, this is a common excuse…), then we are losing important information that could allow us to learn and improve!

Trustworthiness

Every company says that trustworthiness is key in its employees. But why is it important to us?
Our basic premise is that we each work independently on our tasks, with P2P communications between us. There is no manager looking over your shoulder. Therefore, we have complete trust in all of the team members to be doing what’s right for the company, for carrying the company’s DNA into whatever task they have (remember that our success is a byproduct of our DNA), and for identifying mistakes and issues and fixing them at a DNA level.
Let’s take that example of the salesperson who lost a customer. If that salesperson is untrustworthy and wants to look good by stating that he lost the customer due to “Internal customer politics”, then they set the whole company back by hiding important information, thereby preventing us from producing the best possible product. Let’s also take a look at what will happen when another person from Bright Data revisits that customer and finds out the real reason why the customer left us. It will reflect on our communication, which from that point will be more cautious and less trusting. This goes against everything the DNA stands for.
There are second level aspects of trustworthiness and truthfulness that are not as apparent: read about them in the next sections on Debating and mind change.

Debating

It’s human nature to try to convince others that your position is the right one. However, in a productive environment you need to ensure that you are not ‘overselling’ your solution and in the process are ‘hiding’ some of its pitfalls and some of the merits of the alternative. In our environment, presenting a view that is not neutral (for example, by not showing the real downsides of your proposed solution) will typically not convince your peers of your solution. It’s more important to focus on the cons of your own suggestions and the pros of your peer’s suggestions, to make your suggestion more credible: A good scientific theory is one that suggests an experiment to disprove the theory.
At Bright Data, finding out the true reason for something, and fixing it, will result in success as a “side effect”. Therefore, when debating an issue, show the arguments for both sides, as well as your conclusion. Your peer in the debate may show more arguments for the other side and eventually cause you to tilt back to the other position. Tilt to that other position with pride! There’s no shame in this game!

Proud of changing our mind

Litany of Tarski:

  If the sky is blue - I desire to believe that the sky is blue
If the sky is not blue - I desire to believe that the sky is not blue.

What seemed correct yesterday may not seem correct today. We commit to tracking the truth, changing as new data becomes available. This way progress is not stifled by yesterday’s ‘truth’. We try to have a strong opinion, but are always ready to switch it fast when we have new data, taking pride in changing our mind. This is the essence of innovation and radical transparency!

In a super-fast work environment, we learn new things frequently, and must therefore adapt our opinions accordingly, fully aware that evolution brings success.

Choose to bring value to our customers

There are various ways for a company to succeed, for example: by doing great marketing for mediocre products.
We choose to succeed by creating products that bring significant value to our customers (typically through technological disruptions). When considering our roadmap, we choose to do things that make our products bring higher value to the customer, rather than things that provide us shorter-term profit. Why? Because that’s how we can succeed inover the long term – by having products that are difficult to compete with, and customers who trust us. We are marathon runners, not sprinters.
Discussions around product features should be about the value they bring to the customer, not the value they bring to Bright Data.

  Let's provide our customers with a bandwidth saving feature. They'll love it because it saves them money on their monthly CDN bill.

  Let's not do this bandwidth saving feature. Our competitors don't have it, and it will cause our customers to stream less and us to make less revenues.