DataRobot Machines: How We Scale The Company With Automation and Data
No matter what work you do, at a high level you are simply setting goals and building machines to help you achieve them.
— Ray Dalio, Principles
When I was 6 a programmer friend of my dad’s did something that made a lifetime impression on me. He spent five minutes typing on our ZX Spectrum, then sat back and invited me to the screen with the program on it. It displayed two random numbers, asked me to multiply them, and revealed whether my answer was correct. I was fascinated by the idea of creating something that works on its own and is apparently smarter than me.
When later in life I became a programmer, my favorite type of software were systems that performed complex tasks without anyone’s control: game bots, crawlers, expert systems. When I started leading teams, my goal was to make them perform well without me.
Eventually, I combined the two. Machines at DataRobot are a mix of autonomous software systems and self-managing teams. The article below describes how they work.
Machines became very widespread during the Industrial Revolution. Powerful mechanisms made physical work much more effective, enabling sustainable economy growth and dramatic increases in living standards for the first time in the human history.
The word “machine” is primarily associated with a device converting energy into physical work. Though if you look at the origin (μηχανή), it is less specific: “any artificial means or contrivance for doing a thing”. This definition is closer to what I mean by “machine”.
“Doing a thing” is not limited to physical work anymore. Recent advancements in IT infrastructure, software engineering, and AI finally allow us to build effective machines for intellectual work. Companies in all industries need to adapt or ultimately will fail.
DataRobot is a typical B2B software company from the outside. We have R&D, marketing, sales, customer success, HR, and other departments. Inside, we look at each of these functions as machines. We deliberately architect, engineer, measure, and evolve the way our company operates.
This approach serves three main purposes:
- Continuously improve operations in a systematic way.
- Scale the company exponentially without adding management overhead.
- Utilize automation and machine learning to increase effectiveness and performance.
It started as an experiment in a few parts of the company. The approach worked very well and became one of the company’s work principles.
This article describes the framework for building machines developed over the last two years. Hopefully, the lessons we learned will help you build a better company.
Operators and Engineers
In 2018, most people drive cars built by somebody else. Building a car is widely considered to be a complicated task requiring a specialist.
If you look at your company as a machine, it is clearly more complex than an average car.
Building a machine requires different talents and skills than operating it. Nevertheless, most companies expected people to build machines they operate. When a new executive is appointed, they are tasked with establishing business processes using experience, best practices, and tools available on the market. No wonder their machines end up looking like this:
In DataRobot, we have a dedicated team to help build machines across the company. We call it “Machine Engineering”, a weird-sounding name if you do not know the context. Unlike conventional approaches for improving company processes (re-engineering, business process management), ours is driven by engineers, not “business people”. In fact, we treat this a lot like building software products. The main roles on the team are:
- Machine Architect, a role similar to the Product Owner in software development. They are responsible for collecting ideas, requirements, constraints, and other relevant information. Architect creates a consistent vision of the machine and its future iterations.
- Software Engineer responsible for implementing the technical part of a machine. Usually, it is a full-stack engineer who can own UI, server-side code, deploy, and troubleshoot an application.
- Data Analyst responsible for collecting and analyzing data to identify areas of improvement.
The Machine Engineering team works closely with people who run machines whom we call Operators. Machine Engineering talk with Operators multiple times per week. This ensures alignment and fast iterations.
For multiple people to build and improve a machine together, they need to have a shared understanding of how it works. All the key components need to be described explicitly and in detail.
Successful design starts with splitting the job into smaller parts.
Deconstructing Jobs
Most jobs involve performing a limited set of operations repeatedly. Therefore, a complex job can be described as a sequence of simpler tasks and decisions. Deconstructing a job enables shared understanding of how the job is done and ability to improve the process.
We start by asking people who know the job well:
- Where does your work come from? How is it represented? Where is it stored?
It could be an incoming email, a project specification, a ticket in a service desk, etc. - What happens with each type of incoming work? What tasks do you perform? What decisions do you make?
- What are the outputs of your work? When is the work “done” or passed over to another machine?
The result can be represented as a flowchart that consists of inputs, actions, decisions, and outputs.
Even if you not into building machines, deconstructing jobs is useful in many ways:
- Having a detailed description of a job is great for training new hires.
- When looking at the flowchart, you may notice opportunities for improvement.
- You may discover that people do the job differently and combine their approaches into a better one.
When you described what a machine does and how, you want your plan to become a reality. In DataRobot we want every more: a job should be done without a manager who tells other people what to do. We need right things to “just happen”.
Establishing Organizational Habits
For something to happen without conscious control, you need a habit. According to the science of how habits work, it requires three components:
- An event or a condition triggering the habit.
- A clearly defined workflow.
- A feedback loop that rewards well-performed workflow and/or punishes bad execution.
You need all three elements to work well in order for habit to persevere.
Trigger
A simplest trigger is an email or a Slack message sent at the right time. If you have reliable calendars, a calendar event could be a trigger too.
Another way of setting up a trigger is making it a part of an existing habit. For example, if you have a weekly meeting with an agenda you follow, adding an item to the agenda could be a trigger for a new habit.
Workflow
A workflow is just a list of steps. In complex cases, it could be a flowchart. It is a good investment of your time to describe a workflow in detail. You will save it many times over when on-boarding new teammates and by preventing errors caused by forgetting steps.
Additionally, you will go back to the description when looking for ways to improve the workflow.
Feedback
This is usually the hardest part of establishing a habit.
If you are lucky, the person who does the job is interested in doing it well. In that case, a simple dashboard showing performance indicators is enough.
If you cannot rely on self-management, you need to answer two questions:
- Who is interested in the workflow being executed consistently and with high quality?
- What influence do they have on the person doing the job?
You need to show the results of the workflow (or lack thereof) to the interested parties and make it trivial for them to provide feedback.
90% to 100%
We rely on existing tools and applications when developing organizational habits. It saves us tons of time compared to writing our own software. In most cases, existing tools get us 90% of what we need. This means we have to implement the remaining 10%: missing notifications, automation, data transfer.
Two rules come out of this idea:
- You need software engineers to build machines (did I say that before?).
- Good API should be a hard requirement for tools you want to use.
Evolving Machines
The world changes, the company grows, and what worked before does not work anymore. Even if you built a perfect machine, it needs to evolve to adapt to the changing environment.
Every machine should have routines dedicated to learning and improving. Many of our machines have weekly retrospective meeting supported by a dashboard with performance indicators. Each week we look at a dashboard, identify what prevents the machine from being more productive, and come up with changes to implement.
Usually, we have multiple levels of retrospectives: weekly, monthly, quarterly, yearly. Each of them uses a different set of performance indicators that allow reviewing a machine on different levels.
Over the last couple of years, we discovered common approaches for improving machines that work across many functional areas, but it is a topic for another article.
How to Start
Now, when you are convinced that building machines is the right thing to do, where do you start? Here is the plan:
- Find an Operator and an engineer who can play a role of the Machine Architect. An Operator is a domain expert who knows how the job is done. An Architect will help the Operator build a machine that works. They could be the same person, but rarely.
- Deconstruct the job. Spend a few a few hours near a whiteboard to describe how the machine works. Identify inputs, outputs, and workflows in between.
- Establish habits for the workflows you identified. Implement triggers and feedback loops to make sure they “just work”.
- Start measuring performance indicators. You will need objective measures to systematically evolve your machine.
- Schedule retrospectives. Start with weekly and quarterly, then see if you need more. Feedback is critical to improving the process and building a better machine and ultimately a successful company.
This is just an overview of what we have learned in the last two years of building machines at DataRobot. Do you want to know more? Subscribe to this blog and leave comments to tell what should I describe in more detail.
