Stories on social capital in the workplace

Identifying what is and isn’t important in the workplace is very hard. As a software engineer, we are confronted with what you should spend your mental energy and focus on every day. Does the system need to be optimized? Is there a gap in our data? Is the issue resolved or does it need to be escalated? Do we need to spend engineering hours on a request (demand?) from another team?

These questions are obvious to us because they’re at the forefront of our minds and directly impact us, our work, our efficiency, and our deadlines. These questions all have to do with us and ourselves. However we rarely think about how our actions impact our coworkers and leadership day to day and what the net cost of that action is.

Identifying how to spend social capital is even harder because we not only need to identify what is and isn’t important, but also if the cost onto coworkers and management is worth the price. Social capital questions look something like:

• Am I asking my mentor too many questions?
• Am I nitpicking and dragging out a meeting on a design doc that will work regardless?
• Do I cut someone off that’s nitpicking and dragging out a meeting?
• Is my team offloading too much work in one area onto another team? What are the downstream effects of others given my actions today?
• Should I greet my coworkers when I enter the office?

Social capital is the basic idea that we are in a marketplace of social interactions. In some interactions, a person might gain social capital and in others that person may be spending social capital for some kind of non-social payoff. You could look at each interaction as a transaction on your social standing with a person or group of people, but it’s entirely possible that the game isn’t zero sum. That is, both parties could gain social capital and both parties could lose social capital and the social price and non-social payoff could vary wildly.

Whether we’re conscious of it or not, our brains are constantly making calculations on social capital. An easy to see example of this in action is something every new employee who is being onboarded to a company has experience in: asking questions.

It’s expected that as a new hire we are going to ask questions to learn tooling, systems, and codebase for a few if not several months. In fact we should take advantage of this time period when it’s expected. At the same time, as a new hire we don’t want to annoy our coworkers and new team members every 30 minutes with a new set of questions, because we know your teammates have their own set of tasks that they need to finish. We’re faced with being strategic and balancing learning on our own and identifying what we must ask questions about. In this scenario, our social capital is how we’re viewed in our competency as an engineer and the payoff is answers to our questions.

During the onboarding process, our coworkers are looking for us to make gradual improvements until we’re self sufficient. If we don’t improve or demonstrate improvement, at a certain point we’ll start burning through social capital and lose confidence from our teammates and manager. To avoid this, it isn’t uncommon for onboarding employees to put in extra hours every day because that employee is looking to retain (or gain) social capital.

Story A: The junior vs senior engineer showdown

Now that we understand the basic idea, can you identify if a person gains or loses social capital in the following scenario?

A senior engineer is having a design doc review on a greenfield API that will be implemented by an adjacent team. The design calls for the API to follow closely with a paradigm of the current system wherein operators manually upload the data into the system with Excel files. A junior engineer of the implementing team identifies this and escalates what he sees wrong in the design and proposes a more modern RESTful paradigm.

This discussion takes up the entirety of the review with the senior engineer. In fact, it puts the entire project’s implementation on pause as it spills over into several follow up meetings spearheaded by leadership that involve more and more engineers where the junior engineer and senior engineer debate the pros and cons of the design.

The junior engineer proposes their own design in a design doc review with testimony and evidence gathered on customers and consumers of the API and has it reviewed by senior engineers in further follow up meetings. Sensing a decision needs to be made and quickly, management then calls for a final meeting to announce a final decision that sides with the senior engineer’s design. The junior engineer finalizes the meetings by writing a doc to capture the final design and decisions made for the org.

Did the junior engineer overstep and burn through their social capital? With several real time days and dozens of engineering hours spent for this debate only for the senior engineer’s original design to be chosen, one might assume the junior engineer lost ground by wasting everyone’s time, but the opposite is actually true. The discussions were viewed by the organization and leadership as worthy and important that necessitated the opinions of many engineers. Gaps were discovered in the discussions and smaller decisions and their reasoning was captured by the junior engineer.

Also importantly, the junior engineer’s ability to debate with a senior engineer, research the topic, and argue their points and then quickly move on and accept the final decision was showcased to almost a dozen engineers and managers. After launch of the API and in the next quarter, the junior engineer was promoted.

But this easily could have turned for the worst for the junior engineer. Had they not been able to demonstrate their arguments and knowledge but insisted on taking everyone’s time, they could have lost significant standing. Their manager would likely need to intervene to take control of the situation. Even worse, had the junior engineer used the design meetings to flex their knowledge or demonstrate their comptency instead of arguing for what they felt was the right thing to do, it could have backfired completely to the annoyance of several senior engineers and leadership. Remember, being manipulative or having a large ego will always be communicated.

If you haven’t figured it out by now, the scenario actually happened and I was the junior engineer who debated with the senior engineer on the design of the API. At the time, I had no concept of social capital. In fact, I didn’t realize I had gained anything from the discussions outside of personal growth.

Story B: The engineer who speaks a lot and argues everything.

A common pattern I’ve seen at workplaces is that there always seems to be an engineer who tends to take time from others and argues and nits every point in meetings.

One engineer particular comes to mind. This person was extremely smart and technically strong at their level. They always had answers to questions, had strong opinions and could back their opinions and arguments, and often times had insight other team members lacked. This engineer saved their team during a few incidents where their system fell apart and had the foresight on a few designs that led to pivoting.

This engineer however also had a knack of arguing and nitpicking every fine detail, drawing out meetings with 5-10 engineers well beyond their end times. When pressed to move onto other topics or end meetings, I could literally feel how distressed this engineer would become feeling that he wasn’t heard. Too often did it feel like this engineer was in a competition to flex their knowledge onto others during a meeting or even a one on one instead of driving home a solution or doing the right thing. Their ego was fragile and sought the approval of others constantly, and what was especially challenging with this engineer was that with their behavior coupled with their strong knowledge, it was often the listener’s job to identify what was actually important and valuable insight and what was ego-driven throw away thoughts when they spoke. This forced mental energy onto listeners and frustrated everyone.

There is a multiplier effect when you take time away from engineers in a meeting. If you force a 30 minute discussion in a meeting on a topic that doesn’t need to be discussed, you can multiply that number by the number of engineers in the meeting - let’s say 8. That’s 4 hours of engineering time you’re costing the company, and if this becomes a habit, you can start eating up tens of engineering hours per week.

This is my biggest point in this story. It is incredibly easy to take time away from others without providing any value and it’s incredibly easy to lose social capital and credbility when you do. The engineer had strong insight and knowledge, but their ego held them and their team down. We must be mindful of the time we take and be sure that we’re providing actual value for others and the work during that time. We must know when a discussion devolves in value, when to take it offline, and how to take next steps to resolve an issue.

The engineer’s behavior eventually came to a boiling point. During a meeting with the engineer’s team and manager, the engineer was nitpicking every sentence the manager was saying. The manager snapped, cut him off and raised his voice, calling out the engineer in front of the team and advising him to pick and choose wisely what he wants to argue with him on because the “status quo will not continue.”

Was the manager right for raising their voice? Probably not. In this situation, the manager should have taken the engineer to the side to communicate the issues he and the team was having with him. But the engineer’s behavior wasn’t respectful of their manager or the team’s time either, and their social capital tanked not just with their manager but the team. A few weeks later the engineer was moved to a different team.

Building and spending your social capital

I want to get more in-depth with this idea of building and spending social capital in a future post. For now, the best advice I can give to the reader is that they are mindful of their social capital and impact on others. Every small and large social interaction we have with team members, managers, and adjacent teams is a transaction that can incrementally build or topple your social capital. Through this lens, we can become more effective and drive higher impact in how we collaborate in our day-to-day work.