In college, professors regularly told us that in the real world, we need to be able to work in groups. As a young skeptical undergraduate, I naturally rolled my eyes every time I heard this. Most of us hated group projects. More often than not, people would go missing or not do their part with little to no consequence.
After nearly five years of reflection on my college learning journey, I realize that while my professors were right about group work being important in the professional world, they were wrong about the way we go about working in groups. Instead of teaching us what is commonly called group work, I’ve found that honing my soft skills has best served me in group project settings.
Google defines soft skills as, “Personal attributes that enable someone to interact effectively and harmoniously with other people.”
Group projects in university teach us about scrum and agile principles—the concept of creating tasks and delegating them with everyone on the hook (to a certain degree) for the delivery of the project. It’s very clean, it’s very simple. It’s almost like a business contract; there is very little human emotion involved. It’s entirely possible to successfully deliver a project while being completely disgruntled at your team and the process.
I’ve found that being forced to “learn” group work skills often leads to it being devalued as you leave school and step into your first professional role. This is ultimately detrimental over time, as soft skills are vital to successful engineers (especially as they become more senior).
When I joined LinkedIn right after graduation, I knew it was my role to help build reliable infrastructure. I instinctively had an “us versus them” mentality with developers. Over time (and through several unfortunate experiences), I realized that this doesn’t actually work: I found myself in need of building some non-technical skills.
Unfortunately, the “real world” is not cut-and-dry business transactions, as I came to learn. Saying “no” to developers and then asking them for things that site reliability engineers (SREs) consider sensible just doesn’t cut it. You have to be able to effectively communicate with others. Over the last five years, I learned a few soft skills can go a long way in working with others.
Empathy
One of the greatest traits you can have as an engineer is empathy. There’s a great quote from theologian Ian McLaren, who said, “Be kind, for everyone you meet is fighting a hard battle.” As invincible as we think we are, at the end of the day, we’re all human and it’s easy to forget that. Co-workers may have family or personal issues that they don’t speak about, or they may struggle to understand a concept. Empathy can help you better communicate with others. Approaching your colleagues with a kind tone rather than a grumpy or aggressive tone goes a long way in building a harmonious work environment.
During university, I had a team member in a group project who was not able to fulfill his commitments by the required time. My immediate reaction was to let him know I was upset at him. Little did I know that his wife was ill and he was struggling to keep up with his study commitments. My frustration toward him didn’t help the situation and, given the extra context, is actually insensitive. Asking your peers how you can help them is far better than lashing out when things don’t go according to the plan.
Clear Communication
One thing that struck me as an engineer is how many disagreements are based on communication failures. This includes assumptions, misreading intentions or not being specific enough with asks. Many of us work in poor-quality conference calls and text-based conversations. It’s very easy to lose context and intent in digital communication and equally easy to disagree because something wasn’t as clear as it was intended to be.
Part of my role at LinkedIn is to review all site issues on a daily basis and ensure that we’ve addressed all concerns. When raising these concerns (usually during a phone conference), good intent can be lost quickly. Over time, I learned to ensure that my colleagues understand where my concerns come from and offer support to resolve any outstanding questions.
Very simply put: Over-communicate. Make sure your tone and intent are very clear to the recipient and be sure to add as much detail to the feedback or request that you’re making.
Humility
One important thing I’ve come to learn is that, as SREs, we are expected to have all the answers; after all, our job skills are multi-faceted.
Over the last four years at LinkedIn, I’ve worked on many different teams, from the traffic stack to the database platform, and amassed a wealth of knowledge on how those systems work—to the point where I could almost be considered an expert for all of those pieces of infrastructure. Naturally, people come to me asking questions about these subjects and unfortunately, I don’t always have all of the answers. It’s very easy to end up in an imposter syndrome position where you feel inadequate because you don’t have the answer to every question.
This is actually counterintuitive. While great engineers have a solid understanding of the infrastructure, tools and teams around them, the best engineers will learn who the best subject matter experts are and will direct relevant queries to that person.
This becomes a critical skill as you scale as an engineer. If 30 people are coming to you asking you about things that aren’t in your subject matter expertise, you can get slowed down and may not be able to give the best possible advice, effectively slowing the person asking the question. Knowing when to refer someone and whom to refer them to is part of being a great engineer.
Mentorship
The general career growth chart for SREs roughly looks like this:
- You do toil tasks
- You work on projects
- You lead projects and delegate to others
- You invisage projects and ask people to lead them
- You create a team or company vision and get groups of people to lead them
As you become more senior, your role becomes less dependent on day-to-day execution of toil and more focused on empowering those around you. You become less directly in control of the outcome of a project and your success comes from the success of those to whom you’ve delegated. This is where soft skills become important.
Over the past two and a half years, I’ve been lucky to have a mentor who has helped my personal development. He has been a great role model, especially in teaching me how to lead and influence others. He has often said to me that you need to break through the eight-hour barrier. What he means is that you need to up-level those around you so that your impact on the business goes beyond just your work. Your contributions are also to others to whom you’ve scaled your knowledge and skills. As well as technically leading my team, I have the privilege of being a mentor to others at LinkedIn.
These four skills are just a small set of a large base of soft skills. Mastering each of these takes time and practice, but ultimately makes you both a better engineer and person.