On the Role of a Software Engineer
I’m not skilled at drawing. Whenever I try, I feel overwhelmed by the blank piece of paper in front of me. I rarely have a clear picture of what I will create or how I will get to a final product. Nonetheless, I decided to try improving my skills at a library class. Our task was to paint a cardinal on a tree branch. The instructor showed us the basic features to aim for, and I began sketching. My sketch wasn’t great, but I had to move on to adding color. I used the signature red and black colors for the cardinal and chose colors I enjoyed for the tree branches and background. At the end of the class, we looked at everyone’s watercolor painting. Although we all started with the same basic features, each painting differed significantly. We each took the basic requirements of a cardinal in a tree and shaped it into a unique painting.
The beginning of my software engineering career at Enova was like the pencil sketch stage of the cardinal. I started out writing code and doing typical tasks of a software developer. Along the way, I had numerous influences and could have gone in many directions. Like the cardinal drawing, my role could have been “painted” in many ways based on those influences. Working at Enova provided a training ground for me to hone my interests and abilities and figure out how to add value to the team. When I started, though, I did not have a vision of the trajectory I would take or how I would “paint” my progression. But looking back on my meandering path, I see an evolution in myself, and I hope sharing this story may help others actively consider ways they may shape their own roles.
When I joined Enova as a new Software Engineer, I was excited to create software that would be used by a large number of people. I vividly recall delivering my first big project, a new self-service phone Interactive Voice Response (IVR) flow that would provide critical information to customers about their loans. It was exciting to see it in action and see people using the code that I wrote — the keyword here being wrote. I did not design the IVR flow. I did not negotiate requirements. I did not know what problems our Product Manager was trying to address. I did not know which business metrics he used to make decisions about which features I should build. I just thought it was satisfying to build something of value.
Soon after, our team transitioned to support a new product, Headway Capital. Because our team was small, the engineers were invited to attend the weekly “pitch” meetings where we would hear from the Marketing, Strategy & Operations, Finance, and Product Management teams. Listening to these team members gave me context for the projects that came to the Software Engineering team. It was motivating to see the value our team’s work brought to the business and to its customers. With this extra context, I began asking questions and making suggestions to try to improve features we were delivering. As I became comfortable with the software applications that we built and maintained, I found that my growing technical knowledge of the product and the backend systems occasionally helped me to bring up a point of view that impacted the design of our project. The business team members had a perspective on the product, but I started to see that with my knowledge of the software and business processes, I could bring a valuable perspective to the table as well.
At the beginning of the Covid-19 pandemic, the Headway Capital product owners wanted to provide payment relief to customers whose businesses were negatively impacted by the pandemic. They wanted to allow customers in hardship to skip or modify payments without causing further financial hardship. They talked with our Software Development team about some ideas they had. We brainstormed some approaches, but the initial solutions were either not feasible to implement or not feasible to satisfy the goals of the business. The problem was challenging and interesting to me. Feeling motivated to help our customers, I spent some time thinking about the goals and constraints.
By this time, I was very familiar with our product and had detailed knowledge of Headway Capital’s accounting code. This knowledge uniquely positioned me to help find a workable solution for this problem. After thinking through our goals, I decided to talk with my manager about an idea I had for addressing the problem at hand. With our team’s trusty dry erase board to support us, we worked out the major details of this idea. We then presented the idea to our Product Manager and showed her how it would satisfy business goals and help customers. After she was on board, we worked together to present the idea to the Accounting team; with some negotiations and small changes, we addressed their concerns.
When the project was finished, it was rewarding to see the result. It was not lost on me how critical our team’s close working relationship with the Product Manager was in achieving this positive outcome for our customers. I also understood how important this close working relationship was in driving my development as a Software Engineer and in becoming an integral part of the team. I was fortunate to work with a business team that saw our Engineering team’s interest in the product and was willing to bring us along as solution partners. It gave our team a seat at the table in designing the solution to a challenge presented to us by the pandemic. Working closely with the business helped me shape my role – and added the watercolors to the painting of my role, so to speak.
Because collaboration was such a critical influence in my journey, I became curious about what this collaboration looks like from the Product Manager’s perspective. To this end, I asked one of Enova’s Product Managers, Shivam Malhotra, to tell me more about his perspective on the collaboration of Engineers and Product Managers.
Perspective of a Product Manager on a Software Engineer’s role and contribution
In my view, great products are built by teams that have strong collaboration. Great products are functional, solving a user’s pain point, and are scalable to reach a wide audience. In the product development cycle, one of the challenging aspects is to know when to start the collaboration with the Engineering team. While the lessons and principles I have learned have helped me effectively work with the engineering team, some of these were hard learned.
The role of Engineering is not just to write code. The Engineers and Product Managers are solution partners. This mindset may not be easy to cultivate but is an important one in order to build the right product and ship at the right time. There are three effective tactics to become solution partners.
Establish a clear and shared understanding of the problem to be solved and goals (the Why and What)
Collaboration is most effective when it starts early on. There’s truth to the commonly known phrase “Product Managers own the Why and What, while the Engineers own the How”. To develop the best solution (“How”), the two teams need to establish a common and clear understanding of the problem/opportunity. The engineering team’s point of view and questions can validate and ensure that the “What” is clearly defined. Their system and technical knowledge are valuable. The perspective they bring can inform us of the viability and the size of the task. Considering the initiative that Christine talked about, the goal to provide payment relief to affected businesses (customers) was clear and non-negotiable, but the payment structure design and tools to be able to aid customers while maintaining unit economics was a collective effort. If the Engineering team had not been part of the ideation process, it could have been a much longer exercise in coming up with the right solution (“What”.)
Recognize and work with the constraints
Considering the pace of macro-economic changes in 2020, we had to develop solutions under definite time and resource constraints. Not only did we have to act fast but we had a limited number of team members. Hence, the effort and time to build the solution dictated what could and could not be offered as part of the payment relief. The constraints forced us to think outside the box and come up with solutions that involved minimal effort to be able to help customers in a timely fashion.
Create an implementation plan
Once a problem has been well defined and understood, the next valuable exercise is to break down the problem so that the Product and Engineering teams can collectively set shared milestone goals to reach the desired state and target date. Missing this step can result in misalignment and for critical details to missed. Furthermore, this process can identify implementation dependencies and risks, which need to be addressed to ensure a successful delivery.
The three tips I’ve included below are necessary for successful collaboration.
- Start with a clear and common understanding of the Why and What
- Create shared implementation milestones
- Recognize and work within the constraints
Thank you for sharing your thoughts, Shivam! Collaboration with our business team was a critical influence in my development as a Software Engineer. It helped me add some vibrant colors to the water color painting of my role. Adding those colors also created business value for our company and made our working environment more productive. Although career development will look different for each Software Engineer, I hope this story provides encouragement for us as Software Engineers to consider how we can collaborate with our teams to find ways to use our perspectives and talents to build a better version of ourselves and of the company.