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.