Building your culture: 5 things to get right first

BLUF: “If you need to motivate people, you’ve already lost the battle.” – @neil_killick

I have made previous posts about culture being a very important part to your recruitment and retention.  I cannot stress enough about how culture will make or break your team.  Before going out and hiring a bunch of people build the culture to create an incredible atmosphere that teammates want to come back to everyday and not dread work.

  1. Business values
    What is your mission statement and what type of values do you hold true in order to provide the best service?
  2. Benefits
    Don’t just look at 401k, medical, dental, vision, long term and short term life insurance.  What are things that you do to make sure you stand out from the crowd?  New Macbook Pro for each new employee with a buy back program, birthdays off, open work hours, etc.
  3. Office fun
    What are you providing at the office to promote team building?  Scotch tastings, Homemade BBQ, Mariokart tournament, etc.?  The best team building event I have seen to date is my company hosting Extra Life Video Game Charity.  It wasn’t what everyone wanted to do, but got a lot of people involved because the owner’s knew what there company culture was like and what would take it to the next level.
  4. Career growth
    Provide a path for junior a mid level employees to build their career.  These employees are going to be contacted a lot and if you are attempting to hold them back to save a few bucks, then you will quickly see them exit stage left.  If you don’t have the space for promotion, then sometimes salary will ease the pain, but it won’t always work.
  5. Projects
    Believe it or not people care what they work on.  Software engineers don’t want to bounce around between different tech stacks.  If their resume says C# and MVC don’t assume they are ok with ASP.NET Web Forms.

Building a good culture is a hard thing to do.  In my opinion it is about as hard as finding the right idea or better mouse trap, but without it it will be difficult to maintain a consistently strong team to lead you through all the struggles.

Know your team more than just as workers

Everyday you have the opportunity to engage with your team members. During these times you have to take the necessary time to go beyond the “shop” talk with them. Your team members care about things outside of work. Whether you like it or not they have a life outside of work whether you email, text or call them after standard work hours.

I have never asked my teammates to work more than 8 hours a day. My job is to provide a culture that makes them want to work more than that because they enjoy everything about being at the office or whatever they call their desk. If you go back to the definition of leadership it is convincing others to do what you need them to do.

Your teammates need more engagement from you than “What work are you accomplishing today?” Ask how things are going at home, with the family, side projects, etc. These Moments gain you a leg up in your relationship with your team. It shows you care about them and they aren’t just a cog in the machine. Take the time to find a lunch to get individuals out of the office and talk to them outside of the office walls. Heck, take the team out. Exiting the office walls opens people up to tell you what is going on. They will tell you about things inside and outside the office.

Here are some options to get closer to team:

  1. Individual or team lunches. This is a classic way to get on a better foothold with your team.
  2. Side projects. Encourage your teammates to pursue other work. This will get them involved in other technologies and learn more. Sometimes they need to get outside of the team to learn and ultimately they will bring back what they learned to the team.
  3. Career progression. Find paths for your teammates to pursue their career.
  4. Family. If they are willing to share, then learn about what’s going on with their family and follow up with them.
  5. Hobbies. Work is not a hobby. Find out what they do to find a common ground or know what they like for conversation.
  6. Let them talk. People want to talk about themselves. Let them know you want to listen to it. Ask them questions and listen to the answers.

Ensure that you have outside work relationships with your team. This doesn’t mean hanging out with them after work, but learn what they do after work or what is going on in their life that affects their work.

Punishing all because of one

BLUF: You will become quickly disliked if you are taking out one’s punishment on the group.

If you have ever seen Full Metal Jacket, then you remember a scene where Private Pyle is soap beaten by his platoon because they kept getting trouble for his mistakes.  It is common, especially in military, to ensure everyone suffers for the mistakes or problems that only affect a few people or one person.

In the corporate world we have a very succinct breakdown for business organizations.  You can find the same thing in the military.  We have organizational control called detachments that have 1 or 2 personnel from many organizational structures that make up the entire small detachment.  This can include pilots, maintainers, medics, fuelers, and cooks.

This past weekend the entire detachment was being held accountable for 2 person’s tasks that were not complete.  They weren’t complete because of inefficiency, they were just taking longer.  Because they were not complete the entire detachment was being held up even there was nothing that they could help out with.  This is like holding everyone responsible for HR’s pay period responsibilities and no one can leave work until they are complete.  Punishing everyone for the “faults” of a few is no way to instill a great culture in a business.

You have to understand the other side of the coin on this.  The point to punishing everyone for the mistake of one is to show that we are a team and we need to ensure everyone is doing what they are suppose to do in order to have the most efficient work.  You have to use the common sense meter to determine what is overboard in punishing everyone for an individual task.  This is a step in providing a great culture for people to want to be a part of.

Own It

BLUF: Get your team to own the work and increase the productivity.

Communication and information flow is obviously an important part to building a great team.  In order to drive that information flow you need to understand the start to end process of how the process works.  Where does the business process start?  How far do you need push that information down?  You also need to provide that filter to push the right information to the team that empowers them to be productive.

Keep your team involved in understanding of the business processes work, so that they understand as much as possible to keep them informed of proper information.  This process will help ensure that vacating your position or going on long vacations allows the team to continue with the productivity.

The counter argument is that filtering everything might keep them in the dark about certain information that could be clues to keep them more informed of certain situation.  This becomes a balancing act with the teams productivity.  If you pass down unfiltered information, then you can overload team members with information that they need not worry about.  Now you have inhibited their productivity from full potential.  So keep the hims and haws from around the office away from your team, and allow for a higher morale on your side of the house and out of the office politics.

Build team value

Passing around the correct information and showing your team how they fit into the puzzle and proving the value that they are creating will engage them in the work.  This will cause a greater degree of ownership amongst the team.

Encourage creative thinking

Don’t turn down communication opportunities with a team member that comes directly to you.  This will cause them to never return to you for conversation after a few attempts.  Sometimes these conversations present better solutions or opportunities for advancing productivity.

Get your team to own the process for product delivery and get them to engage through every part of it.  Ensure that communication is able to flow appropriately.  This is just a small piece to being able to deliver on time.

Normalization of Deviance

BLUF: You must maintain standards in order to drive projects to the right place.

In January of 1986 Challenger launched and shortly after succumbed to an explosion.  It was later found that an O-ring caused the explosion and they later learned that it was a set culture to accept deviation from the norm.  All actions pointed to an almost certainty that Challenger was not going to make it.

Dr. Diane Vaughan wrote about this situation and coined the phrase normalization of deviance.   It is defined as “The gradual process through which unacceptable practice or standards become acceptable. As the deviant behavior is repeated without catastrophic results, it becomes the social norm for the organization.”

Normalization of deviance is a widely known problem in many areas, but most obviously in aviation because of the safety aspect that encircles the aviation industry.  You can accurately chart a timeline where safety violations occurred prior to a major safety accident that was either major damage to an aircraft or a person.

In software an example would be that you continuously let teams or teammates manually deploy out of cycle to fix bugs or when you let a merge occur without unit test(s).  You continuously let this occur and you eventually do it yourself without fixing or adjusting the problem.  Eventually you don’t notice the problems and every merge request continuously becomes worse along the way.

I recently admitted to exactly this problem.  I was allowing the team to commit merges without the proper merge request process where we need two developers to review the merge requests before a merge can occur and you also need to write unit tests.  I let these slide because the timeline was quickly approaching and for 2 months I didn’t adhere to the process.  When the deadline passed and we had some leeway in our timeline.  I recaged everyone’s expectations to know that they need to have 2 other teammates review the merge request and ensure that unit tests are written if needed.

While you are working through a project and if you are looking at team trends through after action reviews (AARs) or retros.  Plot the bad things that happened and track your team trends to find the violations that could create a damaging issue in the future.  Take the time to exercise on an issue that already occurred to see if you can find the precursor events that you could have changed before the event occurred.

Team Advocacy / Assertion

BLUF: Any team member needs to have the ability to call out any issue without fear of repercussion.


Advocacy is the act of supporting a policy or cause.  You advocate for an action to take place by announcing it and not waiting until the error has occurred to give the big “I told you” speech.


Assertion is the act of give a forceful statement of belief or fact.  You assert your knowledge by announcing the problem that you know exists.

Before every flight that we take as a helicopter crew during our crew brief we discuss advocacy and assertion.  In order to provide others that are not able to manipulate the helicopter to do something their only recourse to a problem or situation is to announce that something is not right and provide the solution if available.  Sometimes what saves a helicopter crew’s lives is one simple act of speaking up to say something is wrong.  The rest of the crew’s job is to acknowledge that it was said and either discuss the solution or announce the corrective action that is being taken to resolve the problem.

In a helicopter if you don’t speak up when something doesn’t feel right or act right, then a serious consequence can occur; 4 people die.  Before a fatal problem occurs or the helicopter is destroyed or incapacitated a crew member has the right to prevent a problem if it is known.

Any team member needs to have a right to speak up and announce that there is an issue before the problem persist and eventually causes blockers or timeline delays.  This action of announcing the issues sets an expectation and alerts the rest of the team to a problem before it starts to snowball.

If a leader does not allow others to interdict these problems than a culture is created where the team lead has to see all the problems for him/herself.  You are not taking advantage of others on the team and utilizing all resources to take action on problems.


Let others announce problems or issues without repercussion and you will have greater aptitude to be ahead of the curve and set the right expectations for the project timeline rather than waiting until it is too late to resolve issues before a release.

How to attract talent, hint, it’s your culture

BLUF: Build a culture that attracts the talent you want.


Provide a package to attract and keep the right talent.  The benefits package gets people in the door to make them excited about the opportunity, but it doesn’t always keep them there because priorities change.  This is a delicate balance.  I have seen pet insurance coverage, college tuition reimbursement, family leave, etc.  These are great but what if you don’t have a pet or don’t have time for college.  There are some benefits that are great for some but not for all.  Here is the biggest thing, if you say you have a benefit, then honor that benefit.  I have been a part of a company that touted that they sent developers to conferences and professional development courses, but they never approved any of the requests.  We had 100% turn over in less than 2 years for a team of 11 developers at that company.  Not because of that one issue, but you can imagine what the rest of the culture was like.


When interviewing candidates make sure you are giving them the correct information and not the smoke and mirrors to get them to accept.  If you have problems, then put them on the table.  I don’t like wasting my time on a company that told me one thing, but then I saw the truth and it was nothing like what they provided in the interview.  The interview is your first step to setting up your culture with a no BS information session.

The opposite is true.  If the candidate does not meet your culture needs and characteristics, then don’t hire them.  Your culture is what makes people happy and keeps people productive.  If you hire someone that injects their own culture and doesn’t fall in line with yours, then you will see the change.


Set your culture expectations from the start.  Have new hires know what the culture is with everyone operating the same and instituting that knowledge across the board.  You will not always be around, but you want your team to embody the culture that you need to accomplish your mission.   There is ownership in this.  It is not just your team.  It is the team.  The team members have as much ownership in the final product as you do.  You need to present that way to them and show that you are doing the same thing and providing the same day to day work ethic and culture characteristics that you expect out of them.


Build a culture that provides champions.  The strength and scalability of your team/company lies in the fact that you have culture champions.  These are the people that follow the culture rules and institute it without being authoritative.  People get on board without being persuaded or forced into the culture.  If your process was fully engaged, then by this time you attracted the talent with the right benefits package, you hired the candidate that had the right characteristics and skills, and the employees are part of the team and understand what it means to be a team player.


Culture is what makes people jump when you say jump.  Culture is what makes people listen to you and perform when the days happen that you need someone to work until 3 A.M. to get the deployment done for release.  Don’t take advantage of people’s time because you failed as a leader to plan and execute tasks well.

A couple books to check out is:

Radical Candor by Kim Scott.  Kim explains how honesty up front keeps people happy.

Team of Teams: New Rules of Engagement for a Complex World by Stanley McChrystal

Culture eats strategy for lunch – Peter Drucker

Entitled Developers

BLUF: You have to try.  You cannot not just play the part and get a job.

Last post I talked about interviewing candidates with a simple, or what I thought, data structures problem.  Since starting to be involved in the interviewing process I am noticing that there is becoming a staggering number of candidates who think that they can ask for high salaries and do minimal work to earn that salary.  I have only hired 7 candidates in the 80+ phone interviews that I have performed over the last 2.5 years.

Should a candidate who asks for $120k a year in salary know the difference between static and instance fields?  Yes!  I get that some people think white boarding a problem is a waste of time, but a simple white boarding problem has a lot of information about a person.  Can you communicate your code?  Can you implement with minimal instruction and ask questions to get to the end?  Can you even code at the foundation level?

The projected growth of software developer jobs, on average, is 17% in 10 years.  The industry is not being over saturated with qualified or over qualified candidates, so the need is rising but the candidate pool is being diluted with unqualified candidates for the needs of a most companies.  What’s my take away?  Sometimes you have to compromise on candidates that are not going to be the best fit because you have to deal with the delicate balance of needing the people to get the work done and the skills of a candidate.

My criteria for a candidate in all situations that I have interviewed is the need for a “full stack” developer.  My “full stack” definition is a candidate that has strong skills in one of the 3 main pillars.  These pillars are front-end, back-end, and database.  Those candidates need to possess enough understanding in the other 2 pillars to make them a compatible candidate.  I have never been looking for a subject matter expert in T-SQL or Linux, so my opinion might be skewed compared to a larger software development firm that is building a product backed by a team of 50 front-end, back-end, data, big data, UI, UX, QA, QC, testers, technical writers, scrum masters, and product owners.

I perform at least one task for all those positions in a week’s worth of work.  As I have always said though, this causes me to be dangerous enough to get me in trouble.  There is a balance in my work that keeps me up to date with what is going on in the industry, but i try to stay focused on one piece and that is web development.  I have pet projects in mobile development but my 40+ hours a week are dedicated to the former.  I have also mentioned that I always try to do an interview or two for a well known software or product company each year.


If you have been in the industry for a while and cannot write a NodeJS application, then you might be out of touch with what is going on.  I am not saying you need to be an expert, but do the “hello world” example to get an idea.  Out of the need for NodeJS we are now seeing WebAssembly coming on with full force.  I’ll counter this with that there is always a need for legacy coders that need to upkeep an old code base.

Extra  Yes, they exist.  I think this list points to all of the most common things that a faker will do, but they only need to exert one of these characteristics for you to realize that it is a problem.

I thought it was a simple interview question

The last two jobs that I have had I have experienced numerous interviews where I am phone screening and performing face to face interviews with candidates. These candidates are anything between a brand new graduate right on the job market to engineers with 20+ years of experience. I have read the articles and I have come to move away from the old way of thinking that says experience on the job relates to how good you are. It is just not true anymore with all of the libraries, frameworks, SDKs, devices, archi… . If you are still doing COBOL and only COBOL are you worth anything? Yes. Someone is looking for your skills.


If I ask a candidate “How do you store a list of integer values?” (don’t judge, this is the first question I ask) most of them respond with a common answer – List (note: I interview for C# and Java positions). Not that this is a wrong answer, but is it the best answer? I have only had one, count it one, candidate out of 100+ give me a very thorough answer that hit all the points you want any candidate to know if you are lucky. If I had my choice between arrays and lists to store integer values, then you have to start asking questions. Can you sacrifice direct control of the array and hand it off to a list? Do you have a finite number of integer values that need to be stored? Is there any reason for optimization? In most cases the right answer is List, but from a computer science foundation the answer is array. The next question is “What if I only wanted the unique numbers from the list of integers?”, survey says! The top answer – “Iterate through the list and check to see if it already exists.” Whomp! Whomp! I have only been in this industry for 8 years now, and I have 10+ years experienced engineers that don’t know the common definition for a set/hash table and how it works from a high level. I am not sure where the void is? Did you just look at blog sites on how to use syntactic sugar to create websites and then call yourself a web application developer on your resume? I am really lost on this. The weird part is that they know the answer for the map question more times than not. A map uses the concept of set as an internal data structure!


1 – LAZY

No need to explain. You just don’t care enough. In the Army we call that an oxygen thief.


Ok, so not everyone can keep up with everything. So you do what you can.


Self explanatory. You went to the Ruby on Rails bootcamp to learn how to be a web developer and now you want $120k+ in salary for spending $5k-$7k on an 8 week course. I can see the debate here if you are applying yourself to learn the intricacies of what is going on under the hood. I might have gone the bootcamp route myself if I had the same passion I do now that I didn’t back in college. I can self reflect and say that I had no idea what I was doing in most of my classes and somehow just made it work so that I graduated. The optimism is that I would have failed out of college more than likely had I pursued any other major.


Are curriculums lacking to teach data structures and algorithms properly? I can’t imagine that is true. My university had a course specifically for each of those subjects. These are must knows, right?


Where I currently reside there is an inflation in what software engineers should earn in salary for their job position and performance. If you don’t know the difference between an array, set and map, or you cannot answer basic questions around that concept, then you are a no to hiring. If you can somewhat answer them, but then you tell me you want $130k in salary, then you are an absolute hell no to hiring. Your experience of 20+ years doesn’t mean crap to me if you cannot answer collegiate level questions. If you are the next startup co-founder about to make millions, and you can’t answer these basic questions, then you are hacking it to the top.


If you have made it this far, then I can tell you that I am not the best software engineer out there. I failed miserably on a Palantir interview 4 years ago, which led me to be better about what I am doing and learn where my voids are. I failed on several technical interviews since then, and it help me refocus again about what my next steps are and it is also embarrassing so it reinvigorates my passion for this stuff. I say all this because I think people need to do technical interviews in order to find their weaknesses. If someone doesn’t want to hire you, then find out why and figure out a pathway that fills that void that was discovered. Furthermore, I would gladly hire a high school candidate that can prove he knows what he is doing and pay him the salary that comes with that knowledge. Yes, there will always be years of experience taken into account because that’s how business works. If a high school graduate can create an awesome web application and architect third party services to boot, then he is getting paid, but I don’t expect him to be a tech/team lead. There is still a business understanding that most young candidates don’t know the ins and outs about. This business understanding is where you move from being tech savvy to a business enabler. Can I rely on you to have the best interest of the company in mind when you say no to new features or delay the product timeline for unforeseen blockers.

Accept Failure and Learn

BLUF: Failure is not a purposeful mistake, but you need to be able to learn from those failures.

No matter how much you plan it will never be perfect and sometimes failure is an outcome.  I have failed.  Too many times than I can count or even care to admit probably.  I probably would not be where I am today without those failures.  Every failure I had I came back stronger from them.

As a leader you have to know that failure is always a possibility, but how you respond to those failures is what makes you a leader.  If you become the one who turtles into your shell and cannot rally the troops, then you’ll lose the team right there.  You can be pissed off, sad or disgruntled about what happened, but your attitude cannot resonate that same tone in front of the team.

If you do fail at a task or project.  You have to be able to look back on it and make things better.  Answer three questions.  What was suppose to happen?  What did happen?  How can it be better?  You also have to be able, at a minimum, to provide 3 positive things that happened and 3 negative things that happened to help lead into your answers.  I have been a part of or used this procedure for my entire 16 years of experience in the military.  The outcome from this process is to learn from our mistakes and update the process, plan or procedures next time that allows for a better outcome.

In the military there are tactics, techniques and procedures (TTPs) that are built from learning from past events.  “Doing the same thing over and over expecting different results.”  You cannot apply the same procedures to the same problem every time if failed already.  It WILL fail again.

There are times at which you have to lean on team members to help get you through the hard problems.  Without being able to lean on others to complete the tasks, then you can definitely accept failure.  The best part about utilizing your team and failing is that you did it together.  The worst part about failing with a team is either you do it alone and you are the sole loser because the team knows they didn’t play a part or you blame the team for actions that you had control over.  If you are delegating appropriately and not asking for the moon, then you have given it your best shot at completing everything and you have to accept that and learn.