In the summer of 2018, my organization was struggling in a number of areas.  Architecture was regarded as oversight rather than aid, leadership decisions were continually being challenged, process felt oppressive to some and they were actively working against the spirit of that process, some teams were bickering with each other or, worse, using “us” and “they” language.  It made sense that there were challenges given that there were two high stress time-bound projects underway but it didn’t make the vibe feel any better.  I vowed to address each issue in an all-hands on my return from the three-week trip I had on the books.

You may be wondering why I’d take a three-week trip in the midst of everything that was going on.  My wife, Krystal, has lived with SLE for 43 years and was being hit with debilitating seizures, sometimes multiple times an hour.  These likely stemmed from a Lupus flare that started back in 2017.  Her health had steadily deteriorated for quite a while and there were legitimate reasons to believe that she would not make it.  We’d exhausted what the local doctors could diagnose and had been accepted by the Mayo Clinic up in Minnesota and so we packed up the car and off we went.  With so much time to think and talk with Krystal while we drove across the country and while we waited for doctor after doctor, all of my problems with my organization were put into perspective.  It is amazing how almost losing the person I love most in this world helped me see what actually matters.

What matters is not architecture or process or adherence to standards or any other seemingly important thing.  What matters is people and our relationships with them.  What matters is the environment that we create in which those people can either flourish or wither.  What matters is that we do everything we can to help others be all that they can.  On the drive back to Denver from Rochester, Krystal reminded me why she felt it was important that I keep inspiring my team.  She said that SendGrid was changing the way that business is done.  She said that we hired souls, not skillsets and that the kindness and collaboration we exuded must succeed so that others could see that a different way was possible.

When I addressed my organization, I let them know what I’d been going through.  I let them know that I had concerns about how things were going in the day to day at the office.  Rather than diving into the details and explaining why they needed to do things The Right Way, I shared why it mattered to me in the first place and what fundamental principles underpinned how we developed software.  And from that day, as I addressed each incoming class of new employees, I only talked about the principles — not the processes or tools or functions.  Briefly, these principles are as follows.

Ownership

Playing ‘mother-may-I’ with senior management is demoralizing.  So is giving a step-by-step  set of instructions to people who are being paid for their creative brilliance.  I have tremendous respect for the people in my organization and believe that they are the best people to make the critical decisions in their day-to-day.  If they are the ones waking up in the middle of the night when a system goes down, then they are the right ones to say what level of quality that system needs and how we will ensure that we get it.  Being an owner means it is their job to maximize the value delivered to their customers and that means that sometimes, they have to roll up their sleeves and do jobs that are unnatural to them.  This means that at different points in time they will be required to wear different hats and do things that might not be fun for them.  At times, developers will have to test, QA engineers will have to deploy, and Architects will have to train support. The end goal is a happy customer but the journey ensures an environment in which people are respected, valued, and able to grow.

Empowerment

When we expect our employees to act as owners and hold them accountable to delivering results, we owe it to them to ensure that they have enough support and the autonomy to accomplish their goals.  This much is obvious.  

What I’ve found to be less obvious, is that they too have responsibility for their empowerment.  All too often, I’ve seen employees complain about the absence of something that would help when not only does that something exist, it was discussed at all hands, announced via email, and demonstrated at a brown-bag session.  For our employees, empowerment must also mean a responsibility to fully understand not only how we do things but why that is the way that we do them in the first place.  I can understand if somebody making minimum wage flipping fast food burgers doesn’t understand all the details of how the fryer works.  It is an entirely different matter, however, when somebody making a six figure salary in a technology company building software takes a passive approach to understanding the software development process from ideation to release.  How can one have self-efficacy in such an environment without something so fundamental?  How demoralizing to reduce one’s job to following checklists rather than understanding the underlying goals and seeing the process as a framework designed to help them express their own creativity!

Indeed, understanding not only the what but the why is how individuals can make their biggest impact on the business.  If something seems like unnecessary process and is getting in their way, those impacted must raise the issue.  If it really is a valuable process, raising the issue gives leadership the opportunity to teach and to provide important context that the individual contributor might not have.  Sometimes leaders have it right.  If it isn’t a valuable process, raising the issue just might make everybody’s lives better by helping us see that we can do something better and faster.  Sometimes leaders make mistakes too. Regardless of the situation, raising the issue can be a win for the organization.  The processes and tools are there for you.  If they’re not helping, figure out why and fix it.

Assume Best Intent 

In the Summer of 2018, we had two teams whose opinions of one another had dropped so low that they had begun to resort to name calling.  It started when Team Strung Out (not their real name) was working on a project with a critical date having board-level exposure and hit a technical area that they didn’t understand at all.  Team Judgmental (also not their team name) gave them some code that could be modified to meet their needs.  The problems came when that code wouldn’t work for Strung out and Judgmental stopped helping them after the first week or so.  Within a few weeks, Judgmental was “selfish, wrote bad code, and didn’t care”.  Strung Out was “stupid and couldn’t code their way out of a paper bag”.  

In the all-hands when I came back from Mayo, I helped everybody see what was real.  Strung Out was working crazy hours on a stressful project and were very naturally getting more frustrated than usual. Their work was needed for us to hit our revenue targets in our first year as a publicly traded company and they were taking on the burden of this for the good of all of us.  When the code that was given to them didn’t work and they couldn’t get help, it fed into human emotions that were already running hot.  To hear that they were being viewed as people who couldn’t understand a simple concept was really too much.

Team Judgmental had a completely different experience.  Seeing their fellow engineers so stressed, they tried to help as best they could by giving them some code that they’d written in the hopes that it would help.  They did some initial training but then got sucked into a critical project of their own — meeting the SOX controls the SEC requires for a company of our valuation.  Failing to do so would lead to a “material deficiency” in our audit.  They had to say no to Strung Out for the good of the company.  When they heard that their code was being maligned, it was natural for them to become offended and choose to believe that the problem was the intelligence of the accusers.

The reality is that both teams believed they were doing the best they could for the company as a whole.  They probably were.  They wanted to work better together but the circumstances in that moment just worked against them.  To their credit, when they were able to see the situation from the perspective of the other, they had genuine empathy for each other and patched things up.  They met their dates and the impact of those two projects played a material role in our $3B acquisition six months later.

I shared this story with each new employee to help them see that in situations where everybody is acting in the company’s best interests and where there is absolutely no villain, it is still easy to create them.  To have the type of environment that we all want to work in, we need to resist this urge.  Start with questions and work towards empathy — we really are all in it together.  People are just messy sometimes.

Help Others and Ask For Help

It is a shame that the traditional hero-developer culture in the software industry fails to reward assists.  Every one of us coming in the door has something to teach and areas where we need to learn.  When we help one another get stronger by taking the time to step out of our immediate concerns and help a co-worker get better, it always pays back with interest.  
Since the fiasco described above, my promise to my organization has been that if, in the very rare case members of a team have a deadline so pressing that they cannot take time to help anybody else, I will make it clear to everybody in the organization so that everybody knows why they are saying, “no.”  In all other situations, it is my expectation that a request for help be met with help.  When my son, Trystan, interned with one of my old teams this summer, he gushed about how much time they were putting into him, a lowly intern, to help him understand the nuances of Go-lang.  This is how each member of a team gets stronger.  It has direct impact to productivity, engagement, employee retention, recruiting, product quality, and accelerated timelines.  So weird that it feels like something that should be put off.

One other place that the principle of help shows up is in all of the various product reviews.  I’ve seen senior engineers bristle at the idea that an architect needs to review their design.  “Don’t you trust me?”  Such an engineer has already failed at assuming best intent.  The reality is that it is always a good idea to have more eyes on a design.  That architect most likely isn’t doubting the engineer’s ability.  They have just been around long enough to have been bitten by their own bad designs far more times than the engineer.  Why would the engineer not want to benefit from all that experience when it may literally be what makes it possible for the engineer to sleep at night?  Accept the help.  Say, “thank you.”

Better Together

If we are doing a great job with our hiring, then we build teams with diverse skillsets from diverse backgrounds.  That is not enough.  We must shape the environment in which they work so that every single person feels safe to speak up in every single situation.  More, they must understand that their voice is important to us.  Assuming positive intent, asking for help, and creating a place for people to help others gets us part of the way there.  Cultivating active curiosity gets us further.  If somebody is not speaking up, solicit their view.  

Back to my son’s internship this summer, he was asked in a group meeting for his viewpoint on the estimate given for a particular code refactor and responded with something like, “I’m just the intern.”  But God bless my former team.  They answered, “but you might be looking at it in a different way that we’re not.  We need to hear it.”  It turns out that he was and they time-boxed the refactor to account for his concerns.

That’s an environment in which people can thrive.