A reflection on leadership in software.
Background
The Initiative
A few months ago I had an initiative that I have been wanting to realize. In the company that I have been working in, there seems to be a lack of documentation for teaching and no media for knowledge sharing between teams. I thought that there has to be one, for the better of us all. So I approached HR and proposed this project. To help people learn. Since I work on a university campus, I thought it might be a good idea to have the learning management system (or LMS for short) be available to the students there as well.
Well, that was the initial plan. As all software engineer knows, when it came up to requirement gathering the requirements were not really exactly what I wanted. It was less of an LMS and more of an HR information system. Well, I didn’t mind. The LMS part of the system is still there, and I think that’s good enough as a start.
So a month in, the requirements were accepted by the user. Resources have also been allocated for my lone project. Initially, I had a team of 3 people. It was me and two other guys. Knowing the project was going to use a new tech-stack they have never used before they bailed. “Well,” I thought, “It’s back to square one”. Luckily for me a year prior I was one of the interviewers for some of the new trainees.
Gathering the crew
It was surely a stroke of luck that my relationship with the trainees was on good terms. I met one of them a year ago when I was active as an activist at my Uni, and I interviewed the other one. So, I figured they would like to have an opportunity. So it came the time — I asked. I breathed a sigh of relief after they said that they were interested. A third person joined after he heard about the project from his friend, interestingly enough.
I orchestrated the first meeting for the four of us. At the beginning of the meeting, I said that it will be an opportunity for them to learn new skills. Since I was going for a relatively modern tech-stack (for the year 2020). A Vue frontend and a .NET Core backend. Just like that — the project was on.
Happily ever after — sort of…
The three trainees’ main responsibilities would be code, my responsibilities were more — many more. Sure I tried to do project management by the book. I used a virtual board on Azure DevOps to list all the requirements, and I also arranged weekly meetings to calculate the project’s velocity. I thought that would be enough — boy was I wrong. First of all, I may have relied on the trainees a little bit too much and I needed to back them up more than I thought. I am not blaming them, it was my fault for not considering their skills thoroughly. Second, I think my requirement gathering skills have a lot of room to improve. I analyzed a few features wrong and came up with very conflicting results — I had to clean this up in the end, it was my fault after all.
So here I am being a project manager, guiding the trainees, fixing all my requirements, talking to the techies in my company making sure everything was safe, secure, and best practice. Boy… that was an experience. I honestly felt bad for the people I led because they might be more confused than I am. Though I always try my best to help them solve their problems. I did promise them that they would get something and I really meant it.
What I’ve learned
Mistakes made
I have been a programmer for 3 years now and I think it’s about time I led my own team. I won’t lie that it was easy nor relaxing. It was a stressful experience with many mistakes made along the way. I was lucky that my team was made out of trainees eager to learn, thus they still continued on through my less than average project management skills. It was a learner though.
After being a project manager I now can grasp what needs to be done by a project lead, or team lead. This is why those roles have less programming and require more time to literally manage the ongoing project. Good project management can be done if the person in charge is focused on doing so.
I was a little to stretched thin at that moment. I needed to help trainees solve problems that they couldn’t while considering the project and safety of the entire codebase. It was a real hassle. I don’t want to say that I was busy, rather that I could not focus on what I should have done, managing the project. System analyzing wise, I can confidently say that — I suck at it, still a long way to go. I didn’t have a good design doc to look up, only a few notes on how it would be made. So I have to read what I wanted to do, probably a user diagram would be helpful or an application flow diagram. I know that this is software project 101 but I am honestly saying that I missed that. I really blew it.
Now look at this diagram, can you imagine the number of roles needed when we want to create this application? You can see the diagram. It is as clear as day. Now imagine having no diagram and trying to understand this system by writing. Better yet, try to translate this diagram into a paragraph. Good luck! I didn’t make this and it made me forget what I wanted to do indefinitely. A big lesson learned. Feature-wise there should be a clear application flow to explain how the system works, how the users register, and so on. Sadly I also didn’t make it. It contributed to the disarray of the trainees under my wing. It showed how a project with good intentions became a complicated one at best. “If only”, I said to my self, “I have done this”.
I used waterfall as the software development lifecycle because the requirements were constant and the user wasn’t much of a hassle. This further amplified my mistakes because — waterfall absolutely needs these kinds of diagrams. The requirements were constant and might as well made diagrams from the beginning to help understand the system beforehand.
If I were to use agile however my huge mishap might be forgiven a little bit. Because if you were to use agile even though an initial design doc is very important, the requirements are fluid thus you might have no time to keep making a design doc and must continue on programming to finish the project before a deadline. I am not saying that a design doc is not important, not by a long shot. I am just trying to imply that the requirements are fluid and you might be forgiven for making a design doc that is slightly different from the end product.
A Realization
I realized why it is important that project management roles shouldn’t be too caught up in programming. There are a lot of things that need to be arranged by a project manager, like making a design doc and managing the team’s workload. Deep respect to all project managers out there doing it well.
Of course, in the end, it is not all about the project rather the interactions with the people in the team are very important. In regard to this aspect, I feel that I have done a good job. My relationship with the trainees I led has nothing but improved. We communicate more, we are able to joke together as friends. I am able to teach them and communicate my thoughts with them clearly. In my opinion, I think socially I am already viable enough. Communication with higher-ups and other teams were also great.
In the end, the project is planned to have its phase 2 of development. I have other projects thus I will not be continuing my role. Thus, the role of the project manager will fall to someone else.
Conclusion
In conclusion, I really enjoyed the opportunity to lead my own project. It really helped me understand the flaws I have in leadership and gave me a path to further improve myself. The company received the project well since they plan on having a phase 2 to further develop it, making it into something better. Being the initiator is truly a dream come true. To all the people who believed. Thank you. Mistakes were made, but from them, we learn new things. On that note, here is a good quote to end it.
The master has failed more times than the beginner has tried – Stephen McCranie
