Dream Big, Be Incremental

Problem

I was an engineering leader at a startup company when one of my colleagues left. I was responsible for taking over his teams including teams for which I had no direct expertise on. My background is in software but I ended up taking over some hardware teams. I needed to find a way to make a successful transition to leading these new teams.

Actions taken

My first order was to make sure that the teams would hold together and wouldn't splinter apart. Every person was critical, especially since we were a startup, so I couldn't afford to lose anybody. This was Column A. Column B included figuring out how I was going to lead teams even though I wouldn't be able to technically evaluate the decisions that they were making. To tackle my first goal, I hustled to meet with everybody on the team individually. I reassured them about the transition and began gathering data about where the team was at, where the project that they were working on was at, what was working, and what wasn't working. At the same time I met with all of the stakeholders and asked them what the team should be responsible for and, more importantly, I asked them what the team shouldn't be responsible for. With this information I tried to define crisp clear boundaries so that each of the teams really understood what they were accountable for, and also so they could have an unambiguous ethos. Once I received all the necessary information, I had a clear view of the correct structure for the teams and where everybody currently stood. I slowly started evolving existing structures such as team meetings and how they got work done into what I thought would work best. To do this, I had each of the teams commit to achieving a small action that was publicly viewable as well as being something that they cared about. The actions were small so that they were feasible to accomplish with little likelihood of failure. Additionally, the action needed to be squarely within the ethos of what the team should be working on. Then, teams would go and accomplish these tasks. Completed actions helped the teams bond, gave them a renewed sense of being a team, let them feel like they were getting things done, and helped ease the fear that another leader would be leaving. After a few months the teams were significantly more resilient than they had been before, even before the other leader had left. Furthermore, I was able to compound upon the success of evolution (not revolution) and so after six months - having gone through these incremental steps - the teams were much more productive overall. As for Column B, the technical side of things, within teams I identified leaders who were experts. It helped aggressively cultivate an honest rapport so that I began to easily sense where things were along the line. I started to understand when someone was padding versus when someone wasn't padding. I was then able to use that gut instinct to pull out the decisions that they were implicitly making so that I could be sure that they were the right decisions. Therefore, it was less about gaining direct expertise on hardware design and more about interacting and building rapport so that any implicit assumptions or plans began to become explicit. This enabled us to debate decisions and to ensure that the teams were doing the right things.

Lessons learned

• It's important to understand what your team should be doing. Make sure that the team agrees but also be sure that the stakeholders agree.
• Get your team to come together around some artifact or deliverable.
• Although it's important to have an end goal in mind, often the best way to enact change is to do so incrementally. It is easier to get a team to agree to a small change than a very big one, especially if you can show the impact of that small change right away.