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

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.

Contingency Planning

BLUF: There are times when you won’t have 100% of the answers to create a plan.  Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.

Contingency plans are critical to any operations or projects.  It is the “if X, then Y“.  You have to be able to account for these possibilities.  Play devil’s advocate or punch holes in the plan.  In the military this is a common practice.  After we devise a plan a group will provide all of the counter plans that the enemy will execute.  This is all in the process of war-gaming.  In war-gaming you answer all of those IFTTT questions.

In software development you can also apply contingency planning.  Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work?  I run in to it regularly.

  • What if we don’t have access to a SQL Server database?
  • Who controls federated logins?
  • When will customers transition?

What is your plan at certain decision points?  At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL.  You have to run with it.  Do you extend your deadline claiming you couldn’t get it done?

Always have a contingency plan for your project critical paths.  A contingency plan is not pivoting.  It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way.  Eventually you need to accept the risks or mitigate some or all of them.  Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.

It doesn’t take long to run through some simple scenarios where you think something might go wrong.  Cover your bases in the situations that you don’t have accurate or unknown answers.  What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.

Leaders are Teachers

BLUF: You won’t be able to scale without being able to teach in order to grow.

Becoming a great a leader means that you need to be able to teach.  Not teaching anyone about your experiences is a selfish approach to not spread your knowledge and understanding.    Jack Welch introduced many to the idea that leaders are teachers.

They have to see their roles as a combination of teacher, cheerleader, and liberator, not controller. – Jack Welch

Teaching team members fosters team communication and imparts a sense of “you know what you are doing” and gives team members a sense of confidence in a leader.  We have talked about how you are not going to know everything and you rely on others knowledge and experience to complete projects, but imparting your experiences is key as you are the more than likely the senior leader and have been involved in enough situations to apply past experience.

In my experiences in the military you see senior non-commissioned officers (NCO) that teach brand new lieutenants the ways of the force.  These NCOs have over a decade of experience in the military.  I had multiple NCOs during my time on active duty that pointed out my many flaws and showed the right way to execute.  You rely on your NCOs more than anyone else when you are a young lieutenant  My one caveat is that you cannot rely on every NCO to point you in the right direction.  Always apply common sense when choosing those that you want to be your inspiration in your career and life.

Everything that you teach your team are small dividends that you are investing back into your culture.  If you have teaching points and not demand points, then you allow your team to learn from the past and filter those experiences in order to provide a more productive environment in the company.  Give them the leeway to make their own mistakes and learn from those, so that they can pass on experiences to the new guy.

I keep going back to this book – Jack Welch: Winning.  This is one of my top books to read to learn how to be a understanding leadership and learn how the people you are leading will make you great and that you need to take care of them.


SOAP BOX

I do think there are issues in the OSS community for those new developers that are trying to get involved with projects.  If you are the one making snarky comments about a pull request or make the commit so complicated that no one wants to put aside a week of free time to fix a label misspelling, then you need to take an inner look at what you are trying to accomplish and if it is truly open source.  Yes OSS projects are “free” libraries to help out others, but open source also means that others have the possibility to help if you give them the platform and culture that allows for that help to emerge.  It takes more than just adding a tag that says “newbie” or “low hanging fruit” to get people to help out.  If they have questions or look lost, then don’t chastise them, guide them.