My first experience as a Project Manager
My first experience as a project manager began quite unexpectedly. At the beginning of my internship program at CodeCoda, ten other interns and I were asked to develop a product featuring our design. The project roles were distributed based on what each of us aspires to be soon. At that time, I anticipated that I would join the development team simply because, as a software engineering student, I’ve spent most of my time coding and developing UI.
Development is what I am most experienced with and, naturally, feels most comfortable doing. Yet, when I was asked about my preferences, I confidently explained that I was open to new experiences. And so, the role of a project manager was a perfect fit. Surprised and still holding on to the coder mindset, I exclaimed, “Only?!!” (obviously not knowing what my responsibilities as a PM included). After my initial surprise, I accepted the challenge of being only a manager. I comforted myself thinking I could also take on frontend tasks while the others are busy, and there’s nothing to manage. Oh, the naiveté!
THE APP
Lavina is all about action and connection. About initiation and face-to-face interaction. Had it existed before, it could have solved a problem all of us had encountered at least once. Namely, having an event ruined due to a lack of people. While discussing the idea, it turned out that each team member had a different story for the same situation, and I know you have one too. Be it a ruined card game because of a missing partner, a football match missing a player, or anyone willing to join a group — the problem is the same, and we decided to take it into our own hands.
Shortly after the initial idea was put forth, our minds had generated numerous scenarios where such a platform would be an absolute game-changer. It could prove useful for events of all kinds and sizes. Whether you need a helping hand to take that old dresser out of the house, lots for a group project, or whatever else comes to mind, Lavina will save the day.
We had to make sure the users navigate easily through all the random events and find precisely what they need, so we decided to categorize them. Out of this solution emerged another problem, though, we couldn’t ever predict all the possible scenarios in which the users might find the platform useful, so we agreed upon giving them the freedom to create custom categories. By allowing the user to tailor the app to suit their needs, we also make them part of our team effort, especially considering the way we all contributed to building the app together.
By giving the user the right tool to initiate local group events quickly, we aim to popularize such gatherings, thereby helping them gain enough inertia for an activity avalanche.
THE PROCESS
During the first week, all we did was planing and discussing. Only after that did we start coding. Seven days in and I hadn’t written a single line of code. Being so unaccustomed to such a disposition, I started feeling (kind of) useless, so I decided to morph into a project managing interactive rubber duck.
From that point on until the end of the project, I found myself jumping from one person to the next asking what they were currently working on and whether they had any issues with it. Seemingly insignificant change, but it made me feel so much more useful. It allowed me to make sure that everyone knew exactly what they should be doing, all the while helping them stay focused on what they were working on currently. This approach also aided us in solving problems with agility since, as is well known, two heads are better than one.
Some idyllic days followed; the sun was shining, birds were singing, back-enders working their magic, front-enders and QAs learning what they had to, and me - supervising, assigning tasks, and trying to help solve developers’ problems. Until we realized we needed a designer to the frontend with more ease and fewer alterations as well as a dev-ops to dockerize the project since we decided to build it using several microservices. Well, we didn’t have much choice but to frankenstein those using some of the team members’ yet undiscovered talents and a few helping hands from the professionals in the company. And so we managed.
WHAT I’VE LEARNED
Sometimes you better keep your head out of the clouds
As we didn’t have an actual client to work with, we were the ones to define the requirements for the app. It was so tempting to fantasize about what we could turn it into imagining we had already built the foundation, but losing touch with reality could only trick us into lavishing resources for implementing unnecessary features leading to the postponement of the first release. To prevent this delay, we had to make the distinction between ideas for immediate and future development. And it was my job to make sure we did it right.
You won’t please everyone
When it comes to decision-making, I try to involve the whole team in the process. I like to allow everybody to voice opinions and share knowledge because it encourages a strong sense of teamwork and understanding. Additionally, this approach gives the team better insight into future actions, why, and how they were chosen. I believe that if you provide transparency and involvement in the decision-making process, people respond with much more enthusiasm because this approach promotes a greater sense of fairness and autonomy as opposed to handing them down a final decision taken behind closed doors. Despite that, though, at the end of the day, you won’t have pleased everyone, and you shouldn’t strive for that. When working in a group, your goal should never be to please everyone but, instead, to work towards your group’s best interest. The former will never happen anyway.
Redo is not taboo
The first few times I had to make people redo their work, I felt kind of uncomfortable because I thought I might not have gotten my point across in the first place. Of course, that could as well not have been the case, but be it a communication problem, poor planning, or somebody’s misconception, telling people they spent time doing the wrong thing is not pleasant for either side. Though, it happens an awfully lot of times whether you’re working alone or in a team. For the sake of your project - you should learn to deal with it. Compromising the project by cutting corners to spare yourself or the team some extra work might not be the best approach in the long run. Getting a bit of immediate satisfaction doesn’t sound like a bad idea until you realize that it could be at the cost of a failed project.
OVERALL
Overall I am 100% satisfied with my first PM experience. Not because it was a breeze, but precisely because it was not. The high times I enjoyed the trying times I hope I learned from. Fortunately, the lessons I learned are far more than three, but that’s the amount I managed to put into words.
In fact, the amount of new information I’ve learned during the internship at Code Coda is astonishing, given that it was only a month long. Apart from myself and my team’s needs, I also attribute this to the super helpful people at Code Coda. They were always down to tell you about their experience with the issue you are currently struggling, offer advice OR refer you to someone who might have dealt with something similar.
Colorful. If I had to choose one word to describe the inter-team experience, that would be it. When you bring together eleven people with utterly different interests, aspirations, competence, and, most importantly, personalities, you get precisely that - a colorful experience. We all had one thing in common, though - little to no experience working in a team of more than two people. All of us got used to working in a team surprisingly swiftly and effortlessly. That doesn’t mean we didn’t have any setbacks, though. Of course, we’ve had our peaks and troughs, but what’s more important is that we were cohesive through both. When somebody was faced with an issue, we tried to work it out together. When someone completed something successfully or had a great idea, we rejoiced with them. We weren’t competing with each other. We were competing with our past work, trying to improve on it every day. That’s the goal I’m striving for when working in a team, and I’m very proud that we achieved it!
