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
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?
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.
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, 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.
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
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.
Muda is a Japanese word meaning “futility; uselessness; wastefulness”, 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). Waste reduction is an effective way to increase profitability.
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.
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
feedforward (status reporting and new information presentations)
feedback (reacting and evaluating )
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
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