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.

Getting on board: dealing with insubordination

This had a great response on Hacker News.  See everyone’s discussion/comments here.

BLUF: Sometimes you have to directly inform a team member and be explicit about expectations.  Implicit tasks are not always common sense.

Recently I encountered an issue with a team leader who was dealing with a teammate who was being insubordinate.  It was not the first time that they were being abrasive and clearly defying what was being asked of them.  How do you handle this situation effectively?  In this case they couldn’t afford to move the individual from the team.  It was already a small team and there was a tight timeline for a release.

The team lead had already documented the experience 3 times, and was not advancing to a solution.  The conversation in general went like this.

Lead: I need you to implement “X”.

Teammate: No.

Lead: This is not a choice.  I am telling you to do this.

Teammate: You need to convince me.

This is the short version of how the conversation, but suffice it to say that the teammate decided he was in control and wanted the team lead to convince why he should implement a private variable in a class.  The teammate thought it was bloat and the lead just wanted it done to finish out the pull request.  Who is right?  No one is right, but the lead has the authority to expect tasks to be accomplished when asked and has the responsibility of delivering the release on time.

I have had previous blog posts about decision making.  You have to be able to decisions with the information given.  Based on the information the lead wanted the work done to keep everything on schedule.  I call this “Pole vaulting over mouse turds.”  (<– I stole this from another colleague).  This quote is the equivalent of “shaving a balloon” or “break through red tape” except I think it is a more accurate description of how some people treat issues with a terrible solution.

All the lead wanted was a single private variable placed in the class and the amount of effort it took to get that accomplished was a multiple day discussion.  There are processes in place to get things like this removed.  If you are iterating and being “agile”, then you can remove it later realizing your mistake, and if you code it right, then it will not be intertwined into code so deep that is causes a delay.  Just write the less than 80 characters line to add the variable and move on.

The bigger issue in all of this is that the teammate did not want to comply with the lead’s request and decided to go the other direction, and not just stick his tongue out, but gave the middle finger and walked away.  Clearly exemplifying that he was going to do what he wants.  A couple of ways I would have handled this.

  1. Counsel the individual by explaining the roles and how tasks are assigned and accomplished.
  2. Remove the individual from the team before it spirals out of control.
  3. All else fails.  Move on to the lead’s supervisor.

If the individual is not a fit, then move him to another team that might have a different control style.  He isn’t a bad worker, but the relationship between the leadership style and his work style are clashing.  However, to keep the team rolling this problem needs to be resolved ASAP.  It is decreasing productivity and efficiency of the individuals and team.

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.

Trust But Verify

BLUF: You are not questioning peoples ability, but their follow through sucks.

If you have assigned major tasks to complete and the suspense has come and gone, then do not assume that it was successfully because there are no realized results.  You have to either receive a follow up from the assigned person on the task or continue to ask questions for the status until it is completed.

Continuing to ask is not a dig on someone’s ability to complete a task or treating them like a kid.  If someone never follows through with you and tells you that they completed the task and what the results were, then you have nothing to assess for further action.

Here are some easy steps to accomplishing no-result taskings.

  1. Meetings
    Create a calendar invite and add the person who tasked you on the invite.  Do this regardless if they are suppose to be an attendee.  Make them an optional attendee.
  2. E-mails
    This is super easy.  CC or BCC them accordingly.
  3. Code
    Perform code reviews or merge requests.
  4. Documents
    Google Docs and Microsoft products – turn on change tracking, Google does this automatically.

You should never think a supervisor thinks that you do not know how to do your job, but understand that they have someone to answer to as well and are being held accountable.  It is a “trust but verify” relationship that is being accomplished.  Instead of taking offense then do everything that you can to keep them in the loop on the tasks that they have assigned you.

How productive are they?

BLUF: Be ahead of the team on finding tasks and assess productivity.

No matter what development cycle you are using you have to be flexible in your taskings.  The landscape is going to be ever changing and you need to adjust your team accordingly regardless of Agile, Waterfall, or whatever hybrid or static development process you are using.

The day before make a list, written or mental, of tasks for your team members.  Take the time to apply skills and experience to tasks.  Give each team member a specific list of tasks and suspense to go along with those tasks.  It is super important that you give a task an assigned team member and a suspense date of the task.  Each task needs those two pieces of information to be successfully.  Everyone is happy to kick the can down the road if the task is not fulfilling so you need to give tasks a suspense.

If you make the tiny task list the night before you dole it out, then you can start gauging an idea of how productive your team is.  These tiny tasks lists need to be tasks that don’t last for an extended time, such as “Build an API by January”.  This task has too long of a runway, an ambiguous suspense date, and large feature task.  You won’t be able to take simple metrics on productivity levels appropriately.

I am not saying you need to drag out a spreadsheet with VBA scripts running in the background or tracking velocity.  This is good ol’ fashion feelings and best guess.  As a leader you can quickly look around and assess the good from the bad in any situation if you have some understood information.  If you cannot quickly assess your team skills at this very moment, then you are not paying attention to them or you are just not a good leader.

If you can ultimately find small tasks to give to your team and start assessing their productivity levels, then you can start assessing their talents, skills, and where they accel in their field vs. where they will struggle.  In case you are wondering, getting coffee is not a task I am referring to.  You should not be trying to haze your team, but if the tasks are within the responsibilities of the job, then by all means challenge and task away.

No Need For Scrums

BLUF: Rules are there to be prescriptive if your team needs to be told explicit instructions.

I have a team that has no problem conversing about issues, problems, or just to BS about something that is going in life or work.  Not one of my team members has ever had an issue coming to me to talk.  That isn’t me looking at the world with rose colored glasses.  They have come to talk to me about career growth, anger with other team members, benefits, and just life in general.  I am 91.1111% sure that they would come talk to me about anything if they needed answers or discussions.

I have never been a fan of the agile process, but I am in a spot where if you don’t do it, then people think you are weird.  So do we need scrums?  No.  If your team does not have a communication problem or deficiency, then there is no reason to have a scrum everyday.  If you maintain your tickets, then you keep the scrum master happy, if you complete your sprint tasks, then everyone is happy, and if no one has questions or misunderstanding, then what do you need to communicate everyday?

Our scrums are not long, 2-3 minutes on average for a team of 4 developers.  I hold to it that scrum is not for discussion.  We do have conversation bleed over into more discussion in case there are problems or issues.  The rule that is place to have a scrum everyday seems to be there just because.  A rule exists because someone needs to be explicitly told how to perform actions:

  • Holding hands when crossing the street.
  • No toys at the dinner table.
  • Do not run in the house.

These are some of the rules that my wife and I have for our kids, but these rules will diverge, change or be removed completely over time because they will not make sense or are no longer necessary.

Your team should be treated the same way as well.  If they understand what they are suppose to be doing and the rule becomes a hindrance more than a business process, then take it away.  Keep rules around indefinitely if they promote a good business process, such as, two developers need to review a pull request to ensure that code is correct, it implements the right solution and unit tests are written.

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

5 Delegation Techniques for Tech Leads

BLUF: Delegation is the best tool you have as a leader.

Delegation is the best tool in your kitbag.  But there are several things you have to do in order to make delegation successful.  In the military there is an absolute must that you have to be able to delegate in order to accomplish tasks.  The military has a clear hierarchical organization structure that allows you to manage your tasks and expect people to accomplish the mission and hold them accountable for their actions.

  1. You cannot multitask
    You are not different than everyone else.  It is impossible for you to multitask all of your duties to make you more efficient and successful as a leader.  You have to be willing to give others your work or tasks.  There are meetings, timesheets, and other non-technical things that need to be done that you cannot give to your team members, and frankly they didn’t sign on for those things.
  2. Micromanaging is for losers
    Micromanaging is like that annoying roommate that was always “accidentally” looking over your should at your computer to see what you were doing.  It makes people very uncomfortable.  If know that you do it, then give people the heads up.  I try to warn people when we have new tasks and deadlines that popup that I will be breathing down their neck to make sure they are on task and getting things done.
  3. Clear direction
    You have to give someone as much information as they would need to accomplish the task.  Don’t just tell them to go correct the UI on the login page.  I tend to give enough to get the job done, but I leave some wiggle room for my teammates creativity to shine through.  This is two fold.  They might teach you something and you might be able to teach them something at the end.
  4. Play to your team’s strengths
    Assign tasks to team members where they will perform extremely well or at least will be best suited for the task.  I give all of my CSS tasks to one guy on my team because he has made it clear that he enjoys writing and figuring out CSS fixes.
  5. Add in responsibility/accountability
    Accountability is the biggest part of all of this.  You have to be willing to tell people when they screwed up and how to fix it.  There is some balance and compromise here.  Don’t give people tasks that you know they are going to fail (i.e., lack of inexperience, knowledge, or confidence).  This final technique will also provide you insight into who is next up on your team for a lead role.

It takes some experience to get delegation right.  Apply it everywhere you can to see what works for yourself and doesn’t make you have OCD about control of your team’s tasks.