Exactly as the so called “normal start” of a bright career in the IT industry, I had completed my engineering Bachelors and started out as a Software developer in my home city. Soon my programming skills brought me an elevation to Senior software developer at the same company. This company was providing software services to it’s clients. As a PHP developer, I worked on the most widely used website making software — no prizes for guessing, “WordPress”. This was my entry point into the deep understanding about delivery of complete web development projects. Before this time, I had acquired the basic skills that most programmers need: mastery of HTML, CSS, and Javascript, alongside familiarity with CakePHP, Yii, CodeIgniter, and Laravel.

By working on projects with clients based outside of my home country, I gained a nuanced understanding of the global web development scene. Ensuring that global projects were completed on time was often a major challenge. Client communication with representatives from my side often had to be managed very carefully because of different levels of technical know-how at both sides. This also meant that inaccurate progress updates were made, leading to mismatch of clients’ expectations somewhere down the line into the project. The ultimate mismatch of expectations led to lost time (and sometimes, clients) in fire-fighting.

After three years of rigorous technical learning through the endless slogging for delivery timelines, I was seeking for a change in my work environment. Working at companies that delivered software services, it had started to feel that I was repeating the similar software implementations and using similar programming languages. I did learn things and had felt that my skills were improving, but I was limited to a specific range of programming languages and technologies. It felt like being a cog in an assembly line.

Transitioning into Product Development

I moved on and joined a product development company — UXArmy. Day one, I was introduced to the UXArmy online user testing product by a colleague. It was fascinating to hear that description and see the demos although, the inside of me was cautiously suspicious about it — simply because such a product was technically quite complex to realise. If everything that were told to me about this product were true, clearly what lied ahead was a steep learning curve to overcome. I was also secretly hopeful that perhaps I’d learn something beyond acquiring different programming skills.

First steps into product development

During my first few months at UXArmy, I was handed over exploratory assignments on things which were seemingly expert topics e.g. Amazon virtual private cloud hosting. I did wonder if I’m getting to the right conclusions however, when I looked around to what other colleagues were doing, everyone seemed to be taking on bigger responsibilities than just task based assignments. Within two months of my understanding of the product, I was appointed team lead for a major part of the product.

By now and based on my open interactions with colleagues and business owners, it started to feel ‘I am doing something significantly different than in the past’. Here I was, in a “product-based company” as we call it in our software engineers’ gossip.

The Change had begun

After each submission of my deliverables for the assigned responsibilities, it was becoming clearer by the day that ‘survival by delivery of tasks’ was not an option for anyone here — delivering excellence and creating winning products was! I had started to work with a different mindset — broadening my technical horizon and applying my so-far-hidden ability to see the “helicopter view”.

Since I had started to work with advanced technologies, I also had started to look at the product features from users’ and business case perspectives. I had to learn to gear my communication to varying levels while speaking with different stakeholders. One time a business manager was unable to understand a programming constraint that needed insanely high effort to overcome, and I was thinking of ways to communicate this bad news to him. After some deep thought process (and pulling off few hairs), eventually I found that he was much easily able to appreciate the alternative user-facing solutions which did not need that NP-hard programming constraint to be worked around at all. To me, this experience brought in a big change in the way I used to look at problem solving.

Start of my Product management journey

Technical management was so different. The team at UXArmy has several highly skilled engineers working on different technologies and platforms for instance iOS, Android, Python, Angular, Ruby-on-rails, Natural language Processing, Social media integration, Video processing, and the list can go on. As a team lead, it was expected of me to provide solutions to new engineers at times. At the same time, it was not a possibility for me to become expert at each of these technologies at once. So this got me into (sometimes desperate) research of different technical skills and learn important parts of these technologies, at a high speed. I had to invest endless hours in researching on each of these ‘important’ topics and in fact some problems faced by us did keep me awake through the nights.

Over the course of my association with UXArmy, it’s been a gruelling but hugely satisfying journey. Starting to step into Product management, I see the three aspects of a product clearly — User Experience, Technical Feasibility and Business viability. I am constantly familiarising myself with several aspects of product development besides keeping abreast of the programming languages. For instance, by creating Feature Roadmaps and doing Proof-of-concept projects.

I have to keep an eye onto the competition product releases and updates. Before creating or suggesting any product feature at UXArmy, I have learnt to ask few very important questions to myself— Do Users need it? Would Users be happy using it? What can be built with minimal investment of expensive software effort?

Learning from handling software vendors

It’s smart to not make everything ourselves, “Buy” where it makes sense. Based on this belief that comes from our business leadership, I did have the opportunity to work with software vendors.

An interesting experience I have had is worthy of sharing. This experience was nothing short of illuminating – Vendors specialise in labour-intensive services/solutions that are often prohibitively costly. A good case, this Software Vendor, let’s call this vendor “Vendor A” allows organizations and universities to record, share, manage, and edit videos on the cloud.

With “Vendor A”, I procured a Cloud API based software solution that would allow websites to capture user behaviour via desktop video recording. This was a critical functionality of our online user testing product. I had to understand the software architecture of the “Vendor A’s product and, luckily it was very well documented. I had to endure communication difficulties with developers of this vendor because the developers used to suddenly go quiet, putting my product release deadlines at risk. As a unique experience, this “Vendor A” changed their policy of interaction via emails and didn’t inform their clients. The lack of responses from them left me wondering if they had chosen to move to a new business! It turned out that it was decided by the vendor to shift all communication to “chat” integrated on the website…”What a relief to find them again!”.

The communication resumed however, the journey forward was becoming increasingly hard. To make our product more user-friendly, I needed to request for a small software change to “Vendor A”. By going through various blogs and Stack Overflow, I was finally able to suggest a solution which required a simple adjustment in their software. This adjustment in software, for a developer like me, would take 30 minutes to implement. When I requested the change from this vendor, he offered me a quote running into 5 digits of US Dollars. That was jaw-dropping and also an eye-opener for me — I did realise that how hard it is for SaaS companies to be flexible. Scale shouldn’t mean inflexibility. At least UXArmy is not – being part of a team here which is so agile, I can vouch for this.

By this time it had become clear in the interest of our users, we were unable to proceed with “as-is” software of “Vendor A”. With a high-intensity technical feasibility study (Research, software proof-of-concept and benchmarking), I designed an alternative solution that could be developed by our own team and would be more easy-to-use than the solution of “Vendor A”. By tapping into the Browser framework’s platform for app creation, I devised a Browser based solution. It achieved the objective of recording desktop videos and incorporated all the features that were part of the solution from “Vendor A”. Our team turned it around in a very short time and we swiftly put the solution in the market.

This experience taught me the importance of having an in-house capability of achieving the desired functionalities without becoming overly dependent on third parties or vendors. This incident also reinforced the old saying that “Adversity is the mother of Invention” 🙂

The Importance of Soft Skills

As a Software Engineer Manager now responsible for a team of ten plus bright programmers, I also had to develop my leadership skills. In the past, arrogance, anger, and egotism had come in the way of my personal growth and effective teamwork. With empathy and respect towards my colleagues, combined with patience, I have been able to achieve success consistently.

I continue to encourage each team member to develop a sense of ownership of work. I help them to see the product purpose and also clarify how their role contributes to the product success and its importance to Users. This has led to improved dedication and motivation in the team, as well as better outcomes.

I never expected to see my team size continuously increase over time. In the near future, I feel inspired to come up with ideas that further optimise our workplace — an environment that eliminates the need to monitoring and gives freedom to new engineers from being caught in the “experienced programmer” false-belief. Everyone at UXArmy has great ideas on how to improve on team productivity, stress management, and the scope of learning — I feel an ownership to translate these ideas into practical implementation. By continuous sharing my knowledge of latest updates in products, technology, user behaviour and needs, I strive to keep everyone’s motivation levels high.

My challenge now is to keep sharpening my own programming skills while also contributing towards building a productive work environment. A well-circulated proverb stays in mind: “If you want to go fast, go alone. If you want to go far, go together.” At the end of it all, it’s all about the User, self-development and teamwork.

The Takeaway

To summarise, just coding skills/programming languages doesn’t take one very far in their career. It’s the soft-skills e.g. thoughtfulness, communication and other skills like process optimisation and deployment, that help to create a work culture in a company that get you leaps into your career. Having said that, the individual’s key skill of programming must be kept shining. So keep ‘sharpening the saw’!

Pramod Kumar is the author of this article. Pramod is part of the incredibly passionate team at UXArmy. He has driven his team to craft an online user testing feature that allows clients to perform usability testing of websites in a whole new way. Besides being a full-stack software developer, he regularly creates technology projects and owns the product feature roadmap. He can be reached at his Twitter handle @pramod1892