The company that I work for has been hiring engineers and has been pretty aggressive at it. We’ve spared no costs and efforts in finding talented and interested people. Unlike a lot of companies we value enthusiasm and attitude over sheer brilliance. The ‘why’ (do we prefer enthusiasm over attitude) has been covered several times and my reasons align with most of such articles and would be tangential to the point of my post.
I had been oblivious to the stigma that is associated with software consulting firms, especially with the sudden boom in product startups in all major cities. During the course of one of the interviews I was told that an engineer we were interested in speaking with wasn’t interested in working with a services company because he didn’t want to be tied down, checking off tickets assigned to him. While this isn’t uncommon at consulting firms the way he put it brought back a lot of repressed memories of my time at one of my first jobs at an MNC.
This also brought me to a more recent turn of events where I chose to give up on an assignment because it stopped feeling right. I had recently stepped off one my longest engagements (and one of my personal favourites) to take up a new project which after 2 months still seemed odd. It felt a lot like my first job. In fact my first job had projects which kept me going and interested, but this had brought me to a point where it seemed wiser to step down.
I feel it all boils down to the product/project managers.
As a project/product manager its vital to embrace your teammates/engineers in the vision of your product/project. Its important to ensure there is no disconnect between what you envision as the goal for your product and what your teammates ideas are.
So what made one project a personal favourite while I couldn’t wait to get off the other?
The better product manager ensured that I was always involved in the day-to-days of the project. Things like keeping me involved in customer feedbacks, issues the accounting team faced and what the company aimed to accomplish gave me a sense of purpose. It defined my role in the success of the company and made my work seem purposeful. Every commit/fix seemed to validate my contribution to the success of the business.
The other, just ensured that I knew about the issues that needed completion and how the module had to work. This was very literally checking off tickets. I had very little vision of how it fit into the grander scheme of things. There always seemed a level of disconnect that I couldn’t seem to get around. I wasn’t aware of what the project was planning next and why it was doing that. So, my interests were solely aligned in getting my features and tests working. I was rarely aware of when my features were merged and was generally notified when there was an issue.
While some may argue that its impractical to have everyone involved in the big picture. I feel its up to the people managers in each team to ensure they carefully abstract the information to the right level to keep everyone feeling like their contributions are purposeful.
So what if the information was already abstracted to the level that I needed to know?
This is where great product managers shine through. If you’ve made it this far its worth getting into this one.
As part of my first job (at the MNC) I was part of a 4 person team that was responsible for automating all and any kind of tests that needed to be run in the company’s QA boxes. At this point, I was a clueless, fresh grad who wasn’t sure how I could be of any use to this project.
My project manager (one of the most experienced engineers at the company) told me that I had to look into a set of tools that would convert any kind of user activity on any web page into a set of reproducible scripts. He then went on to let the other guys know what they would be working on. It seemed like a fairly straightforward task given that the tool did most of the stuff and I had to pretty much just follow the documentation to get things working.
At the end of the day when we all had dug into the nuggets of information that he had distributed, he came in to tell us how each of the modules that the 4 of us had been working on, would interact with each other, to ensure that all the tests were run and reports generated. There have been very few moments in my life where I was hit with such clarity of thought. The beauty of it all was that If he shared this bit of information at the onset it would’ve seemed a lot more daunting. This way he broadened the scope of our work and vision at the right time.
So, my point is that being a project/product manager is hard. Being able to understand the motivations and passions of each of your team mate is tough but important. If the vision and the goals of the uppers management is not conveyed correctly down the chain your pretty much running on zombie legs.