Changing Responsibilities In an Organization Undergoing Change

Problem

"When I started my job at my then-company, I was responsible to hire people quickly and build a lot of architecture, but I was able to stay hands-on coding most of the time. Everything was running perfectly and we built the first version of everything. However, as the company grew, anytime I would start coding, I would immediately get interrupted with questions and other, typical VP work. If I would ignore that to code instead, the other teams would be negatively affected."

"If I didn’t code and build things, the work didn’t move forward. If I did code, the work didn’t move forward."

"In the first phase, if I didn’t code and build things, the work didn’t move forward. In the second phase, if I did code, the work didn’t move forward. Also, the novel thing was that if I didn’t architect and create plans for the teams, the work didn’t move forward. As the team grew even bigger to 80 people, every time that I would start getting into the details of a new plan or architecture, I would be interrupted with HR or management work. If I would ignore that to do the planning, the teams would have issues and people were not getting what they needed. It used to be, if I didn’t architect, the team was not moving forward, whereas later on, if I would architect, the team suffered. If I didn’t manage the people, take care and grow the teams -- both internally and externally -- the work didn’t move forward."

Actions taken

"I fought it for a while as I enjoy immensely doing coding, planning, and architecture. It was hard to reconcile what I wanted to do and what others wanted me to do."

"Stop coding; you do boxes and lines, other people do coding."

"I gathered three other leaders from my organization to consult with them and I received the most direct and honest feedback from them. Their feedback was fascinating in its simplicity and conciseness -- Stop coding; you do boxes and lines, other people do coding."

"It was important for me to understand what the organization needed me most to do and to focus on that rather on what I felt I needed the most for myself, or a particular feature or product."

"Getting a council of people I respected and assessing what was the most impactful thing I could do and then, constantly reassessing how I was spending my time helped me clarify my thoughts and understand how my role has been changing as the company was growing. In addition, I would assess the consequences of me ignoring what people would ask me to do because many of those requests were completely outside of my scope. I was diligently keeping notes and reflecting on all the changes. In the end I left the company because it was too big for me. My role became too distant from the actual engineering work and I felt that type of role is not the right for me."

Lessons learned

"The primary job of an engineering leader changes a lot as a company grows. I identified three main phases: a. Being an architect and builder; b. Building the team, making the plans and working on architecture that other people will implement; c. Becoming people’s manager who deals with budgeting, hiring plans that are months out in the future."