Until my recent stint at a startup, I admittedly didn’t pay a lot of attention to project management. Most of my career has been at FAANG and for us project management came down to a few simple things:
- Define OKRs for a quarter.
- Setup standups and sprint planning. Track the work in JIRA or asana. We mostly handled these from the technology team, but had an occasional product manager or a technical program manager assist us.
- Identify stakeholders and then work alongside a technical program manager to manage stakeholder expectations and timelines. Write a confluence doc atmost.
- Send a celebratory email highlighting the launch and metrics associated.
In my last startup, project management became an untamed beast and suddenly, I was exposed to these plethora of titles and job descriptions that I never even knew existed. For example, there is an entire job description called (Scrum Master/Agile coach), whose sole job is to monitor on whether we were following SCRUM correctly or not! I waved my hand in frustration with my CTO asking for him to give me that additional $’s to hire a strong engineer instead. Luckily, he relented. There is a long reddit thread on how none of the successful companies have gone “scrum”.
But, he went ahead and established an entire organization built with a VP and all called DPMO: Divisional project management office. The reasoning was that technology and product don’t seem to agree and align on timelines, so we needed a separate department to coordinate them. I fixed it in my organization by bringing a common roadmap across tech and product and aligning them on aggressive deadlines and priorities. Some of my sister organizations didn’t and this led to an additional organization being built. This new VP hire set out on an empire building spree. They added three additional layers to this newly formed org: Directors, first line managers and junior project managers. The directors and the first line managers focussed on meetings to establish and the templates of communication and the actual work of tracking projects came down to these junior level folks. While they are friendly and nice people to work with, they simply didn’t have the technical acumen or business understanding to effectively function. A successful program manager understands the complexities of the relationships across teams and actively works to unblock each of the teams. This requires years of expertise as well as strong coordination skills. These junior level folks mostly acted as scribes to document meeting notes and to create slack channels.
Things became so bad that I had to constantly escalate to the VP of the DPMO office to give me a consolidated summary of how things were going along and where I needed to jump in. This resulted in the DPMO creating another hour long meeting with thirty plus people and an extensive powerpoint deck that gives us a status summary of each of the projects and with no clarity on whether things were going along nicely and whether things could be sped up. Meanwhile, my engineers and engineering managers were complaining to me that they found zero value in these meetings and that these so called project managers exert zero influence on unblocking teams, like ensuring that relevant teams stick to their timelines and being proactive in moving things. I jumped into one of these meetings and was appalled to see that my dependant team simply showed up to the meeting saying that they cannot meet the timeline as they didn’t do any work since the last meeting. I noticed the project manager writing down that as an update for the meeting notes. Sigh!
I once again escalated to my boss, the CTO who basically agreed with everything I said and then somehow still chose to double down on this crazy madness arguing for more senior project managers. Meanwhile, I simply decided to take things into my own hands by doing a weekly meeting (sad!) on project level summaries with my leads and managers and establishing a direct line of contact with my engineering and QA counterparts to get things going. Whereever we could, we went ahead and decoupled our engineering architecture with additional investments.
Some of these annoyed our DPMO and I was definitely not seen as a “team player”. But, our business metrics and impact were strong and hence we could get away as much as we could.
Final thoughts
Amazon argues that we should resort to process as minimally as we could for two reasons: 1) Process reduces ownership and 2) Process slows down velocity. If these are the outcomes you want, please go ahead and add process. But, if engineering organizations think that process is a way to make things faster, then you are barking on the wrong tree. I was surprised with the tone of my CTO and some of my counterparts on how they wanted more process to get things moving faster. Thankfully, I shielded my organization from a lot of process and was able to demonstrate that we could move faster with minimal process.
Many times, when we think of process, we think of additional roles whose job is to watch over engineering and it dampens enthusiasm and energy. Product owners, Scrum masters, Agile coaches, are all titles that take away ownership from the engineering organization. If you want to build an technology organization with high ownership, you need to reduce the middle-layers and strictly focus on job descriptions that bring value.
