Formalizing Processes to Gain Visibility in a Remote Organization

Problem

In the company that I currently work for the organization is fully distributed meaning that every single individual- including sales, marketing, and leadership- work remotely. As a director of engineering it is my task to manage the managers who look over the ICs and engineering department. Early on, I made the mistake of solely relying on the managers to tell me how things were going. When I noticed quality issues with one of the teams, I found that the manager became defensive about the engineers. The work that they were doing was subpar at best yet that manager was telling me these were the best engineers that he had ever worked with.
&nbsp

Actions taken

I quickly realized that I had very little visibility when it came to the performance of the individual contributors. A unique element of working completely remote is that you don’t have the ability to walk around and see how engineers are working together. You don’t get the chance to ask them what they’re working on and see them in action. Instead, I was relying on engineering managers to serve that purpose for me and provide a conduit of information.
&nbsp

I wanted to know first-hand which engineers were contributing value to the organization so we could give them the recognition, encouragement, and attention they deserved. Further still, I recognized that I didn’t have complete confidence in engineering managers’ ability to objectively evaluate the performance of the teams and the ICs. I discovered that I hadn’t put in place a system to be able to gain better visibility on what the teams were doing and how they were performing.
&nbsp

Due to the awakening nature of these realizations, I decided that I needed to take immediate corrective action. I implemented four actionable steps.
&nbsp

1. First, I chose to change the 360 feedback mechanism around engineers. Before, this feedback consisted of two simple questions that, not surprisingly, gave me less than adequate information on the performance of the ICs. There just wasn’t the culture of having managers think and dive deep into what they should be looking for regarding someone’s performance. Thus, the two question analysis was transformed into an in-depth analysis that hit particular points of performance. For example, how do they consider the performance of their work? How do they consider the operations of the work? What is the quality of their work? Do you have to do a lot of rework? These questions were more specific and gathered data on the quality and performance of the ICs so that I was gaining the visibility necessary about individuals on the team.
   &nbsp

2. The next thing that I did was pivot my team-based skip-level meetings to skip-level one-on-ones instead. In addition to the one-on-ones ICs had with their manager, I now had one-on-one time with each individual on a revolving basis. It took more calendar time, but it was worth it. I could then get direct feedback from the engineers themselves, probing what projects they were working on, getting a sense of what struggles they were having, getting to know how they felt about the quality and architecture of the work, and if they felt like they were given adequate support and growth opportunities by their manager. This allowed me to get a direct sense of an IC’s performance.
   &nbsp

3. Another component that was missing was that I hadn’t a clue which engineer did what type of work when a project was shipped. Of course we had a system for recording projects but the process was such that documentation were line items on a road map. Product managers reported the status of each initiative including whether they were completed on time or not but when things were finished it was unclear who was responsible for the work. Who led the project? Who was a major contributor? To resolve this, I put a system in place where we enforced a tech lead role on every single initiative, and we reported in the roadmap review reported who the tech lead was. When those initiatives were underway I was able to regularly inspect the technical spec, reviews, and output.
   &nbsp

4. Finally, we began having retrospectives for every single project. The reality is that I don’t have the time to sit in on every retro nor follow all the tickets related to that Sprint board. However, because I can clearly see who is leading the project I can go directly to that person and get the information I need. In fact, each tech lead writes up notes from the retro which allows me to clearly see where the team did great work or where they may need support and guidance.
   &nbsp

Lessons learned

• These new processes came from a combination of thinking how I would interact with this as an engineer and would it be sufficient, as well as talking with former colleagues of mine including directors and managers of managers. I was able to gather these resources, recognize that putting a process in place would hold managers, engineers, and myself accountable, and finally making the decision to formalize it all.
• Since making these adjustments, my ability to understand and evaluate the ICs’ and the managers’ performances has changed dramatically. I have a much clearer picture of my direct reports and their engineers. This is especially important when an engineer is doing great work but going unrecognized by their manager. I’m able to advocate for the engineer and push the manager to pay more attention. That quiet engineer may be contributing more than you think. Furthermore, I have more visibility when the time comes to exit someone. These new mechanisms have boosted my confidence in the decisions we’ve made because now there are specific things that I can point to and data I can include to reference back to.
• Prior to setting in motion these four steps, I relied entirely too much on my own intuition and reports from the engineering manager. Looking back, I understand that that was not best practice when managing the performance of a team. This was a direct factor of not having good visibility and one of the biggest mistakes I have made as an engineering leader.
• It is important for tech leads to be honest and forthright with information. I am able to get visibility from them not only on how the engineers are performing and growing, but also on how the engineering manager is leading. It is a built-in feedback mechanism that works on multiple levels.