As an engineer, I’ve always had a love/hate relationship with project managers. On one hand, they’ve historically been the first (and most difficult) roadblock to me making the “right” changes to a system. On the other hand, they’ve typically been there to provide valuable insight that guides and shapes the systems I’ve worked on. For a while I wondered what life would be like without a project manager. I would be free to run at the things I thought were most valuable and implement them correctly while making my own time-to-market considerations. I wouldn’t have to spend countless hours in meetings discussing how I planned on implementing something and why it was the right thing to do to someone who didn’t fully understand what I was saying and mostly heard me asking for more time and more resources for less features. It sounded ideal.
Flash back to a few years ago. I was working with one of my favorite project managers (let’s call them Bill) on a project I enjoyed. Bill was great for our team because they gave us a ton of autonomy to do things as we saw fit but was a constant reminder to stay on track and focus on the value. They offered a sense of accountability without treating us like children. During this project, which continued to grow in scope and change, they let me know they were changing teams soon and a new project manager (let’s call them Steve) was recently hired to take over this space. I was disappointed but willing to see how it went; prior to our current project manager whom I enjoyed working with, our team was working with the best project manager I’d ever worked with so I assumed this transition would be similar.
Now let’s jump ahead to when I decided to leave that job. I’d had enough about a year after Steve took over. When they joined the team they were pitched as a project manager with great technical skills who knows our domain very well. This sounded perfect; someone who would understand what I was pitching and why it was important, but that could also help us identify and chase real value. I consider myself a reasonable engineer that works well with all disciplines but I recognize that may be a favorable self review. During this year, I couldn’t seem to find common ground with Steve. We often found ourselves talking past each other, arguing over minutia related to either process or implementation. The only thing we could ever really agree on was that our systems were poorly designed and desperately needed the changes we were both advocating for.
When we onboarded Steve we got them familiar with our processes, products, and technologies. They seemed eager to learn and contribute and had a great attitude for working together. After our first sprint, the team agreed that things seemed to be going well. It wasn’t until the next sprint or two that we realized things were falling apart quickly. When our backlog started to run dry I approach Steve and said, “it looks like we need more tickets to discuss in grooming” to which he responded, “what can I do to help you create tickets?” I was confused; I’m usually the one asking that question. Sure, developers create tickets for tech debt and things that need attention that a project manager could never know about, but developers don’t define the roadmap. How was I supposed to know what the next epic should be comprised of, or exactly how the next milestone is going to be achieved? This is where we found ourselves frequently having opposite views.
We eventually had a few mediation meetings with an engineering manager that didn’t really resolve much. What did come to light is that we both were expecting the other person to be primarily responsible for creating and filling out tickets. Ultimately as a show of good sportsmanship, Steve took on writing more tickets for us. Problem solved! Right? This is where things got much worse. We then began arguing that Steve was being too prescriptive in their tickets. They would tell us what technologies to use, what patterns to implement, and how to structure the system. We rebuked these tickets. “Steve, we need you to tell use what to do, not how to do it!” I told them. They typically responded something like “How can I tell you what to do if the problem we’re solving is an engineering problem and I’m not an engineer?” To me, it felt like them shirking their responsibilities as a project manager. It was their job to understand what the problem space is and break it down into epics or milestones. From there, the team can fill out implementation tasks or describe how (and how long it will take) to get it done. Nothing seemed to be working properly for us.
When it all came to a head and I left, I found out shortly thereafter that they left as well. My new position was exciting and I learned that engineers here drove the ship. We owned the process and were responsible and accountable for communication and deadlines. It felt like a dream. Whenever I met with project managers they would ask me what goals we were chasing, how we were accomplishing that, and how long it would take for certain milestones. This felt right. They offered insight into what to chase and left the rest up to us. I felt invigorated and inspired to own the roadmap and lead the team.
During the next year I realized how this system works and how engineers in this system thrive. When you are a passionate engineer working on a system or domain that has growing pains and problems that are both technical and logical, there’s an abundance of things you can find to do that are valuable and worth doing. As you have more and more wins (and quick wins, too) you realize that all that is left are incredibly challenging or vague problems that require a lot more organization and nuance than “fixing the automated testing framework”. It was challenging to find my footing at times and I would feel a bit lost and without direction when I wasn’t naturally in tune with what our systems needed or what our customers wanted. It was in these moments that I felt like I wanted my old project manager Bill back. They would know just what to chase and how to chase it. These moments were few and far between, though. More often than those were moments where I was slowly realizing that Steve was right and I was part of a system that was largely wrong.
I realized that Steve likely came from a company much more like this one where their role was to provide guidance and nudging, as well as some valuable insight exclusive to their position, when developers needed it. They were exactly what I needed at certain moments in this new role. The problem was that I was expecting a relationship where either developers or project managers were doing it all. I was either asking Steve to do nothing and leave it to me or do everything and tell me how to do my job. We never found the middle ground because I’d never seen the middle ground before. It’s tought to admit because I remember in the moment how right I thought I was. Steve was the first of their kind, in my eyes. An oddity that just needed to learn how the world worked. That said, any project manager I’ve worked with up to that point was a “Bill” and not a “Steve” so it’s a natural conclusion to jump to.
My takeaway here isn’t that Steve was right and I (or Bill) was wrong. It’s that we need to do a better job of recognizing the job function required by the way a team and organization is setup. Steve’s approach was radically different than what my previous team and organization expected and so we were never able to find common ground. I don’t know that it could have worked without more significant changes outside of our team. What I have learned is to keep my eyes open for these kinds of water-and-oil scenarios and start asking whether the challenges of the situation can be resolved purely by correcting issues with the primary contributors to the challenge, or do they need something else? Is the misunderstanding something that can be explained away by talking to another person, or do we need a bigger mentality shift in the way we work? It’s not going to be easy, but you need to make every team and person you work with as effective as possible, and to do that it means you’ll have to learn how to execute a wide variety of different operational models; let project managers drive, let developers drive, share the load, and surely other models I haven’t worked with yet are all completely valid.
Let’s hope the next time a situation like this arises I can be aware enough to remember this experience and make it work instead of insisting on conformity.
William Custode 