1/3, 2/3 Rule

BLUF: Give your team the time they deserve to accomplish their planning before execution.

During any operation in the military there is a rule of thumb that should be applied to any mission planning set.  The “1/3, 2/3 Rule”.  This rule states that you should only use 1/3 of the planning time for your planning and give 2/3 of the planning time to your subordinates.

For example, if you need to move a logistics package from Tampa, FL to Atlanta, GA and it needs to happen in 3 days,  then you should take 1 day (1/3) of the time to plan out the logistical movement at your level and then give your team 2 days (2/3) to plan out their part at their level.

If you think about this, then you are allowing the most planning time given to your teammates rather than being selfish and hoarding all of that time and everyone else’s time to create my plan and then throwing it at everyone else hours before the execution has to happen and expect a great execution to occur.  Also, if you wait until the end to give your teammates your plan, then your team is sitting around doing nothing and guessing about what actions they need to take to make this a successful execution.  They can only guess if you actually told them that something is coming down for them to get ready for.

This planning technique highlights a few leadership characteristics that I have discussed in previous posts.

  1. Don’t be selfish, be self servant.  Allow your team the most time to plan for mission execution.
  2. Provide a WARNO (Warning Order).  This will answer the 5 W’s for your team to prepare for without knowing the intricate details of the plan.
  3. OODA loop – Don’t let this 1/3, 2/3 Rule confuse to be a hard and fast rule about you do your 1/3 planning first and then they do their 2/3 planning.  This is still an iterative fashion that you should continue to feed information to your team as your receive it.

Backwards Planning

BLUF: Planning is only as valuable if your information is accurate and worthwhile.

Planning and design is the biggest consideration if you have the time and information to apply at this stage.  This stage will allow you to reduce code maintenance.  It also allows for expectations to be set correctly.

Backwards planning helps you setup tasks that need to be accomplished by a deadline.  This planning technique can be used with any software development lifecycle methodology.  It allows you to estimate tasks timeline from a deadline and work backwards to see when you need to start each task in order to meet your deadline.

Here is a quick example.  Fly from Atlanta to South Africa.

  1. Deadline: June 18, 2018
  2. Pack: 1-2 days before
  3. Find travel amenities (magazines, books, pillow, snacks, etc.): 3-4 days before
  4. Order new luggage: 1 week before
  5. Vaccinations: 1 month before
  6. Book hotels: 1-2 months before
  7. Book tours: 1-2 months before
  8. Passport: 4-6 months before
  9. Purchase plane tickets: 1-6 months before

In this example you have to start your process of getting ready for this trip in January 2018 otherwise you run the risk of not having a passport to leave.  If you already have your passport, then you can start in April 2018.  Obviously with experience and know how you can further reduce your timeline.  All of that is part of the planning phase.

Backwards planning can allow you another tool to tell you if your timeline is accurate or if you need to reduce your workload in order to meet your deadline.  This can also help you in finding which features or tasks will never be able to make it into your timeline because it just doesn’t have the runway to accomplish something that is dependent on another team or third party to accomplish.

Realize that this technique can help estimate points in Agile, timelines for Waterfall, or to find predecessors for your tasks.  Also realize that you cannot always have a great planning phase without enough information to accomplish your planning.  Sometimes things happen that interrupt schedules and cause you and your team to be dynamic.

These dynamics can either be your best accomplishment or greatest downfall as a leader.  Don’t allow a misstep in plans to fail your project.  Don’t forget…

No battle plan survives contact with the enemy. – Helmuth von Moltke

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.