For the first years of my career in technology I was an individual contributor specializing in Network Engineering. I was Cisco certified and really enjoyed the process of building and troubleshooting networks. I also liked writing an occasional coding project and automating some of the routine tasks, but realized that wasn’t where my greatest talent or passion was.
I was working in Google at the time and worked around many TPMs. Some of them weren’t very helpful, and the only things I got from them was a daily request for status of my tasks and when it will be done. Then they would copy and paste my responses in the emails they sent to the leadership team, receiving congratulations for the work me and fellow engineers did.
Now as project managers we do often have to request for status updates and communicate with our leadership teams about the health of the projects and the values they deliver, but I believe there is so much more to the job.
Some of the TPMs I worked with, however were amazing, legendary and awe-inspiring. They were leaders. They listened. They were the guiding light the ships look for at night while at sea to know they are headed in the right direction. They knew the path to victory. The studied deeply. They new the organization well. They were holding themselves and others accountable. They were in the trenches with us. They were willing to get their hands dirty and do anything they could. They protected the team. I often saw those TPMs go into the meeting with the executive team and take full responsibility for the project running behind schedule. Saying things like I failed in anticipating a certain risk, I was not able to estimate the size of the effort correctly, I didn’t obtain the full set of requirements in a timely manner. They never once brought the pressure they felt on the team. And when they succeeded, which they did very frequently, they never took credit. It was always the team.
Aspiring to be that type of a leader, drove me to the field of project management, to sign up to Stanford’s Advanced Project Management Program, get my PMP certification and eventually make a transfer to get my first role as TPM. The process Google refers to as ladder transfer, in my case it is a transfer from an engineering to a TPM ladder.
The ladder transfer involves a series of interviews with a number of Program managers, who would then make a recommendation for your transfer if they feel you are ready. To prepare for these interviews I found a few mentors to get a better understanding of what it takes to be successful in this new role. They were happy to share their time with me and we had a number of conversations that I consider transforming for me to this day. They taught me some of the best practices they use, of how they do their estimations, create scheduled, work breakdown structures, critical paths, run meetings, deal with changing priorities, timelines and budgets. But the one conversation in particular sticks in my mind the most.
One of my mentors Mike asked me this question: “What is the most important outcome for a project as a TPM?” In my mind I was thinking wow that’s an easy one. I said: “To finish the project on time and budget?” I was very proud of my quick, concise response. He thought about it for a while and said: “Not a terrible answer, but I think that would be like the third in terms of the importance, you want to guess the first two?” I had no clue. His answer I will never forget. He said: “First and most important. Improving your team.”
What? Improving the team? I mean aren’t we here to get these projects done as quickly and cheaply as possible. He said, “Yev you are playing checkers, while you should be playing chess. Your team is a single most important asset you have. One of the things you have to constantly think about is making sure they improve as individuals and as a cohesive unit. Their skills are well-rounded so if your database subject matter expert is unavailable your project does not fail. They have a shared ownership of the project’s vision. They support and help each other. They learn how to resolve their internal conflicts, how to draw from each others’ strength. They can make good decisions as a team. They should not need you everyday or even every week.”
“Wait, wait a second, hold on. If they don’t need me, why am I even here”, I asked. He responded: “If you built a great team and the program structure, you are free to focus on other things, this machine is working just fine, just fine-tune it once in a while when needed, routine maintenance, oil changes, break pads, that’s it.”
OK, so what is the second most important thing?:
“The second most important thing is building the right thing. The thing that your customers will use to solve the problems they need to solve. If you build something quickly and within budget, but it is not what your customers can use to solve their problems, you have just wasted everybody’s time.”
“Again, hold a sec. In the initiation phase of the program, we gather all the requirements from our stakeholders, our customers, right. We document it we get their sign-off, their buy-in right. We build the thing to spec, right?”
Mike’s response: “Right, but I don’t think it’s possible to do all that in most cases. I don’t think you can ever gather all the requirements. I also don’t think your customers even knows them all, they often times don’t even know what it is that they want in the first place”
My head was spinning. My PMP books were missing all of this.
“Time out, Mike. If you don’t have the requirements, you don’t have the spec. How the heck will you know what to build”
He said: “You don’t. Here is the best thing you can do though. Figure out the problem. What is the problem. Be super crisp about it. It is the most important thing. Get to the root. Automating something is not a problem. It is a solution. What is the problem? Inefficient router upgrade procedure that is expensive, manual, boring and error-prone is the your problem. That’s what you are solving. Your team of smart software engineers may has an idea of how to solve it, but they are not the users of that solution, they don’t know. Figure out what is the MVP, something they can get their hands on, see value in it and give you feedback, why was it good, why was it bad, what you should add and remove. Take that feedback into account. Deliver them V2, rinse and repeat, until you got something that solves the problem well enough, and people use it.”
The very first project I was assigned was……interesting. It was building a system that takes all of the changes being planned on the network and automatically performing a risk assessment to determine if it was safe or not to do at a given time. It would not only provide a risk rating and summary of why it was risky or not in terms of the impact to a network capacity, but also provide a recommendation of when it would be safe. There were nearly a thousand changes that needed assessment on a daily basis. The task was essentially to automate the change management process of the biggest network on the planet.
The project had a number of amazing software engineers. They had a fairly detailed design and a lot of code already written. But at that moment the project was running a number of quarters behind and a team leader was begging for a TPM to help them get on track. And I was the guy for the job.
I spent the next week reading countless design documents, diagrams and details of different system components expertly written with an amazing level of detail. I held meetings with the individual team members and a team lead to figure out what they were working on, their challenges, their vision.
The weekend before my first team meeting. I decided that I can’t really provide a lot of value in defining their technical strategy. This was a team full of amazing and highly experienced software engineers. What I can help with is making sure we are heading in the right direction with clarity and moving the ball forward. The project is really behind, nobody is expecting for it to be successful at this point. I can take some risks here and see if it works, if not will pivot and change our approach. Let’s pay attention and learn.
In the first meeting, after getting what everybody was working on, which were different components of the system, I even surprised myself, by saying what is our MVP?
I had a few stairs and then our program lead said. Well we have a design done, a design for everything that we need and It’s detailed enough where we can write code, which is what we are doing.
I suggested, if you had to build the bare minimum, but still something that can perform the most basic subset of functionality we are going for. What would that look like?
Next steps –> Figure out what MVP looks like, estimate the level of effort, set target for a demo = first milestone.
The first demo happened in 6 weeks. And it was a huge success. There were a number of teams that decided they want to pilot the functionality that was made available. These teams become our partners in shaping the product to what it eventually became.
Every meeting would include summarizing our short term goal (2 week sprints), where we are now and where we are trying to get to and ended with….you guessed it, Next Steps. The following meeting would begin with a follow up on our progress, or any risks or issues in achieving the previously identified nexts steps. This became our habit, next steps, next steps, demo, demo.
The program was a success. The team was happy.
One of the managers publicly said that I saved the program that nobody thought was going to succeed without adding any additional resources.
Again, surprising even myself, I said, “I didn’t actually do anything. The team of amazing software engineers took on an incredible technical challenge, came up with never before thought of designs and solutions which they implemented flawlessly. All I did was adding a few next steps and scheduling a few demos. They did it, not me.”