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.

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.

Tasking – Edge of Success

BLUF: Give team members tasks that put them on the edge of success or failure.

Providing the right level of task to the right person is always a tough decision because there has to be thought that goes into it; time, priorities, experience, and knowledge.  Not only these definitive decision points, but also do you have the right team makeup to provide a solid foundation to solve problems.  You have to build a team that makes sense.  If you are using C#, then don’t hire the technical expert that has been building Java Applets his entire career.  Unless you have the project runway for him to learn C# first and then get going on the project, they will fail.  Either because you are pushing them to fast and then don’t have the knowledge and experience to provide productive coding or because they get fed up and leave with the environment that they are working in.

When assigning tasks out take into consideration which ones will put team members on the edge of success, but a critical step left or right could put them in a failed state.  Having team members that you are excelling to succeed, then you are doing no favors for them or yourself.  They will not have challenging work and you will ultimately have a product that falls flat.  Engage each member equivalent to their technical needs and wants as well as their experience.  Once again you have to have the right team make up to make this achievable, but that includes still be able to solve problems that occur that no one knows how to solve.  You just need the team members that are willing to venture into new lands.

It becomes a team balance to provide the best culture and environment for your team to both have technically sound and creative work that they are proud of.  You have to know when to back off on the pressure and let your team have a break.  Software engineers have a known ebb and flow in projects.  You are going to have days or weeks where there needs to be full pressure to get something done or fixed, but there has to be a down time for them after the fact.  If you don’t provide that type of environment, then you run the risk of too much stress and fatigue for too long and they start to hate the job and career.

I treat my team like they are my kids.  You have to be able to teach them and give them life experiences without dictating how to perform every task step by step.  If you start to fall into the realm of micromanaging or dictating, then either you are the wrong leader or your hired the wrong people for the team.  Take a look at yourself first and adjust to see if people will break out of their shell to provide productivity and creativity.