Software Engineering Leadership — 1

Learnings from the leadership situations.

At first, our heart should say, no matter what, I want to get this thing done with my folks. Then the leadership comes out naturally without the fear of failure. Because our focus will never get deviated from what we want to get done.

Thinkstock

There are some situations I personally faced in my career and I would like to publish them from the leadership point of view.

Situation # 1: Building Products In-house vs Third-party.

When it comes to building products, the decision to go with in-house development or opt for a third-party solution can be a challenging one. As an engineer, I have found that it’s important to approach this decision from both a business and technical perspective.

1. Categorize the requirements — Group the requirements into business and technical categories, and prioritize the business use cases first.
2. Determine the tech choices — Based on your and your team’s skill set, determine which technologies align best with the requirements.
3. Visualize the priorities — Draw a triangle with the business use cases on one side, tech components on the other, and a timeline in the center. Connect the dependencies between the two to determine priorities.
4. Evaluate existing solutions — Perform simple proofs-of-concept to assess product efficiency, scalability, reliability, security, resource requirements, budget, and more.

By following these steps, you’ll be able to make a more informed decision on whether to go with in-house development or a third-party solution.

Situation #2: Working with Vendors — Setting the Right Foundation for Success

Starts great. New people, all smiley faces around. Collaborating with vendors can be exciting, with fresh faces and positive energy all around. However, there are potential challenges that need to be addressed to ensure project success, such as time zone differences and miscommunication.

1. To avoid wasted development time, it’s crucial to have clear and concise communication, especially when it comes to writing high-level acceptance criteria. These criteria should be broken down into bullet points, outlining each actionable and preventable aspect of the business. The upside of this is that development can be conducted around the clock, depending on the team’s responsibility and work ethic.
2. Before starting the project, it’s important to document expectations and turnaround times. Having responsible leaders, both offshore and onshore, who work across time zones, can serve as bridges between teams and help to set clear goals. It’s essential to have a backup plan in case these critical resources are not available. The efficiency of the vendor’s operations and communication can be gauged by the actions and deliverables they deliver.
3. To prevent conflicts, it’s important to build strong relationships between team members and foster a sense of unity. Hosting fun events, Kahoot quizzes, or Chai & Chat sessions can help to increase awareness and create a positive working environment. Regular review sessions, where teams assess their progress and goal attainment, rather than relying solely on individual assessments, can help to ensure consistent progress.

Situation #3: Managing Risks in a Project

1. Clear Division of Responsibilities: Avoid a situation where one team or person tries to do everything from development to support, as this can lead to stress and misinterpretations. Instead, it’s important to clearly divide responsibilities, ownership, and accountability to reduce unknown impacts.
2. Early Risk Identification: Be proactive in identifying risks by regularly staying in touch with all parties involved in the project. Signs of potential risks can include changes in resource availability, shifts in organizational processes, security adoption, and fluctuating requirements.
3. Prioritizing Risks: Prioritize risks based on their potential impact on the project. For example, if building a reusable component is crucial for the product’s success, it should be prioritized even if it may not initially seem valuable to the business.
4. Accountability for Risks: Every risk should have a designated skilled person to address it, and team members should be encouraged to take ownership of these tasks. Transparency and open communication about how risks are being managed will build confidence and help bring more support to the project.

Continue Part #2.

Find other articles @ my publication: ThinkSpecial