Building things make you feel awesome, there’s is no exception when it comes to software. We all know in any software project there can be many things that could go wrong it could be having a bad process, anti-patterns, unrealistic deadlines, uncertainties and mainly which I believe is ignoring the ‘People’ factor. In a software project, there’s a team that delivers the software and there’s the customer who receives the software that addresses a particular business problem.
Even when the process troublesome or ad-hoc, when the technologies are complicated or outdated, or when the deadline is tight, with the positive and empathetic mindset you can meet the expectations of the customer, keep the team spirit, and feel the pride of craftsmanship. That’s where Emotional Intelligence fits in. I found an awesome article about Emotional Intelligence which describes the following competencies.
In the first part of my article, I will be highlighting the 3rd and the 4th competencies of Emotional Intelligence which I have applied in some of the projects I have worked in. In any software project, there are two main sides once side which is the customer and the other side which is the team. The objective of this article is to show how both sides could be balanced effectively.
Better we treat our customers not only they continue to get our service or buy our products but also to refer our product or service to potential customers. In his book, Daniel Goleman states that in a psychological sense, the company as experienced by the customer is a sum of all the interactions with the employees. You could be working on a project that is outsourced by an offshore customer or you could be working on a project in which the software is sold directly to the customer such as a mobile app. In any context empathizing with the customer and offering the best customer experience will surely bring good business outcomes such as good revenues.
Delight the product owner
Importantly the team should maintain the trust, keep the promises by delivering on time, keep them informed even the bad news, and especially the team should make the customer feel important. So its always important to respond to their emails, slack or skype messages and phone calls immediately as possible. That way we could eliminate the anger, doubt and other negative emotions they might encounter.
There can be customers who are non-technical, so in order to have a mutual understanding between the customer and the development team technical people should avoid using technical jargon instead, they should use terms and phrases customers understand well. Instead of telling the Product Owner who comes from a sales background “Our backend is hosted in AWS lambda which can be easily scaled out” it’s better to use phrases such as “1000 users can access our product at the same time”. That way not only the team deliver value but also makes his job also easier to sell the product. Bonus!! a better rapport is also made between the customer and the company.
There can be customers who would always give very rude and negative feedback which could drain down the motivation of the team. In such situations having a professional and calm tone can be used to calm down the customer and identify areas that can be improved in order to deliver him a better value. You can start with an apology and takes some notes on their expectations and what could be improved. If he continuously changes requirements which the team finds it difficult to cope with, its always good to use various estimation methods (i.e. Planning Pocker) so both the customer and the team will have a mutual understanding about the effort (which consist of size, complexity, and uncertainty) that is required to complete a particular feature. Also in environments where requirements changes are rapid, it’s also important to highlight the risks which would occur and keep the customer informed which would improve prevent any negative consequences.
Customers love when you listen and understand them. Always ask the right questions, and collaborate with them to solve their business problems. That’s why it’s important to get them involved in Sprint planning. It’s also important to prevent the customer from micromanaging the team which could also reduce the morale of the team.
Delight the end-user
When you develop a mobile app or a website its always important to empathize with the end-user and identify their behavior and emotions (especially pain points) when he tries to accomplish a particular goal (i.e. booking an air ticket) with the application you develop. In this situation “Customer Experience” should become the primary focus rather than focusing more on the features or the technology. Methods such as Customer Journey maps, Personas, Empathy Maps, or Value Proposition Canvas can be used to empathize with the end-user in order to identify their emotional state before we develop the app using the best technology. As a result of that, the user easily gets attracted to the app, finds it easy to use for a long period and also he would recommend the app to his friends as well. The following image is an example of a Customer Journey Map.
I really like the way how Alistair Cockburn who is a pioneer in the Agile movement compares the similarities between rock climbing and software development. More than rock climbing being fun and challenging, the team should focus on reaching the top as the team with the limited resources they have, tools, and also the team should be well trained. Building software is also a team intensive activity that communication and interactions are essential, nobody should be left behind just like in rock climbing. In a typical cross-functional Agile team, there are UX guys, developers, QA everybody looks at the product from different perspectives. Because of that having a team culture where the team members empathize by listening to other’s opinions and perspectives surely give good results. The idea behind Planning Pocker in Scrum is to facilitate such thinking therefore when estimating a User Story, a holistic view is established within a team.
Keep teams self-organized
Micromanagement should be avoided in any software development team to prevent negative consequences. Among the 12 principles of Agile, one states the following;
This statement encourages self-organized teams where the team figures out how to accomplish the goals. This will enable them to best utilize their skills, experience to deliver on time which will lead to a better team and individual engagement and feel the pride of craftsmanship.
Coach and mentor the team
When the team has junior members they should be well-coached and mentored. It’s always good to identify career aspirations and the of each individual team member and the areas they are passionate about and allocate them with the related work. This will improve the engagement of each team member and increase their engagement and confidence. Later on, those team members could also mentor their fellow team members and juniors with the skills and knowledge they have acquired so they will also build their skills in mentoring. In coaching giving feedback plays an important role, which has an impact on whether the person would continue or give up. It’s always good to appreciate the good work and provide guidance and support for the areas they need to improve. If a team member needs improvement in some areas its good to listen to him and identify the difficulties he might encounter and provide them the necessary support, resources, and the knowledge for him to perform better in the future.
Once a team member masters one skill he could mix up with his peers and master the skills their peers are competent in and become an all-rounder. The key is to build their confidence, passion, and commitment. There can also be situations where meeting qualities and standards are crucial in a project. In such situations its always good to make expectations clear and prepare guidelines and checklists to eliminate doubt.
Handle outages effectively
When the system is running in the production sometimes things don’t go so well, systems could crash or serious bugs could arise. Although disaster recovery plans and risks well documented and practiced, so many unexpected or unpredictable things can occur. In such outages, the team can usually be stressed up. Stress in this situation can be both positive and negative. When taken in a positive way it gives the team a sense of urgency which gives them the optimum performance to solve the outage. From the negative side, especially when the team culture always focuses on blaming and shaming individuals that could also demotivate the individuals and the team and could impair their ability to solve the outage. Also as a leader in such situations its always a good practice to work with the team and solve the outage which not only motivates the team but also will help to take the control of the situation easily. Once the outage is sorted out its always good to identify the root cause other than finding fault on a person and plan for similar outages accordingly.
Maintain an emotional bank account
Some customers are flexible while some can be assertive who would always demand firm deadlines which the team finds it impossible to meet. In such situations empathizing with both the team and the customer can be challenging. To face such situations I use a method called “emotional bank account”. The idea behind that is to maintain an “emotional account”, whenever a good incident takes place within the team (a team outing), always deposit the account and when some negative incident occurs (such as working overnights for a week) withdraw from the account. When the account balance is low, we can do something to make the team happy. Ultimately both the team and customer satisfaction can be met.
When we sum up everything how can we put everything into practice to gain all the benefits? It’s always good to create awareness within the team and the organization about the opportunities and benefits of Emotional Intelligence. With the right emotionally intelligent mindset everybody wins!!!.
- Emotional Intelligence — Daniel Goleman
- Agile Software Development: The Cooperative Game — Alistair Cockburn
- Team Geek — Brian W. Fitzpatrick, Ben Collins-Sussman
- Scrum: The Art of Doing Twice the Work in Half the Time-Jeff Sutherland