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

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

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.

Conclusion

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.

Benefits

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.

Interviewing

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.

Expectations

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.

Champions

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.

Conclusion

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.

Conclusion

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

https://www.captaincodeman.com/2014/07/01/top-10-ways-fake-software-developer.  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.

HERE IS WHERE I START TO SHAKE MY HEAD.

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!

THEORIES

1 – LAZY

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

2 – SELF TAUGHT

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

3 – BOOTCAMPS

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.

4 – CURRICULUMS

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?

5 – JOB MARKET

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.

CONCLUSION

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.

Tasking – Edge of Success

BLUF: Give team members tasks that put them on the edge of success or failure.

Providing the right level of task to the right person is always a tough decision because there has to be thought that goes into it; time, priorities, experience, and knowledge.  Not only these definitive decision points, but also do you have the right team makeup to provide a solid foundation to solve problems.  You have to build a team that makes sense.  If you are using C#, then don’t hire the technical expert that has been building Java Applets his entire career.  Unless you have the project runway for him to learn C# first and then get going on the project, they will fail.  Either because you are pushing them to fast and then don’t have the knowledge and experience to provide productive coding or because they get fed up and leave with the environment that they are working in.

When assigning tasks out take into consideration which ones will put team members on the edge of success, but a critical step left or right could put them in a failed state.  Having team members that you are excelling to succeed, then you are doing no favors for them or yourself.  They will not have challenging work and you will ultimately have a product that falls flat.  Engage each member equivalent to their technical needs and wants as well as their experience.  Once again you have to have the right team make up to make this achievable, but that includes still be able to solve problems that occur that no one knows how to solve.  You just need the team members that are willing to venture into new lands.

It becomes a team balance to provide the best culture and environment for your team to both have technically sound and creative work that they are proud of.  You have to know when to back off on the pressure and let your team have a break.  Software engineers have a known ebb and flow in projects.  You are going to have days or weeks where there needs to be full pressure to get something done or fixed, but there has to be a down time for them after the fact.  If you don’t provide that type of environment, then you run the risk of too much stress and fatigue for too long and they start to hate the job and career.

I treat my team like they are my kids.  You have to be able to teach them and give them life experiences without dictating how to perform every task step by step.  If you start to fall into the realm of micromanaging or dictating, then either you are the wrong leader or your hired the wrong people for the team.  Take a look at yourself first and adjust to see if people will break out of their shell to provide productivity and creativity.