Reflections on project management
Welcome back to my blog!
Howdy internet friend, and welcome back to my blog! Unlike the weekly update posts, in this article I want to discuss a specific topic. For those readers who are unfamiliar with my work, without mentioning the company I will simply say that I am a security consultant, and have been consulting for the last few years. Generally speaking, my consulting has been on issues of offensive security. Activities like penetration testing, vulnerability scanning, and security awareness training have made up the majority of my professional consulting experience. However, this week I am finishing an engagement that is different from any other I’ve worked on in my career. I was assigned a staff augmentation engagement to spend six months working at a major financial institution managing a project. Since I’ve never managed any projects before, I had to learn very quickly what works and what doesn’t. In this article I am going to share with you some of the things I’ve learned in my six month experience managing a project. I hope you find value in this article. Finally, I’m not going to mention any specifics about the project I was managing except to say that I was responsible for getting teams of developers to volunteer to scan the code they are writing in a static application security testing solution not sold by my firm. My company built the previous scanning tool, and myself and another consultant were retained to get their developer teams up to speed in the new environment.
As mentioned above, what is challenging about this engagement is getting developers to volunteer for more work. None of the application teams were required to scan their code, and to do so generally means more work in terms of remediating the results. So the challenge - how do you get teams to volunteer for more work? Consider that many programmers (including one of my first programming professors) pride themselves on being lazy and of those that don’t, many love to find ways to make their lives and jobs easier (generally through automation). Thus the challenge of getting a group who generally like to make their lives easier volunteering for more work.
I wanted to throw in a quick section to talk about caveats. It’s important to mention that what I’m going to describe below is unique to my situation. Each and every situation you might find yourself managing will be different. As such, the methodology section below shouldn’t be considered a step-by-step guide, but rather it is intended to be instructive about my experiences. Each environment is different, and before anyone can successfully manage any project, it is important to get an understand of the company culture. If your team prefers asynchronous communication, then pinging people on slack/Skype/discord will get you a reputation for being rude. If your team hates e-mail and all your communications happen that way, you are starting in a bad position. So make sure the first thing any new (project) manager does is to get a feeling for the company culture and what works best at that organization. Without this information you are most likely going to be tilting at windmills. An investment in learning company culture will pay off dividends, so make that investment from the beginning and it will pay off before you know it. Having explained this caveat, let’s turn to now to the section on methodology.
We weren’t given a specific list of a few hundred application teams to contact. Instead, myself and a colleague had to go through and generate lists while learning about the client environment. Once we managed to sort out a list to contact, we started sending e-mails in batches of about fifty a day. When we had a list of respondents and whether they were willing to migrate we began the process of onboarding those applications.
Early on in the project, the person responsible for leading the engagement had a question about incentives and how best to motivate these teams of developers. As many of you know, I have a liberal arts academic background and my initial response to this request was to research and write a paper. So in the early weeks of the project I built out a paper on incentives and the best way to motivate a team. We revisited that document at the end of the engagement and updated it with what we found to work and what didn’t. This process had a few unintended benefits, but perhaps one of the most valuable was that it got me thinking about incentives and the best way to motivate developers. If you are struggling to motivate your employees, you might consider doing some research and composing a paper on your own - it might be more instructive than you realize!
My research turned up something interesting. Over and again the results indicated that people were more interested in praise and non-monetary compensation than in just getting more money. This was counter-intuitive for me, because I assumed that people would be mainly motivated by money. However, it turned out that I got the best responses from the teams by just being nice. When the pandemic started forcing teams to work from home, I changed the messaging of my e-mail messages. I let them know that I understood these are extraordinary times and if they wanted to move back their onboarding a few weeks, we would be happy to accommodate them.
Out of everything we did on the engagement, nothing worked out as well as just being nice! While this was surprising to me as a result, it matched up with the research done earlier in the incentives paper. Which leads me to the following recommendation:
- If you are leading a project, whether it be for the first time or after years of doing so, invest time and research incentives!
- Do not underestimate the benefit of being polite and kind.
- Be honest with people!
- Do not underestimate the power of empathy.
I discovered that after spending time both inside and outside the office thinking about how to motivate the teams of developers, when it came time to do the job much of the work had been done. Furthermore, I discovered that by the end of the engagement working with teams was much more smooth than at the beginning. Part of this had to do with the benefit of spending six months improving processes, but that didn’t account for the entirety of improvement. Investing the time for yourself to read articles about how to inspire your team will pay dividends in the future. Just the act of thinking how to better meet teams where they are will have a noticeable improvement on relationships - at least they did for me.
In that same vein, it’s important to note the benefits of being polite and kind. Of all the things that I changed throughout the project, changing my demeanor had the most immediate and noticeable impact. Being friendly and getting a reputation for being nice is a change from what people were used to regarding security. Often as security professionals we get the reputation for always saying no. Well, by trying to shift from “no, because” to “yes, if” we were able to begin seeing better results. Shifting from an empowerment focus away from a restriction focus helped improve the relationship with developer teams almost immediately. I also noticed one of the people I was most friendly with started taking on additional leadership in the project, to the point that he lead an onboarding for his team while I just watched and answered a few questions.
My last two suggestions are simple but powerful. As I mentioned above, COVID-19 pushed the customer to shift during the project to work from home which presented a few challenges. However, by reaching out and letting the teams I’d already contacted know that I understood there was an ongoing public health crisis and offered the opportunity to move back the process a few weeks. Many teams took me up on this offer, and greatly appreciated the flexibility. I honestly told me them I understood how trying these times are and if they would like to revisit the issue in a few weeks, I would be happy to accommodate them.
Finally, it is important to point out the power of empathy. Over and again when I gave people a little compassion and empathy, the results were always good. No one was nasty or rude when given the benefit of more time and empathy. Sometimes all it can take to make a change in a situation is to meet people where they are, be friendly, and the entire situation can turn around very quickly. Please do not underestimate the benefits of kindness and empathy!
I learned heaps from this engagement. I’d previously considered the idea of moving in to a more managerial role but now that I have experience doing it I feel confident that I could do the job well. I also understand why firms want people to have management experience before putting them in a position of leading. There are many potential pitfalls and it is not an easy job! If you can deal with being on phone calls often and frequently having meetings, than management might be for you. If you prefer to be technical and not have to tell people what to do, then remain in that technical role.
There is often a thought that career advancement for technical folks requires going through management, but that doesn’t have to be the case. In my experience the skills required to be a successful manager and a successful consultant are not the same. While I will have another post coming in the next few weeks on consulting more generally, I want to just add here that if you have read this post and thought, “holy crap! I don’t want anything to do with managing anyone or anything!” There are still options for career growth. Just because traditionally management has been where technicians end up, that does not mean it has to be that way. Many firms offer different tracks for their consultants - either technical or managerial. If you are not at a firm that gives you the option to remain technical, there are other firms that will.
Finally, I wanted to thank you for taking the time to read this post and I hope you found some value in reading it! If you enjoyed it, it wouldn’t hurt my feelings if you wanted to share it with your friends or colleagues. I also understand now why firms want people to have management experience before putting them in a position of managing. There are many potential pitfalls and it is not an easy job. If you can deal with being on phone calls and frequently having meetings, than management might be for you. If you prefer to be technical and not have to tell people what to do, then remain in that technical role. I want to conclude that just because firms have done things a certain way doesn’t mean that will always be the way that it is. As my father used to say, “change is inevitable, except from a vending machine.” This pandemic has shown that things that were previously “impossible” are now commonplace. Firms that would never allow remote work have shifted to a remote-first culture. Our world is rapidly changing, and those that are flexible are going to have the best time! Lastly, thank you for reading and I hope you have a very nice day and an excellent weekend!