Resist Folklore
published 2024-02-08 18:42:00 -0500
Considerations When Porting Prior Company Processes and Practices
We used to have a company value at DataRobot titled “Resist Folklore”. The intent was to make sure we were creating the best possible DataRobot, and not just bringing in what we used to do from our prior jobs. It’s a good challenge, as most of us have worked somewhere before and we have either developed or been engaged with processes and practices which we believe were good for the success of our team and/or company. And yet, everything occurs within a context, and as such simply saying “We always did X over at Company Z” doesn’t contribute directly to the success of the practices or processes within your new environment. On the other hand, we cannot have a static environment inside the company which is so special it cannot grow and change with the experiences of others. This is a condition called “terminal uniqueness”; from which we will die. We must challenge the status quo from time to time. People who are new to the organization tend to be an excellent source of these challenges. How can we successfully incorporate change into a new company while taking the proper context into account?
Encouraging Change
Recipients of new ideas must help foster those ideas, or the benefits from change will be curtailed before they can be properly evaluated. Maintainers of the status quo should consider the following:
Ask for improvement ideas regularly. Especially from people in the company less than 6 months. In fact, encourage ideas for change from everyone, including yourself. Everything starts to look normal to someone who has been doing it for years; if a new person says something seems off/weird/crazy to them - investigate. If you have been there for years, but have always hated some process or practice - why are we still doing it?
Be ready to act. It’s too often the case that the work involved in change (which we can artificially inflate) causes us to respond to change ideas with slow skepticism. We condemn new ideas “to committee”, so that we don’t have to deal with them right now. This is a mistake - if the problem is real, then finding the solution is worthwhile.
- Be curious about the problem statement - help anyone with an idea to articulate what is broken or insufficient.
- Help with the evaluation of the current state when new ideas are presented. Watch out for areas where it is hard for you to explain why something is being done. Good evaluation questions include:
- Who still cares about the process or practice?
- Who receives the outputs/benefits from it?
- What would break if it were changed?
- Who do we need to talk to about a change?
Evaluating Your Prior Company Experience
Processes are usually not static even within the company which invented or implemented them, but our memory of how the process worked at a prior company is static. What is more, the environment which made the process useful before may be dependent on context which doesn’t exist in the target company. Every process or practice (whether developed internally or ported) would benefit from answering some of the following questions:
- What is the specific statement of the problem to solve?
- What outcome will be achieved by adhering to or adopting the new process/practice?
- Is there anything currently in place which is supposed to solve this problem? What are the issues with it? Why is it failing/not successful?
- Do we want to replace it or improve it?
- Has anything been tried in the past? Why did it fail, and what has changed? Consider mixes of different processes and practices which may be in place, not only those wholly targeted at the problem space.
- What additional aspects of the system contributed to the success of the practice/process at the prior company?
- Was a budget required?
- Which roles were responsible for implementing/maintaining it?
- How many people were available for each role relative to the people engaged by it, or outcomes from it?
- What software systems were in place to support the practice?
- How were people motivated to participate? Was it tied into compensation, etc?
- Were there upstream and/or downstream processes which provided inputs, or made use of the outputs of this process? If so, those also need to be evaluated.
- Is the process or practice culturally relevant in the target company or team? Is it opposed to any stated or unstated values? Typically around expectations on people’s time, or scope; transparency expectations; review systems, etc.
Organizational Change
If everyone agrees there is something to change, it’s typically going to take more than just saying so in order for an organization to actually change. Even surprisingly small changes require support; adding a new section to a document template could fail simply because people weren’t educated on the value it would provice them. Let’s consider how to move an organization: Did you really reach agreement on the need for change? On average, no one likes change. It’s important to get buy-in, or natural defense mechanisms will bog you down at the start. This doesn’t mean you have to end at a place where everyone is consulted, or even happy. That will also kill change. It does mean that you’ve figured out who must agree, who should be consulted, etc.
Who agreed with you?
- Do they (individually or group) have the right to change it?
- Are they responsible for the implementation?
- Will they help you enforce it?
- Is everyone ready to pay for it (with time, resources, budget)?
- Do you need / have an executive mandate?
How Will You Get Alignment?
- What incentive do people have to switch to a new way of working?
- What support is required to make the change? Systems support to provide structure such as workflow, etc? People support to review/answer questions?
- Do you require a transition plan from an existing process or practices?
Education is key, but there are a number of things to figure out. Maybe the invariant in situations I’ve encountered is repetition. You can’t just explain and walk about. You also can’t stop with explanation. It is likely that you will need to bake some aspects into your new process. For example, if you introduce a new template you can add informative text within it. If you create an automated process, add reminders that go into Slack, or enforce certain fields with explanatory text to match. If you are going to do some formal education such as lunch and learns, or dedicated presentations, ask yourself the following:
- Who will do the educating? Public speaking isn’t for everyone, and again there is a quesiton of resources for who has time to prepare material.
- Who will be educated, and how? Will you use a presentation, a recording, a simple email update?
- How long should you provide information before switching over to the new way?
- Do you need to run a pilot with one team or group?
- How will you know that people have transitioned to the new process? How can you follow up with laggards?
A Word of Caution & of Encouragement
It is true that change can be hard. Yet it is often the case that the change is not so hard, it’s just hard to start. Consider whether change might just start with you and a small group. Don’t take all the questions above to mean that you need an exhaustive document on every answer; or that you have to change for everyone all at once. All change is harder the larger the change itself, and the larger the target group which must change. But whether large or small, difficult or easy, don’t settle for the status quo.