“Our dev culture is based on Bushido Samurai code”

Share This Post

Share on facebook
Share on linkedin
Share on twitter
Share on email

My interview with the VP of Engineering at GigSmart about their dev culture

I’m a culture nerd. Obsessed with the idea that you can have two groups of software engineers with similar talent and experience and one group might build better products than the other because of this amorphous thing… dev culture. 

I talk to 5-10 engineering leaders every week in my role at LinearB. And I always ask them about their dev culture. 

When I spoke to Chris Downard, VP of Engineering at GigSmart, about their dev culture, what he had to say blew my mind. 

I’ve known Chris for a few months. He’s an awesome guy. For starters, every time we Zoom he shows up with a different panda background.

Chris Downard of Gigsmart has built an interesting dev culture.

He took a circuitous route into software development – only falling in love with coding after getting a poly-sci degree and having a close call with law school. 

He takes his responsibility as a leader very seriously. In his Linkedin profile he characterizes himself as a builder of teams and software. Notice he lists “Teams” first. 

When I asked him how he thinks about his role as a VP of Engineering, his response was similar. 

“Build better, more engaged engineering teams… That’s probably what my actual official job description is. So culture really matters.” 

Naturally, I asked him about their dev culture at GigSmart. 

Origin Story  

Chris and GigSmart CTO Jason Waldrip wanted to find a set of values that aligned to their company values and would work for them as their team size scaled up. 

“Jason and I sat down and chatted about the values we wanted to see in our team. We both align strongly to the company culture. So our goal was to augment the engineering department with a set of values that codified behaviors that helped us reach our desired outcomes. 

Jason asked me if I was familiar with Bushido. I had heard of it but wasn’t super familiar. He walked me through each tenet and as we talked about them we started iterating on things that worked for our team. It started falling into place right away. It was a great structure for us. Be honest. Be genuine. Strive to better yourself. Assume positive intent and respond in kind.”

This introduction to the GigSmart engineering values comes directly from their internal employee manual. 

Bushido is the code of the Samurai. We believe that the virtues followed by this ancient code translate well into how we behave as members of the software development team at GigSmart. You can find the original description and virtues of Bushido on Wikipedia. We adapted some of the virtues to fit our organization. 

Watch Chris explain how they adapted Bushido for their dev culture 

This is the code we strive to live by. Study it, know it, embody it.

Dev culture at Gigsmart is based on Bushido Samurai Code

Practicing Bushido in a dev org every day 

After hearing Chris describe how they adapted this ancient code into their dev culture, I had a million follow-up questions. 

Dan: How does this get rolled out to new team members?

Chris: It’s part of our onboarding process. On your first day you meet with HR and learn about GigSmart company history and values. And then the next meeting is with me and I onboard into engineering values and the first thing I do is walk them through Bushido. 

Dan: Are there any parts that your team likes the most? 

Chris: The heroic courage is popular because we’re very “succeed together” oriented.

Dan: Are there any aspects of the code some people don’t understand?

Chris: Probably emotion vs. logic. The purpose of this principle is that there is inevitable conflict, differences of opinions, or sometimes just irrational human behavior. Our job isn’t to stop it from happening. It’s to act with empathy and assume positive intent. When we disagree on approach, we don’t fight about it, we discuss it. We encourage passion and articulation over resentment and resignation. We do our best, as teammates and humans, to not respond to another’s negative actions with additional negative actions.

Dan: Do your people ever debate you on any of these?  

Chris: The last value [self control] does not mean to be a Vulcan (nerds unite, man). We want passionate technologists engaged on problem solving and value creation. And we embrace strong opinions weakly held. Meaning when someone presents a solid foundation for why we should implement a certain way vs another, or why a thing exists in its current fashion instead of a different way.

Dan: 8 tenets with 24 bullets is a lot for people to remember… does anyone ever push back on the length?

Chris: Our people definitely can’t all recite them off hand, but the themes they can. I bring them up in retro to compliment others. I bring them up in 1-1s for coaching on how to have better interactions between people and I weave my own past failures/experiences into them and how it doesn’t align with that principle. I’m Locke-sian in thinking – humans are fundamentally good and want to have success. Product delivery is a team sport, so we want to see each other do better, we want to see ourselves do better.

Dan: How do you embed the use of these values in your day-to-day work?

Chris: I really like this quote from the Bushido Wikipedia page:

“If one does not investigate into the matter of bushidō daily, it will be difficult for them to die a brave death. Thus, it is essential to engrave this business of the warrior into one’s mind well.”

We have an important mission here at GigSmart but it isn’t life and death. And when it starts to feel that way I like to remind the team that when we make mistakes we can learn from them and move on. But I do like the idea of engraving the code into my mind each day. 

One way we use our code on a day-to-day basis is by giving praise in the context of Bushido. 

See Chris talk about how he gives praise in the context of Bushido

Dan: If you give praise in the context of your values, do you also give criticism using them?

Chris: I do. The most consistent one that gets used is “assume positive intent.” 1-1 coaching is a great opportunity to offer feedback in the way of “You’ve expressed frustration or difficulty with this pattern of behavior. I will work on helping you improve the areas you aren’t in control of to help make that a better experience for you. Here’s an opportunity for improvement you could help me with to make that even more effective and will better exemplify <principle xyz>.”

Dan: You’ve mentioned the use of data being an important part of your culture. How do you decide what data is important to you? 

Chris: Merge Frequency and Cycle Time are important indicators for us right now. 

See Chris explain why he’s watching merges and Cycle Time closely

Dan: Is there a wrong way to use metrics?

Chris: You get what you measure. If you stack rank individual developers you create anxiety. 

One of the things I don’t like about getting individual statistics, like the number of commits you push as an individual developer, is that you’re incentivising the number of commits they push. Not necessarily the quality. Or not necessarily tied to the business objective for delivery. 

I don’t care how many commits they make. I care about the work the team gets done. For example, if a developer starts pairing a bunch that should not affect how we view them as long as they keep delivering value. 

Chris shares his ideas of when using metrics can go wrong

Dan: How does LinearB help you communicate metrics to your team?

Chris:

Chris' thoughts on how metrics are communicated are a good representative of the dev culture he has built.

Dan: Have you updated your values since rolling them out?

Chris: Not yet. But I have made a directed effort to shift the team mindset from being “owned” by the company to being owned by the team. That is, I very specifically and directly make it known to each person that this team is theirs. Their culture is theirs (with some guideline principles from me and the company). If they don’t like something or they don’t think something works, it’s their responsibility to change it. When it comes up initially I’ll help and coach, but they don’t get to keep bringing it up without action. They must be the change agent and develop buy-in. That not only forces them to put ownership into practice, it provides on-the-job training for how to bring about change in an organization and in small, incremental ways teaches good tenets of team leadership and collective ownership.

Culture is a river – it’s always in motion. You don’t have a culture that is one thing forever. Every time a person joins your team or leaves your team it changes. So it’s important the team has a fabric of concepts that are broad enough to align to and bring their own flourish to it.

Dan: What do you think would happen to GigSmart dev culture if you moved on?

Chris: When you think of your organization’s culture, does it survive you? If you left, will it be carried forward? Is it something you have to reinforce or will the people that are a part of it teach it to others as well? It should give your group an identity that they can use in response to situations of uncertainty. Uncomfortable code review? What guidelines (aside from being a good human) will remind me that the most likely outcome here is positive intent. A difficult deadline might need a rallying call. Struggling with automated testing? Make it part of your core identity and state clearly that you value automation and celebrate the successes.

I truly believe the greatest measure of success in implementing culture is whether is survives you. If something changed and Jason or I departed GigSmart, I feel the team would still be using the language we codified. The number of times I’ve heard from the team “assume positive intent” and references back to “compromise without resentment” is too many for it to not be part of the fabric now.

What I learned about dev culture from Chris, Jason, and the GigSmart team

Being obsessed with dev culture as I am, I think about this conversation with Chris a lot. 

What can the rest of us take away and apply to our own teams? I came up with 6 things: 

  1. Be intentional. Chris and Jason put a lot of thought and work into their values. If as leaders we don’t decide what our values and culture should be, we may end up with a culture we don’t like that doesn’t serve our people or our business well.
  2. Write it down. Themes are important. It’s what people remember. As Chris said, everyone on the team may not be able to recite all 24 points. But they can all remember the 8 themes. Once you decide what your values should be, write them down, make a poster and put it in places people will see. This doesn’t stop you from iterating later. Don’t let perfection be the enemy…
  3. Be authentic. Bushido works for GigSmart because Chris and Jason really believe it. They live it every day. If they didn’t, their team would pick up on it. The easiest way for your values to become shelfware is to choose things your leadership doesn’t truly live and breath. If culture is not embraced from the top down, it doesn’t have a chance.
  4. Share ownership. As Chris said “I have made a directed effort to shift the team mindset from [our values] being owned by the company to being owned by the team.” Yes, culture starts from top down. But it can really flourish when members of your team at all levels pick it up and run with it. Allow room for your culture to live and breathe and change based on feedback from your people.
  5. Make it sticky. Your culture can be more than an idea. If you do it right, your values can help you run your business on a day-to-day basis and become more sticky as a result:

    – Incorporate your values when you give praise and constructive feedback.
    – Immerse new people in your values early by including them in your onboarding.
    – Discuss the pros and cons of important decisions in the context of your values.
  6. Measure what matters. “You get what you measure.” If you believe software development is a team sport, are you sending mixed messages to your team by measuring individual developer productivity based on the number of code changes or commits they make each week? 

Call to action: If your engineering team values aren’t already defined, write down what you think they are. Then ask 5 more people on your team to write down what they think they are. You’ll quickly get a good sense for where you’re at. Then you can get to work 🙂 

Bonus Interview Content 

Dan: Are you doing anything special to maintain your culture now that your team is 100% remote? 

Chris: I stole this trick called Coffee Talk from Jeremy Murray, a manager I used to work with, who has a really strong remote culture. We basically open a Zoom meeting and leave it all day and our people can come in and out any time and just hang out with each other. It’s awesome because devs are getting a chance to really get to know teammates from other teams that they used to only see briefly in meetings. I think it’s one of the reasons our productivity is up since going remote

Dan: Can you give us an example of when you gave praise in the context of Bushido?

Chris: Here is an example from our #tribe-development Slack channel from a few weeks ago:

Chris maintains Gigmart's dev culture daily, in meetings and slack.

Dan: Why is dev culture so important to you? 

Chris: Your projects could disappear tomorrow and your business could completely pivot to something new. To me, two main things allow your engineering team to quickly reorient. 1) Your SDLC process being well understood and perceived broadly as valuable. 2) Your culture. Your product is gone so you can’t say look at the effects and things we’ve done with x. You fall back to “these are the behaviors, norms, and moors that fostered our success in doing that and we’re going to do it again.”

Dan: Tell us more about the man behind the panda. 

Chris: I was born and raised in Texas. I moved to Colorado at 20 and about 6 months later fell into operational management of cellular stores in the area. Ended up moving to Utah and later Nevada to do the same before going back to school for pre-law – Poli Sci degree baby! :-). As I graduated undergrad in 2011, our first child was born and I deferred law school for a year to spend time with the new family and be close to my wife’s family. I picked up a job at a company that produced HR focused software and I fell in love. This is my 3rd time living in Colorado since I was 20, but I don’t plan to ever leave again. I love it here.

My wife and I are now the proud parents to two boys (Caden is 9, Ryder is 5) and we spend all of our time focused on them and having fun. This summer our big theme is building a big pollinator garden like we had at our last home.

Italian Trulli

How does your software development team measure performance?

More To Explore

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering leaders striving to be better for their teams