Software engineers in many tech companies have two growth tracks - Engineering Management and Individual Contribution. At a very high level, managers take care of their team members' career growth, matching tasks to skill-sets, performance reviews, and planning among a long list of people-related activities (some companies have more hands-on engineering managers, but that is besides the point of this blog). Individual contributors, depending on the level they're functioning at, take on various technical tasks like architecture & design, coding, code reviews, dev-ops tasks and on-call support. It is a common belief that Individual Contributors' jobs only need technical skills, and you only need people skills if you're a manager. This belief is sadly reinforced by representations of software engineers as anti-social nerds in popular media (think Silicon Valley, The IT Crowd). They don't have many friends and don't know how to interact with other people in various social situations. After all, programmers only need to interact with computers, right?
Wrong. Software engineering is a job that requires several interpersonal skills. These skills become more and more important as engineers become more senior. Let's take a look at various aspects of the job that require them:
Knowing what to build: we don't code for the sake of coding. Ultimately the solution we build needs to solve a real world problem. To know what to build, us engineers need to empathize with our users and understand the issues they're facing. "Just tell me what to build" is an attitude engineers cannot afford to have. Gaining this deep understanding of user problems requires engineers to ask users the right questions - a task requiring strong interpersonal communication skills.
Code /Design reviews: When we review our teammates' work, we directly communicate with them in the form of feedback and questions in the comments. Constructive and non-confrontational feedback, preferably with examples, works best.
Blameless incident reviews/retrospectives: After a production issue is mitigated, the team should run an incident retrospective meeting to possibly understand why the incident occurred. Communication in this meeting should be carried out carefully, so as to not blame team members for the incident. Instead, the focus should be on making the systems more robust, with the aim of adding human-proof safeguards to avoid a repetition of the incident.
Contributing to the growth of teammates: Growth of team members is not just the manager's responsibility. The team's senior engineer also has an important role to play in it. The senior engineer should be able to share knowledge about the most complicated concepts, processes and systems in simple language that everyone can follow. This demands both empathy and strong communication skills.
Influencing (without authority): Quite often, senior engineers need to convince other people of key decisions. For e.g., convincing the customer/senior management to cut project scope in order to be able to deliver a high quality product. This is challenging because it often involves communicating technical details with non technical stakeholders.
Building team culture: Finally, senior engineers play an important role in defining the culture of a team. By communicating in a transparent manner and welcoming feedback, they can build a healthy team where everyone is comfortable to ask questions and challenge each other's opinions respectfully, regardless of their designation.
(This is by no means an exhaustive list. Comment below if you can think of more!)
I'd like to conclude by saying that software engineering *is* a people-oriented job. We should be investing equally in technical and interpersonal communication skills if we are to truly excel as Individual Contributors in technology!
Software engineering is a team sport and too often many of us miss the value of learning to Influence without authority.