Reading time: 11 minutes
When a company comes through changes by altering its development approach, creating new products, adding more features to existing products, or hiring more people, it might mean difficult times for the company’s old timers. We like changes but we also fear them. I’ve been working as a product manager for more than a year by now. During this period, my team has faced at least five big fears. I’m going to tell you about these fears and how we overcame them.
1. Fear of screwing up infrastructure
Quality assurance is the best method you can use to release your product without bugs. But, sometimes, you don’t actually have the equipment to check your code on.
We develop DCImanager, the control panel for server and data center management. And at times, we simply can’t create proper conditions to test the code in a virtual environment. For example, we have added the support of a new switch, a router, or a PDU but we have no equipment to test it on.
Some developers might skip QA but it’s not our story. In our case, one mistake can cost a lot. One variable is not initialized — operating systems don’t get installed. One mistake in your code — the data center goes down. Nobody wants to be responsible for a data center being down so this is the number one fear for my team.
How we overcome this fear:
- All developers review the code of every feature.
- We create lists of things that we can’t release the product without.
- After the release, we analyze what we might have missed. We describe in details what was done and what it resulted in so we could return to any task at any time and recall everything.
- We update our knowledge base, dedicate time to creating documentation for developers, and share our findings within the team.
- And the key thing. Any custom development made for a client shall be tested on the client’s equipment.
Once, we were adding the management of switch port aggregations for one of our clients. If we made a mistake, the client’s equipment in the data center would fail. Our client decided to come to the data center every night at 3 AM to make sure that everything was alright and get back to the previous version in case if something bad happened. You know, we might have lost the remote access to the equipment, which might have paralyzed the data center operations — this is not a joke. Happily, everything went fine.
2. Fear of losing a Q/A specialist
Our developers create unit tests but manual testing is done by people. Once, we had a situation when our team has lost their Q/A guy. We didn’t want to stop releasing new features so the only thing we had left to do is test each other.
It was painful. To be honest, all our programmers are ex-Q/A. For them, getting back to manual testing is a step back. They were afraid that if they do it okay this way, they will not receive another Q/A specialist. But everything went fine eventually. We’ve got our Q/A back in a couple of sprints and learned a lot of lessons:
- We were able to look at our situation from the Q/A perspective. For some cases, we added more actions to make the life of Q/A easier, e.g. statistics generation.
- We confirmed that a developer cannot test himself/herself because simply won’t notice some things. You need to test somebody else’s code.
- We also confirmed that Q/A is really important because they’re responsible for the final quality.
3. Fear of joining another team
DCImanager was released in 2013. Technologies have changed drastically over the 6 years. The time to develop a new version has come, and we decided to create it from scratch. We created a few prototypes, determined MVPs, and prioritized everything. Then we froze development of the old version. However, we couldn’t really start development of the new product: There were two other new products to be launched, and all forces have been sent to support their launch. During that period, my team had to join the team of BILLmanager, our other product for hosting automation.
And here we met another fear. Developers of the product for engineers were afraid to dive in billing. They believed that it was not the area they would want to (and can) work with. I felt it might demotivate my team. Unlike us, the billing team was happy to meet newcomers.
We had to work on BILLmanager for a few sprints. This also was a useful experience for us.
We did the following:
- We stayed as a team and didn’t depend on the BILLmanager team to minimize a potential stress from switching to another product.
- We picked tasks that had to be done yesterday but were not done earlier because of insufficient developer resources. Product managers discussed the tasks which were then translated to the team by me.
- BILLmanager developers were our mentors. The exception man was answering the questions while the teamlead was telling us how things must work.
- We had two standups. For one thing, we visited BILLmanager standups, for the other thing, we discussed our results inside our team.
Our lessons learned:
- When you work with another product, you have to read the other code and understand the logic of the product. Our experience of working in the billing team was successful due to the help of their teamlead and the patience of the exception man: We learned new skills and helped implement new features faster.
- We had a glance at how things work in the other team. It may seem that every team is similar but that’s not true. The devil is in the details. We learned some things from them, such as their ways of using a scrum desk, their code style, etc.
4. Fear of becoming a mentor or losing a teamlead
A company needs many strong programmers. When a developer works on his/her hard skills and goes to the Middle level, he/she will have to train newcomers. However, normally, a teamlead has to train the others. We did the same in our team until our lead developer has been sent to another product. The programmers lost their teamlead and now had to train new junior developers and each other.
The thought of becoming a mentor can terrify. You have to distract from your main tasks, work with other people, and explain clearly what you understand intuitively. If your padawan doesn’t understand something, it becomes your problem. If he or she has made a mistake in the code which you haven’t noticed, it also becomes your problem.
I won’t be able to tell you how to become a good mentor. But, we survived it and learned some important lessons:
- Give more context when explaining something. It might be clear and simple in your head but messy and difficult to catch in a real life.
- During the review, you need to understand what a developer wanted to solve with the code as opposed to understanding the code itself. It will help you better understand the logic and find mistakes.
- Share knowledge. This way, you learn how to form your ideas into words, prioritize things, and find better solutions.
5. Fear of lagging behind new technologies
The time to create the new DCImanager has finally come. We thought — this was it! We could finally start from the beginning and forget about old bugs and strange dependencies in the code. However, we also feared it.
The technologies were much ahead of us. The old version was created with С++11 and make. The new version was to be developed with C++17, CMake, Conan, and Docker. The team had to learn this all. It made us leave our comfort zone again, which was a true challenge. Everyone thought: “What if I fail and they fire me?”. We still master new technologies so this fear still exists.
How to master new technologies faster:
- Don’t be afraid to look stupid. Always ask for help from your senior colleagues if you need it.
- Record everything to help newcomers without repeating the same things 10 times a day. Keep your knowledge base up-to-date.
- Just google it. If it doesn’t help, see 1.
Challenges, not fears
I consider our experiments as a chance to learn something new and become better, and I want my team to consider the fears the same way. I believe that the climate inside the team depends on me. If you put faith in your product and your developers, listen to them during standups, try to fix problems during the retrospects, support your team members, and explain to them that changes are necessary, it will help overcome the fears.
But let’s be honest. We still have a couple of phobias we haven’t overcome yet. We are afraid of deadlines or feel fear when new people join the team. So far, I believe we can’t do anything with this. But, who knows, maybe we will win the battle with them in the future.
P.S. If you want to be the first to see a demo of the new DCImanager, send us an email to bizdev@ispsystem.com with the subject “Want to see new DCImanager”. We will notify you once we have it. If you need a product for server management but feel that the current DCImanager doesn’t fit your needs, send us your feature request — maybe we will be able to add your feature to our nearest roadmap.