This week, I've been fortunate to identify two key principles.

  1. Document everything
  2. Become a cross-team asset

Document everything

For smaller companies / less developed companies (startups included): Most processes and knowledge are not well defined and documented. This is due to lack to time, constant things to deliver, siloed workstreams, poor office culture regarding sharing, etc.

Regardless of the reason why it does not exist, documentation is necessary. Necessary for new-joiners to understand the business, necessary for a single-source-of-truth to agree upon, necessary for process improvement projects in future. It is also a form of scalable knowledge.

Even a simple PowerPoint dictating the key processes, roles & responsibilities, order sequence, decision items, constraints, dependencies (on both internal and external systems/people/teams), etc. contains so much information:

  • Lead times for each process (allowing us to identify bottlenecks)
  • People that are overly specialized - if knowledge is not shared and they leave the business, there is a large opportunity cost to the business. Cost is the time and effort needed to either a) find someone else to hire or b) train someone internally. Training costs & time costs in allowing the new person to get up to speed. Maggie example where she is also not willing to share i.e. gives up her info reduces her bargaining power
  • Dependency identification - either strengthen or diversify or in-house?

The question then becomes great, I should document. How do I do that?

First, is there a clear need? At my first month on the job, most teams had different information about a process. Everything was in everyone's heads. But everyone had a different story (slightly). This made the method of collating a process simple.

  1. Identify a process that needs documentation
  2. Identify the people that can contribute to building the full picture
  3. Interview them and collect insight
  4. Consolidate information - identify any areas of alignment vs. contradiction
  5. Review low-level documentation with everyone (don't make anything pretty yet); should just be legible and easy to review - make sure the information is correct
  6. Iterate until everyone is happy with the single-source-of-truth
  7. Build a nice looking visualization to support the sharing of this document
  8. Use the document to further research / analysis for improving processes / reducing risk

Become a cross-team asset

How do you go about getting information?

Support multiple teams - talk to different people, share your ideas, etc. By being an asset, you do not necessarily need to be working for a particular teams. Instead, you could simply be a soundboard and share ideas. What I realized within my first month was because I was one of few proactively speaking to multiple stakeholders, I learned a lot about the different ideas going around each team + learned about what projects were being conducted.

Be the gateway to bridge internal stakeholders. Example: I was working with Ellen on testing the ETC survey which enabled us to capture certain information from our customer base. I also worked with Koen on the geocoding assignment to categorize all our customers by location. I then later met Jeffrey who was talking about how he wished he could get access to: a) customer demographics and b) address data. It was very easy to bridge the gap.

Jeffrey, in particular, is incredibly swamped with constant BAU work in processing sales orders. He does not have that much time to go about collecting all these insights. Identifying similar individuals that hold responsibility but have too much to deal with are perfect candidates to show support because they will value this the most.