Every micro era in an organization (whether it’s happening higher up, or in your typical team of individual contributors) has different problems which need to be met with what I’m calling “ad hoc arrangements.” There is such a thing as processes which are intended to be fairly indefinite, and then there’s these things. Let’s delve into a couple examples from my recent history. It’s my hope in this article to share with you what these situations feel and look like so that you may more readily identify them and act quickly to address them.
Influx of New Engineers
I once had (for lack of a more accessible term) a maintenance team. This team had historically been composed of domestic engineers, experienced in the app domain. Then, in the span of a quarter, we augmented the team with three overseas developers from India who were intended to be permanent members of the team. Obviously, these engineers did not come pre-packaged with experience in the domain. Furthermore, they were to be assigned a new feature project within the domain with a tech stack they mostly didn’t have experience with. To make matters more difficult, the tenured developers in the team were not experienced in the new feature tech stack. Thankfully, I was familiar with the tech stack, but I was managing another team and mired in administrative overhead, which somewhat dulled my response time to the situation I’m describing.
The typical model we had followed in the past for teaching new devs was oral tradition, and it wasn’t working out due to language barrier and time zone differences. Yes, there was some documentation here and there, but largely you couldn’t trust the documentation. For a little while, the early part of this project moved slow. These were competent engineers, but the odds were stacked against their success without intervention. Now this is where leadership comes into play – it doesn’t matter whether you’re the manager or not. These new members needed greater surface contact with experts to solve their problem. And as far as the team went, the domain experts were not the tech stack experts (or expert, in this case). So I created office hours after every standup. Standup remained as it was intended, for brief updates. Office hours became an enshrined part of the team schedule where anyone could ask anything. Having it directly after standup reduced the friction of attending another meeting. This was by no means a permanent process change. And surely, after no more than a few months, practically no one was coming to office hours anymore. Modes of discovery for this group had successfully migrated to Slack in the form of occasional questions in the team channel. Missions accomplished! Office hours abolished.
Knowledge Gaps from Reorganization
Our Engineering organization got cut in half, removing tons of domain experts and eroding established. Admittedly, this didn’t occur overnight, and there was a long transition involved in closing up existing projects and migrating the departing engineers over. All of a sudden anyone could be working on any arbitrary feature regardless of whether they were familiar with it or not. Everyone needed the resources to start working on a feature on their local, and ideally without having to seek help. So we sought to institute a policy where we would intentionally match a dev with no knowledge of the feature with a dev that had the highest knowledge. They’d be required to pair on it until the dev with lesser knowledge produced a document that would lead a new dev to getting to the point of being up and running. To ensure the documentation was good, we would have yet a third dev (also with no or low knowledge of the feature) come in and try to get things up and running.
In actuality, we never got around to implementing this ad hoc arrangement. The nature of the idea was solid. We no longer had Product department presence adding pressure into our roadmaps, so we ‘had the time to do it.’ But we ultimately had to choose another knowledge gap priority to focus on: devops and infrastructure knowledge. But that’s a story for another time. Suffice it to say, if we were to execute on the original plan, it would have been a temporary arrangement until we were saturated with ‘get started’ guides in every major feature space. And then we would have transitioned into a more steady state ‘keep the docs updated’ process.
Leave a Reply