Shed Tasks

BLUF: Shed as many tasks as possible from your list so that you can focus on the entire picture and coordinate efforts for the team.


Delegating is an important part of being an effective leader.  I keep harping on this action as a leader.  It ensures trust in your teammates, lightens your task list, and ultimately gets work done faster.  Aside from this list you are able to focus on other requirements from the project and adjust focus on the project as the landscape changes.  This allows you to be a more dynamic leader throughout the project.

Shedding Tasks

There are many fallacies about handing out tasks to others.

  1. I don’t want to put work on other people because I want to help.
    As a leader you have to be able to task others to take care of their responsibilities.  You don’t hire people to sit around browsing the internet or socializing.  People want to do work…most people.  They also tend to get in trouble when they aren’t actively engaged in proactive tasks.  “Good idea fairies” tend to come out providing possible errors in code, adding new requirements to work, and unfocused work.
  2. I don’t trust anyone to do the work.
    If you don’t trust your teammates, then why did you hire them?  If they can’t do the work of the project then you need to move them, teach them or, ultimately, fire them.
  3. I don’t know how to assign work.
    Pay attention to what work your teammates can do and assign as appropriate.  Trial and error is always a fallback.  You cannot always assign work to the right people because of the size of the task.  It might be an overwhelming feature.  Break them down until they are achievable tasks.  “You can eat a whale, one bite at a time.”

As everything goes it will take time to be efficient at getting tasks done and assigning them correctly.  Iterate through the problem until you find what works for you.  Hold daily meetings to take note of how long some tasks are taking individuals to accomplish.  Use the common sense meter to adjust or help where necessary.

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.

Refactors and merging projects of Angular 4 into Angular 1.5

Last week I had to sit through a meeting where we were trying to figure out how to merge an Angular 4 app into an Angular 1.5 app.  First off, why?  The original intent was to merge the features of each project into one to create a new product.

Our defense was that we were using the latest, at the time, Angular library and that we had just finished a complete refactor and re-architecture of our entire project that took 2 months.  However, we lost the argument because the other project already had alpha/beta/production users.  What they had failed to do was a refactor, code review, or unit tests for the last year.  They have been working off of prototype code from the very beginning.

After the meeting I asked to have a static code analysis done of both code bases with HP Fortify and SonarQube.  The results were without question in our favor.  Both HP Fortify found 3 errors in our code which turned out to be false positives and SonarQube produced 0 issues, code smells, duplications, etc.  For the other project there were 130 issues with HP Fortify and 29 bugs, 3 vulnerabilities, 231 code smells, and 33% duplication with SonarQube.

Even after the static code analysis was done 4 developers took a look at the code base and it was even uglier than they thought.  Most of them saying they would be embarrassed to have the code base in their portfolio.  The code was hacky and only one developer was working on it for an entire year with no code reviews or merge requests.

Here is the rest of the story.  The project that came up with 0 errors was prototyped with minimal architecting effort, but got to a point after our MVP demo that it needed to be refactored in order to produce a sound and maintainable project.  What the static code analysis was not able to identify was the bad architecting that we originally did.  SonarQube found only 9 issues before our refactor.  I didn’t expect a static code analyzer to find out architecting mistakes, but the amount of difference between our code architecture before and after the refactor was massively different.  That is why we need some code reviews done to ensure that our findings for providing the accurate information to make a decision on our code base merge.

The obvious decision would be to merge our Angular 1.5 app into our Angular 4 app, but there is a business case that might not allow for that timeline, so we have prove our case that our technical solution is a better way forward for the business.

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.

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.

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.

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.