Bright Data's mission is to bring back transparency to the internet by turning unstructured data (web page) into structured data (table). Bright Data is the key gateway for businesses to access web data (e.g. 'what is the price of earbuds in all North America stores, in CSV, every hour').
Why do we need a DNA?
To have a joint set of guiding values in the decisions each of us makes daily.
As individuals, the DNA lets us make decisions fast, without hesitation or approval.
As an organization, the DNA keeps us learning as a body by defining and improving what we know.
How do we keep our DNA alive?
By constantly trying to align our daily actions to match the DNA.
By helping others to work by the DNA.
By teaching it to Bright Data newbies.
How do we change our DNA?
Suggest changes to firstname.lastname@example.org.
Make your contribution to the creation and evolution of our Bright Data DNA.
That's how we improve!
Our success will be a byproduct of our DNA.
Continuously learning and evolving
Creating great products that will impact every person in the world is an immense task. Succeeding requires a culture of professionalism, consistency, learning and rapid change. We imitate this culture from nature -- 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.
The DNA is our shared memory of how to do things right, so work according to that DNA. If you find a way to improve on our DNA, share that with email@example.com and influence change in our DNA.
We are highly pedantic in keeping our codebase perfectly consistent with our coding conventions. When none exist, or the specific case is not covered, we use the existing current codebase style as a guide.
Email consistency, just like source code consistency, helps handle large amounts of email efficiently in our team.
That's why we keep our email styling consistent with our email style guide, and look out for unwritten conventions in the way Veterans communicate in the company, and follow their style.
When we do something new, or something un-documented, we improve our consistency by creating a procedure. This documents the task we are doing, to ensure better consistency next time this task is carried out.
When we do a task which is not standardized, we find out how it was done previously by others. We also provide you with general knowledge you need to have while doing specific roles in Bright Data. If more information is needed, ask Google.
If you are doing a task which is not standardized, look how it was done before.
Not all aspects of tasks you do have a written standard or procedure. So how do you learn how to do them? By seeing how it was done previously by others, and learning from them.
Imitation is a very powerful learning tool. Look at the highly productive veterans in the company, and try to imitate their working habits, large and small.
If you choose to imitate the veterans who better fit your character and style of work, you will quickly improve your efficiency and productivity.
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 our DNA, teach others about the DNA, and help new employees get to know the DNA.
Old features keep us behind. 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 bring us value, obsolete documents etc. - remove them! Removing obsolete procedures/code/features greatly simplifies our product and daily work, makes it easier to change things going forward, makes us leaner and more 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.
If 'future use' code is still unused, with no signs of anyone working on it for the past two weeks, why is it still 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.
Our users and customers are the reason for our existence. We try to constantly understand their needs, find out their pain points and solve them. We constantly evolve, improving our services, features, and products - we do everything we can to bring them significant value as they are our most valuable asset. We should aim to be liked by our users by doing things which are net-benefit for them. When evaluating our business decisions, we ask ourselves 'would consumers like us more if they knew we made this decision?'.
Why it is essential to put customers first
We strive to be unswervingly self-aware, which facilitates being intentional about how we act, what we do, and how to constantly improve.
Our behavior and actions should have a cause. A reason. Well-thought from beginning on the full flow and the end result.
Having a well thought-of reason in advance helps us make our actions more consistent, and if the action is later found out to be incorrect, allows us to find the root-cause in the mistaken reasoning that was used and improve the reasoning for in future actions.
Mindless actions do not allow improvement in the future, because they were not derived from a systematic well-thought of reasoning: if they had a positive outcome - we cannot repeat them, if they had a negative outcome - we cannot avoid them repeating.
Even hacks should be well thought of in advance. Especially hacks!
Hacks are a very powerful tool of quickly solving real problems, and implementing real features with great value, in a short time. But in return, they require you to think it out well through in advance, to make sure the hack is worthwhile, and is not going to cause more damage than its value.
We're a team - like a pro sports team, not a kid's recreational team, not a family. Bright Data hires and develops smartly, so we have stars in every position.
We look for people who share similar values to ours: They are pros, ambitious, they love to get stuff done, love to learn and love working with similar such people. They are also smart, and masters of their domain. 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 a candidate that shows traits of being a star. If we are not 100% sure that they are a perfect DNA fit, we let that person know of our concerns, and we go ahead and hire for the bootcamp to give that person a chance to learn the company DNA and become a productive member of the team. The first weeks of our work together serve as a mutual get to know period.
At your first 3 weeks at Bright Data you are a temp employee for a period of mutual 'get to know', with the intention of making the transition into a full hire during that time.
We rarely let people go after the initial temp period, because by then the person has shown great capabilities and ability to let them flourish at Bright Data through the DNA.
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.
Congratulations on being selected to join the team! Professionals like you are rare, and are what excites the rest of the team here. We are looking forward to you becoming an integral part of our professional team. The 3 week Bright Data bootcamp is your first step from candidate to Bright Data Noob, 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 in the first day, 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 things to review prior to bootcamp, including: information about the company, products, DNA, coding conventions, basic tools and methods of work, and access to your mentor for any questions you may have in advance.
Congratulations on successfully completing the bootcamp! You are now on your journey from Bright Data Noob to Bright Data Veteran. The goal of this process is for you to evolve from someone who can be part of the pro team, to someone who is an integral part of the team. Here's the process you'll be going through:
Bright Data Veterans are the core of the team. You will make immense 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.
Bright Data developer Veterans are typically not let go from Bright Data.
We communicate openly, clearly, truthfully and with precision
Open knowledge facilitates free information exchange, allowing us to learn from each other and make smarter decisions. We share all information within our team, as well as in our ecosystem (customers, partners, market) - unless there is a compelling reason not to.
Try to avoid adding BCC (blind copy) recipients - it is usually a sign of non-transparency.
We each provide clear information on areas of responsibility and expertise, our current tasks and activities. We do so, to allow anyone to get the full 'raw data' and to be able to question our decisions and actions in our area.
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 which were migrated already to Windows 10? A: Sure. I have the list on my laptop, I can show you.
Q: Do you have the list of people which were migrated already to Windows 10? 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 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.
Information is open to everyone at Bright Data. This transparency is provided to allow you to get your work done without requiring permissions, which slow you down. However, accessing information which 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 additional consequences.
It's important for us to communicate clearly, delivering direct feedback. Critiques allow for self-improvement. Political correctness prohibits conveying messages successfully.
We provide direct feedback. People who are not accustomed to it, may consider it blunt and possibly even hurtful. Remember that this is not a reflection on your abilities but on the 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 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.
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.
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 exact in your communication; avoid vagueness and jargon. If you are too generic, you leave too much space to ambiguity; specific communication ensures messages are conveyed correctly and expectations are met. High level terminology or jargon, moreover, are often used as an excuse not to make an all-out effort for handling a difficult issue.
We communicate precisely, with specific details:
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 and 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 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'll be happy to hear more about the things you have written.
At Bright Data, the email we would send would be:
Please share with me the unique visitor data for October/15 which led you to this conclusion. I'd like to publish that data in our next blog.
This email is more precise and specific, resulting in better communication.
Explain your idea accurately and get to the point; your messages should be supported by good reasoning.
In God We Trust. All others bring Data
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 Toyota Production System.
We try to make mindful rational decisions, based on real world data, facts and use cases.
Providing concrete data will give your colleagues a firm basis for either agreeing or disagreeing with your idea. This scientific scrutiny approach improves the quality and assurance in your ideas and suggestions, once they passed the healthy questioning.
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.
Stand up for your beliefs: dispute tasks that you believe are wrong or can be improved, even if its from the CEO!
But, this should not come at the expense of getting things done (GTD).
How to dispute while staying productive:
We do things immediately, so that we can evolve and improve faster
A startup's engine for creating better products is a constant Learn-Build-Measure loop. It's unlikely to succeed on the first try; so we iterate on the product until it's fit. The more responsive we are, the faster our products will evolve and improve.
We do quick tasks immediately, even when they're not particularly important, to avoid the overhead of prioritizing and of reopening their context.
Quick tasks are not worth delegating. The communication and management involved in the delegation process takes more effort than the task itself.
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.
Note: this doesn't strictly apply to managers, since delegating efficiently is part of their role
We discard promptly 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.
Email responsiveness and never losing an email (forgetting to respond) is critical for efficient and reliable email communication with our peers. So we strictly follow the email handling guidelines, that include rules such as:
What's a small task and what's not?
When to act immediately and when to postpone?
The timetable below can help you determine your actions according to the task you are handling:
|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 immediate partial solution/responses.|
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 immediate partial solution/responses.|
Log it in your work plan and update the requester on when you plan to implement it.
Mark it in your calendar, and update again the requester if you decide to delay once more.
It's OK to change a schedule if other tasks come up or take longer than expected, but we update the requester with the new schedule.
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.
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.
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 you do not know how a product works for customers, until they've been using it. The biggest waste of our time has been when we put major efforts on a tangent, only to find the whole direction was wrong for a reason we could have detected earlier. We learned that you should release very early, and make incremental improvements.
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 are to design the smallest conceivable delivery, that brings some initial value. Design it, release it quickly (hours?) and then iterate on improving it.
Fast evolution requires rapid experimentation.
We love experimenting with new ideas/features/technologies/solutions. We measure the experiment 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.
Fast feedback loop reduces the time it takes to build a feature as originally intended, by getting the feedback on a wrong direction early on, before completing the whole feature.
All examples cited above minimize iteration time and bring value almost immediately.
"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 learning which additional improvement iterations 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. Sign at Facebook
We take pride in our work, and invest time to produce 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.
Moving fast ultimately will be why we succeed.
Yes - we break things while moving fast, but we fix it even faster! (Sign on Facebook walls).
Listen to an interview with Mark Zuckerberg, Founder & CEO of Facebook, talking about moving fast and break things.
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.
Do only a little better every day, and you are 37x better by the end of the year.
When starting a new task, we break it down to smaller tasks that can be released on their own, and can bring value on their own. 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 want 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 work in progress...
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 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 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 parital 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 progres.
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.
At Bright Data we deliberately avoid branches as a means of 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. You will not manage. 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:
We choose to solve a problem over stating that one exists. Prefer actions over words
We can only bring more value to our customers and to each other through actions. Offering new, well thought-out ideas is great, but must be followed with an action plan of how you get it done, so that your ideas turn into products.
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.
Problems are everywhere. Anything we see is something that can be improved. Every product has an endless number of bugs and points to improve. Many things need to be changed. Just stating that a problem exists does not bring value -- solving the problem does!
Translate issues/opinions/suggestions/problems into actionable solutions.
I think those guys are doing a great job on their onboarding
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.
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 did not yet happen. Our experience showed us that any work we spent on theoretical issues always turned up in the end to be a waste of time. Actions based on future theoretical issues are called at Bright Data 'over engineering'. By handling only today's problems, we place our trust in evolution to guide us to a successful future.
Researching and learning in Bright Data is always carried out by action, by doing, by implementing, by delivery.
We research via real life experimentation, and by incremental steps to see if the direction of our solution is correct. We don't just sit, think, and fill our heads with thoughts for a month. Instead, 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.
If you encounter a problem, do not suggest how to solve it - solve it!
You have resolved a problem or finished a task - great work and well done!
However, it is not DONE until you have communicated with your customer directly, and received his 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.
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 after lunch. Other than that, we don't have meetings. We believe that while sometimes they may be productive, they are typically a waste of time for most of the participants and above 2 participants ego overcomes logic. We prefer to 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: the owner of creating a comprehensive solution creates on his own what he finds to be the best overall solution. Then he incrementally iterates on it with each stakeholder separately, considering the new feedback received each time to make a better and better plan.
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... We don't have a meeting room. Avoid meetings - just talk to whoever you need ad-hoc, over lunch etc. And never set recurring meetings.
After discussion summarize to your peer the main points you had, which next actions needs to be taken, and who is responsible for each action. Actions should be recorded in work plan to make sure nothing is forgotten. See GTD.
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 cause it. Do you know of any such change? In any case, I will take charge of fixing this issue.
Those who complete tasks on their own from start to finish create the largest impact
The people with the largest impact are those who do 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.
Bright Data is the sum of its employees. Each person brings a real tangible self contribution to the final product.
Something you can point out proudly to your mother and say "I did that!".
Bright Data is a P2P company. But not only our products are P2P, so is also our daily work method: people in the company work directly with their peers. We do not pass things 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.
No managers needed!
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 it from start to end on your own, pass it on in its entirety to someone who can.
We avoid passing on subtasks - namely, smaller parts of a bigger task - to others: it's unfair to your peers and the overhead of context switch within the company makes it inefficient:
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:
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.
It's easy to feel like you deserve the time of your coworkers.
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. But every interaction comes with 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 his kids, or otherwise enjoying his non-work life.
Consider keeping a list of issues you'd like to discuss, and lumping them into one discussion 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.
We avoid asking our peers questions we can ask Google: Let me google 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 - don't ask!
We optimize emails we write for making them simple to understand and act on for the other side. We take time to write the email carefully and review and modify 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.
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.
Implementing a new feature? Trying to fix a bug? Modifying code? Improving the installation flow? Suggesting to add a new tool? Whatever you do, just make sure you do not degrade the existing situation.
A great company is combined 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 in the course of their own work.
You should bring value to Bright Data - at the very least, do no harm:
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 peer's time by asking for help, you prevented your peers from progressing in their own features.
Our peer's time is always more valuable than our own.
Revolutions aren't won by paid soldiers; they're won by true believers in the cause, patriots. A home owner treats his house better than a home renter. Whereas renters are mercenaries, focused on short-term personal gain not deeply vested into that the house (next year they will be renting a different house), owners optimize for long-term outcomes, bridge gaps in organizations, think and act beyond their job description. They care deeply about their home - their workplace. In Bright Data, we are all owners and not renters.
Introduced any new feature or application? Take full ownership of it by adding yourself to the
jdoc, and by monitoring and influencing its progress.
Complaints are words. Solutions are actions. Only actions make a change.
Take ownership of problems, don't hope someone else will solve them for you.
If you need to instruct the sales team how to sell the product, first sell it yourself. By doing a task first yourself 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 with Brian Chesky, Co-founder & CEO of Airbnb, speaking on doing tasks yourslef.
Hire 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 himself), getting interest from publishers (by contacting them himself), 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 are the exact requirements of the person to be hired.
Bright Data is a global company that provides mission-critical services for countless customers and users. As a result, we must ensure a very high level of reliability. Each engineer shares responsibility for keeping our services running smoothly 24/7/365.
Once a problem occurs, each team of experts (a team for each product or service) is assigned to provide the best and quickest resolution. After you become familiar with the Bright Data infrastructure, you will be part of such a team.
We strive to make on-call incidents rare: once every few months, per team. When possible, non-critical issues are handled on the next work day.
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.
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 accept quickly any other, better idea, no matter who suggested it.
Great craftsmanship focuses on creating best results, not whether it was our own idea.
We strive to produce great products. If we see a glitch, we don't just refresh the browser's display and sit, self-content, to view the result - we dig in to find what happened, even if the problem seems to have disappeared.
We try to re-create the problem, digging deeper until we find the root cause. Problems don't just go away - they come back, more severe, at the worst possible time. Finding and fixing problems early makes our products great.
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."
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 WOW our customers. We measure our productivity in how fast and often we can be effective.
Work is only effective if it directly changed how we make a better product.
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.
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 impact millions of users within hours of being committed. At Bright Data we strive to make the most of that opportunity.
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 do this task.
If a task does not match your capabilities, and someone else can do it faster, try to have him take ownership.
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 this 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 in Hola we believed that long work hours bring success.
After the first year in Hola, we decided we are completely different: No working at night, no working on weekends, everybody needs to choose a personally defined number of hours he feels comfortable with, a number that matches his perception about the work-life balance required in order to enjoy life!
Don't work crazy hours at Bright Data, but during the hours that you do work, work with 100% focus and dedication. Less hours, more focus.
We make HUGE efforts so that people do not have to work like in startup world. We therefore expect that in the very very rare occasions where working crazy hours is essential for solving an urgent customer problem, our employees take up the challenge and put 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.
At Bright Data we managed to make it possible to work from everywhere!
We have invested a lot of efforts in creating the right productive environment, the right tools, and the required procedures, so that you would feel no difference if you work from our headquarters, offices, from home, or from a local Cafe. All you need is an Internet connection, to allow you to connect to our Cloud Office.
When suggesting a change/improvement, look for the 'total overall cost'. For example, consider our DB has performance problems, and a developer may suggest to move to a different DB engine to solve the performance issues. When suggesting to 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.
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.
Rule of thumb when evaluating any action/task/solution/code/document...:
We love extreme minimalism.
This minimalism is deeply embedded in our daily work, and DNA:
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:
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 he sends to you), so that:
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.
Don't trust your memory. Carry a pad and write things down. Systematically go over your list - you will see it's very satisfying to cross things off that list. At the end of a meeting or skype call, send a short summary email with action items.
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%!)
We love working with people who can manage themselves and their tasks on their own. We find that a management style where micro-management is required, guiding the individual contributor in many steps of the way and tracking working hours and micro tasks kills our productivity and our creativeness.
Thus, the perfect Bright Data'er is the person who finds his own tasks by understanding his surroundings and deciding what would be of maximal value, creating an MVP, sharing that with his supervisor and OK'ing the direction, and then getting that done productively.
We find that this is more productive, and more enjoyable for all.
Take responsibility and ownership for the problems and solve them on your own. Responsibility means that you are going ahead with a change and seeing it through, while understanding the risks and making sure that they are worth the outcome.
A great delivery is one that does not require anyone else to get involved in your tasks.
No one will check your work - so do it well first time
We do not do code reviews (... except for new people, and they must very quickly do perfect commits, so we can stop doing their reviews).
The flow of adding a feature/modification/bugfix is:
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:
Rather than rely 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.
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 make better products and a better workplace.
Everyone makes mistakes, especially people who get a lot done.
Therefore, we're constantly on the look for our own mistakes. Once we detect and fix them, we are on a better trajectory, 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 are probably in the same, wrong mindset in which we were before.
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 that are relevant. 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 allows for improvement.
Making mistakes is part of the culture of running fast, 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 of the second sort.
When identifying that a mistake has been made 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 consequences are - where may have the glass shreds ended up, do you need to put in an order for a new glass, are there other repercussions?
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 done? Send a corrective email, go to finance department and ensure that the customer was not entered in 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 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.
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 in place many systems and procedures to prevent mistakes and to catch them once they happen - 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:
5 sounds 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:
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 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
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:
'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 who to blame. I worked and sometime 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 have 5 solutions on this incident. | | Arik
From: niv To: arik Subject: crit system did not work | - 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. 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.
Sometimes you will be asked to explain why did you take a certain action. Such a process of answering 'why?' gives us an opportunity to either enhance our procedures, in case it was good idea, or completely fix an identified problem, in case it was a mistake.
In case a mistake was identified, you wil be asked not only to fix this specific one but also taking 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.
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 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:
It's very common that when someone points out a mistake, the receiver tries to explain why the mistake was done, why it's not such a big mistake, that such things happen and so on. However, at Bright Data we thrive on running fast and recognize that mistakes happen, so responses of this type become irrelevant and a sheer waste of time. We acknowledge making a mistake, thank him for finding it, fix the mistake and move on to the next big thing!
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 he is 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 hid 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!
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 the shoulder (and if there is, then something is not working right). Therefore, we have complete trust in all of us to be doing what's right for the company, for carrying the company's DNA into whatever task we 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 he sets 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 is intolerable from a DNA perspective.
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.
It's human nature to try to convince 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 you 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!
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.
In a super-fast work environment, we learn new things frequently, and must therefore adapt our opinions accordingly, fully aware that evolution brings success.
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 great 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 bring us shorter-term profit. Why? Because that's how we can succeed over 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.