Why we need a Systematic Approach to Developing our workforce

In the past the man has been first; in the future the system must be first. This in no sense, however, implies that great men are not needed. On the contrary, the first object of any good system must be that of developing first-class men; and under systematic management the best man rises to the top more certainly and more rapidly than ever before.

Frederick taylor (father of scientific management) 1911

The Quality of Your Product is Only as Good as the Tools You Use

Your software is only as good as the current knowledge of the team who created them

want a better product? desire a better team.

how do you do that?

Train them, give them resources

How do you ensure that resources are not wasted?

It starts with Hiring!, find the right people, the ones who crave for learning and growth, those who get out of their way to find answers and solutions.

It all starts with hiring and looking for people who believes in the same things as you do.

Now ask yourself, what do you believe in?

do you believe that things just fall into place? do you believe in luck? (would you leave your organization’s success to luck?) or do you believe in building a team of Growth-type and no-bullshit honest people so that your team with organically grow as time goes by?

Why we need to build positive work environments

[et_pb_section][et_pb_row][et_pb_column type=”4_4″][et_pb_text]

we need good work to happen naturally, and to do that we need to start with Psychological Safety,
https://www.impraise.com/blog/what-is-psychological-safety-and-why-is-it-the-key-to-great-teamwork

This list came from Google’s quest to find the perfect team, Project Aristotle

image source: https://www.impraise.com/blog/what-is-psychological-safety-and-why-is-it-the-key-to-great-teamwork

[/et_pb_text][/et_pb_column][/et_pb_row][/et_pb_section]

The Bus Factor and why every team lead should know this.

from deviq.com

A project’s bus factor (or truck factor) is a number equal to the number of team members who, if run over by a bus, would put the project in jeopardy. The smallest bus factor is 1. Larger numbers are preferable. Essentially, a low bus factor represents a single point of failure within the team.

from wikipedia

The bus factor is a measurement of the risk resulting from information and capabilities not being shared among team members, derived from the phrase “in case they get hit by a bus.” It is also known as the bread truck scenario, lottery factor, truck factor,[1] bus/truck number, or lorry factor.

The concept is similar to the much older idea of key person risk, but considers the consequences of losing key technical experts, versus financial or managerial executives (who are theoretically replaceable at an insurable cost). Personnel must be both key and irreplaceable to contribute to the bus factor; losing a replaceable or non-key person would not result in a bus-factor effect.

tldr; if a key perso is hit by a bus, can operations continue?

Sample Scenario #1 there one key person doing a role without backups, this results in a bus factor of 1, with a fault tolerance of 0 if that person gets hit by a bus, there is 0 recovery, operations is affected

Sample Scenario #2 there are two key people doing a role with absolute information, this results in a bus factor of 2, with a fault tolerance of 1 we can get by if 1 gets hit by a bus, operations run as usual (but may have some slow downs if certain knowledge/skills are only known by the poor guy which was run over by the bus)

Is your operations rattled each time a key-role leaves the team?

if you answer is yes, then its a sign that you have a low BUS FACTOR and you need to increase it.

As a team,department, organization-in-general we should be aware of this concept,and actively discuss how to increase it for business continuity.

How to use Management to increase Producing Capacity

effective-management-fulcrum

Management is essentially moving the fulcrum over, and the key to effective management is delegation – Stephen Covey, (Habit 3) Seven Habits of Highly Effective People

Where Micromanagement Does work

  • it works for E people (see Alderfer’s ERG theory),
  • routine people who LIKE being told what to do
    • because they dont have to think, so they can think about something else.
    • like students or those busy with other big things
    • for people like them, routine is a breather.

Where Micromanagement Doesn’t work

  • it does not work for G people (see Alderfer’s ERG theory)
  • if u are a G person.even you won’t enjoy being micromanaged (but subconciously we tend to do it to others)

How do you increase output with G people?

the key is delegation

proper task delegation have the ff: characteristics (much like a task delegation guidelines)

How to remove the fear when programmers are asked to work on your codebase

nixcraft_codehandover.png

Problems

  • Sharing Projects/Codebases within a software development team is hard.
  • Programmers sometimes outright say it can’t be done.
  • This affects project deadlines negatively.
  • This is a type of Muda((https://en.wikipedia.org/wiki/Muda_(Japanese_term))) Information Waste which is rework
    • the Author already created the codes, debugged it and made it run.
    • then the next developer has to do it again because THERE IS NO AUTOMATION NOR DOCUMENTATION (see comic above)

Proposed Solution

  • INNERSOURCING – https://resources.github.com/whitepapers/introduction-to-innersource/
  • Borrow proper README formats from opensource projects
    • there are many guides/templates available online like this
    • github.com/PurpleBooth/README-template
    • this removes the question of WTH do i do with this repository?
    • this removes the muda rework because a copy+paste guide is already available
    • this allows a new-developer-in-the-project to quickly start working on business requirements and not waste time on technical specifics that should’ve already been handled by the author/initial team who worked on the project.

Quick Breakdown of the sections of the proposed README format

greatly inspired by https://gist.github.com/PurpleBooth/109311bb0361f32d87a2

  • Project Title – a meaningful name that indicates the problem you are trying to solve
  • Getting Started – any piece of context you wish to share to future maintaners
  • Prerequisites – skills you need to have, tools you need to know and software needed installed
  • Installing – how to get the project runnning~
  • Running Tests – how to ensure that the project really works before others start working on it
  • Deployment – how to release the finished project and some details where the application is actually in use right now
  • Built With – tools/frameworks used, to quickly match people who could work on this project.
  • Contributing – Coding standards / Architecture Design Decisions so the codebase will retain looking like it was written by a single person and therefore easier for future maintainers to understand.

Proposed KPI for a maintanable Software Project

  • Software Developers (Especially Tech Leads) metrics should include “how easy is it to onboard new developers on projects that I led”
    • this is in contrast to smartass developers who take pride in obfuscating their code because it makes them look smart.

From Wikipedia

Muda is a Japanese word meaning “futility; uselessness; wastefulness”,[1] and is a key concept in lean process thinking, like the Toyota Production System (TPS) as one of the three types of deviation from optimal allocation of resources (the others being mura and muri).[2] Waste reduction is an effective way to increase profitability.

From Wikipedia

KnowledgeManagement – Email is where your keystrokes go to die

never write a long EMAIL to someone three or four sentences, anything longer than that should be on a blog or a wiki or in your product’s documentation or it should be on a FAQ or a knowledge base or anywhere in the world except email. Because email is where your keystrokes do to die.

Scott Hanselman

How to make the most out of meetings

Why is this an Interference?

http://www.businessinsider.com/why-your-work-meetings-are-a-waste-of-time-2015-12/#there-are-no-followups-6

  • Meetings are not inherently bad, what’s bad is when you run a meeting that didn’t yield results
  • if your plan is to see what happens you will surely succeed, in seeing what happens – still trying to recall where i got this

How to run proper VALUE-ADDING meetings

aside from the solutions mentioned in the article/link posted above, here are what i commonly use to make meetings productive. This article talks about it. http://stevenmsmith.com/types-of-meetings/

  • Know the purpose of the meeting
  • Know the type of meeting you want to conduct
    • problem-solving
    • decision-making
    • planning
    • feedforward (status reporting and new information presentations)
    • feedback (reacting and evaluating )
    • combination meetings
  • Take “minutes of meeting“. as a start even simple notes will do..

knowing how to prepare yourself before a meeting reduces cognitive load, reduces stress.

Know the Purpose of the meeting

dont let the topics drift away too much from this. This gives us a handle and focus. a few branching out from main topic is ok. but beware of topics spawning just because people cant say anything about the main topic but still wants to look active. within the given time, don’t let meetings end without achieving this or atleast any lead on how to proceed next.

Know the type of meeting you want to conduct

this conditions the mindset of the people on during the meeting.

  • problem-solving – “ok i need to think of all posible solutions and try them against the stated goal/problem”.
  • decision-making – “ok given facts i need to consider possible options and their risks and gains”.
  • planning – “ok we need to think ahead, where we want to be in the future”
  • feedforward (status reporting and new information presentations) – “ok i need to recall all things i did, oh sh*t i haven’t really done anything”.
  • feedback (reacting and evaluating ) – “ok today i learn what i need to improve, i will be criticized today because they want to improve so i need to stay objective and accept tough-love”.
  • combination meetings – combinations of any meetings above as needed. “ok this might be chaotic..brace yourselves”.
  • undefined meeting type – “ok nothing to do here, i get to spend time achieving nothing,waiting for clock to tick.”

Take Minutes of the meeting

save in a centralized location accessible by anyone on a later date (and obviously that is not your pc hardrive) this catches whatever output (hopefully the real goal is achieved) gets produced from the meeting. this is where everyone can verify if the meeting was a success. this is something we can use on a later time to loook back, restrospect and improve our operations

Why you need to delegate (stewardship)

Stewardship is for growth of yourself and others, It is a win-win situation.
Stewardship is about telling people  WHY something needs to be done, WHAT you think could be a way to achieve it but  NOT HOW to do it.
Stewardship is about telling people what happens if they fail.
Stewardship is about giving your people what they need to get the job done and trust them that they will do it.

Trust goes both ways, a person who cannot trust others is not trustworthy.

Duplicating your capacity by developing people to be atleast as good as you (real goal is for them to be better than you!) is the only sustainable way to scale..
Stewardship increases the potential of both you and your trainees.
– they learn how to handle bigger tasks
– you can free up time for bigger tasks (act on it,delegate it, or delete it)

And teaches the value of stewardship. So it resonates to future trainees.

Now I understand what our CTO was telling me years ago. “In the future you should make more like you, like mark mark mark mark”.

The goal is to scale,to develop good people. not to be on top of other people.

 a leader is someone who knows the way, shows the way and goes the way

Other References

https://www.thoughtworks.com/insights/blog/three-common-mistakes-first-time-tech-lead