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.
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.
Being an engineer myself after a careful review of requirements which will usually take a constant shift, I used to get biased, to build my own product than using an existing one which can’t be determined its usability just by exploring it once or twice.
So what should we do? Start analyzing from - Business & Tech point of view
- Naming is important and simplifies communication. So, group the requirements and name them.
- Categorize them business vs technical. Start with business use-cases and then come up with tech choices. Example: Build a marketing product. Usecases: reach people through various channels and collect responses for further fine-tuning of your campaigns. Tech choices: Java, Spark, Data, Typescript technologies. These tech choices are generally derived from your’s and your team's skill set.
- Draw a triangle. Left adjacent has the steps of business use cases and right with tech components, these are not sorted priorities. The centered fold line represents the timeline.
- Connect the dependencies from business usecases to tech. This action eventually results to identify the priorities.
- Using the existing products in the market, cross-check and start simple POCs with the business usecases. These POCs should be aimed at analyzing a) Product Efficiency & its Scalability, b) Product Reliability & its Performance, c) Product’s data security, bugs and their response time to fix, d) Skill, Training, resources needed to meet the timelines, and finally e) The Budget with its licensing cost. Depending on the product type you may even need to consider f) SaaS, g) Cloud Adoption, i) Product limitations & eventual impact on accommodating the future business usecases.
Situation #2: Working with Vendors
Starts great. New people, all smiley faces around.
- When there are timezone differences — wastes a lot of development time if the communication is not crystal clear. Example: As a product owner writing just high-level acceptance criteria will lead to misunderstanding. This criterion must be in bulleted points for each business executable and preventable action. The positive side of it is running the development around the cloak. This depends on the people who feel responsible and enjoys their work.
- Expectations and turnaround times need to be documented ahead before the project starts.
- Find the responsible offshore & onshore leaders who will work across the time zones as bridges. 4 hours in the client timezone and 4 hours in the vendor's timezone. These people are critical for project success and require to set clear goals. Have always a backup for these resources. Actions and deliverables from the vendor will speak the operating efficiency and communication happening through these people.
- Conflict Resolution: Take the actions to build a good relationship between team members and to understand each other, working together to build a product with a common vision. Create fun events or Kahoot across the teams that can help build awareness. Conduct Chai & Chat sessions just to talk about life and its value other than the work. I used to tell a story with a few puzzles to solve.
- Establish pre-planned sessions where teams review together themselves whether they are meeting the goals consistently or not rather than leading and deligating these review powers to only some individuals.
Situation #3: Risk
Everyone & Everything: When a team wants to do everything in every area right from development to support — This will lead to stress and misinterpretations as someone else will do something else by not knowing who is doing exactly what. Many-to-many communication models demand and consume more time than needed, which can be saved in a one-to-many. Divide the responsibilities, ownership, and accountability is important and reduces the unknown(s) impacts proactively.
- Identify the risks early. How is that possible? Skills, resources, hiring, resource consolidation, organizational processes, always changing security adoptions, dev sec ops, Product owner/business folks co-ordinations, shifting requirements, re-planning, etc., we can sense these signals as the interactions are going higher. Keep in touch regularly with all the parties that are involved in the project’s ladder up and down for early observations.
- Prioritizing the risks: Our commonsense tells us, risks that have a high impact on the project need to be accounted for first to work on. It can be technical architecture design or can be resource limitation or can be the missing skills needed. As an example, a reusable component in the product might need to be built first, which helps product advancements faster. At the same time, your business may not admit its value and lead to a conflict. When such reusable components are not prioritized, such risks complicate stuff down the line and create an eventual impact on the product to decelerate the other lined functionalities and duplicate the efforts right from code to human resources. Identifying and Educating such risks early is crucial for product success.
- Accountability of the risk: Whether these can be risk addressing tasks or business tasks, we always need skilled persons to address them. Various kinds of personalities are good at various tasks to deal with. Identify them and convince them to take ownership. Every risk should be seen in a positive way and communicated to all the teams. Being transparent and presenting on how we handle such risk will boost the confidence of helping hands.
Continue Part #2.
Find other articles @ my publication: ThinkSpecial