Clients hire us to make sense of all sorts of crises and systemic problems. While the specific goals and outcomes of each engagement vary widely, the majority of our projects follow a set pattern the first few days.
We start the day with a kick off meeting. This is an opportunity for the client to set goals and expectations, do brief introductions, and get an overview of “the problem” as the client sees it.
We then move to brief, informal presentations by the people closest to the problem describing how things currently work. These may include past risk assessments, architecture diagrams, and process walkthroughs. We insist that clients not create new presentations just for us. We’re happiest with a grab-bag of content repurposed from existing work, and unfiltered takes from experts.
Day 2 and onwards
Starting with the template and team members from day one, we’ll ask questions, read documentation, and generate ideas. Our goal is to iterate and make hands-on changes in partnership with the client’s team.
We will join any regular meetings where a client asks for our participation and engage with new incidents as they occur during the engagement’s time window.
We aim to be spending most of our time with people who are hands-on experts by the middle of the first week. These people can be claims experts, customer support agents, database administrators or software engineers who are keeping the client’s systems and processes running. They are the source of our best stories and insights. We’ll ask the people we meet for introductions to others as we work our way through the client’s organization.
Most clients like to set up a daily morning and evening check in with us. These are typically 15-30 minutes with the principals to share new questions, early findings, and roadblocks.
We’ll use the last day of our intensive engagement to present our recommendations to leadership and key team members.
Notes on our structure
Layer Aleph is small, and there is no hierarchy among the partners. We each have particular areas of expertise and interest which we’ll match to the client’s concerns during the engagement. We’ll typically have one person act as the primary client contact during a project. We are in constant communication with each other to avoid duplication and share insights, even when we split onto different tracks of work during the day.
We are most effective when we can access client systems directly, ideally by the end of our first day of work. The most important tools for us to be able to access are:
- Real time communications (Slack, Microsoft Teams, IRC)
- Document repositories (Sharepoint, Google Drive, Dropbox)
- Monitoring consoles (New Relic, Grafana, Google Analytics)
- Source code (GitHub, GitLab)
We negotiate expected deliverables with clients ahead of time and put the details in our signed statement of work. We prioritize actionable recommendations and will make changes (with permission) directly to client systems to drive improvements during the engagement. We find brief, highly actionable memos to be more useful than long reports, but if a client requires a longer written assessment, process map or architecture diagram we can absolutely provide one.
When working with particularly large organizations (thousands of employees) or wide surface areas for assessment (multiple C-suite stakeholders), we may ask for help from an executive administrative assistant or project manager. These people are extremely helpful for understanding the hidden organizational structure and getting time with key experts.