Process approvals

Some processes have a long cycle of approvals which are delaying the final task execution. The delay is disturbing, while some people might miss an approval which restarts the process from the start. It complicates and delays execution dramatically.

The wrong part is that an approver has no any accountability on giving or not giving an approval.

The correct way to collect approvals is approvals by default. If an approver or substitute fails to review a task and give the approval within a pre-agreed period of time (1 BD is fine for most of the cases), the task is approved by default and the process moves forward. If any damage caused by giving approval by default, the approver who failed to review a task, assumes full accountability for the damage.

This way forces every an approver to be personally interested in giving the approval while keeping process execution quick.

Muse - Drones

The Drones is totally enjoyable. The sound returned to be similar to their 2000's albums and moved away from their failure albums 'The 2nd Law' and 'The Resistance'. Drones is fully packed with tooth-breaking songs, I'm sure more than 50% will become hits. It's been a while since I enjoyed so many songs from a single disk. Most of them are a great quality.

I have additionally enjoyed their reference to Qubric's Full Metal Jacket. It's entertaining to see one art piece I love to refer to another art piece I love. Great Job, Muse!


The Martian

The book is not for everyone, but science and engineering nerds would surely enjoy it. It tells the story of a botanist Mark Watney being stranded on mars and his journey to escape (or not :) the planet. He is doing all the weird crazy science and duct tape engineering to make his escape possible, fighting the odds of uncertainty on his way home.

The book's science seems to be error-less for a casual sci-fi lover. Engineering and stage setup for the books's action seems to be organized in such a way, the the action hero was supplied by all the necessary resources to make his escape only. There is a series of events which would almost kill Mark, bit now. And yes, there is always a workaround possible with only few resources brought to Mars with him. There are about 7 of them and I stopped trusting real-life positive outcome on about 3rd. Real-life entropy is much more unexpected and deadly. Mark had more odds to die from diarrhea than surviving all the mayhem he's being through.

Reading science and engineering is mostly joy. Although he ratio of science/action book's content is about 90/10 which makes it boring at times. You wish to move action forward while being  stuck with some crafting scenario.

If you like to know how to escape Mars with Duct tape and disco music, the book is for you.

Русский национальный фолк

Обажаю korpiklaani за то, что в их фолк-метале есть какой-то национальный инструмент, который одновременно задаёт мелодию и предает ей неповторимый колорит Скандинавии, природы, смиренной грусти. Будто эту песню играли много поколений назад и в таком же неизменном виде будут играть ещё много поколений.

В русской культуре такой же национальный и одновременно грустный колорит задаёт гармонь. Хочу слышать наш фолк-метал с гармонью, на наш русский грустный лад.


It's been a really long journey, but finally i have become CCNP R&S


Staff oversharing

In my experience I was working in a IT support company with a team dedicated to a project and a team shared among projects. Being a part of a dedicated team is simple. Same goal, shared job among everyone. Team spirit and dedication. Possibly one lead/manager.

Shared teams are worse. Shared teams introduce additional complications to be managed

  1. Each person should learn multiple project's contractual scope of work
  2. Since projects are never identical, subsets of technical expertise for each employee multiply with every added project
  3. Vacation, leave and sick planning becomes messy with above 2 complications, because each expertise subset must be shared among at least 3 employees in order to ensure the service is going to be covered during on expert's absence.
  4. Different projects are mostly different customers with their own unique tools for ITSM/systems administration. Each member must know how to use all the tools for each project
  5. Different project follow different subsets of business processes and different escalation/responsibility charts.
  6. KPI Reporting multiplies with amount projects in place
  7. Tasks prioritization is tough. Imagine having two highest priority incidents for a  different customers during a scheduled change for a third one. It creates Interruptions. Support engineer jumps from one task to another often without having previous task being completed. Too often.
  8. Management multiplication. Each project tends to have a separate delivery/project/account/name_it manager, who is interested in his project KPIs achievement and destroys a shared team's dedication.
  9. Capacity management. Estimating and measuring each team member's effort dedication to each project is complicated.

Therefore I'm suggesting a universal measure of measuring complexity of a shared team member's life. The logic behind is not to measure resources, but to measure complications level of a team. Each complication in my logic adds 10% work overhead for each project. I didn't introduce 0.1 constant, because the coefficient may vary from complication to complication and might be more severe or less severe depending on circumstances. Complications add to each other creating additional workload and than shared among the team members.

The formula below shouldn't be considered as precise or scientific measure of any kind.

The idea is to get a complication multiplier ($complexity) which indicates a fraction of complexity overhead for the team. The complexity multiplier can be used for deriving additional amount of workforce required to manage all the project in the team.

We may assume $complexity values for 0 to 1 stand for healthy teams, 1 to 1.25 stand for slightly overloaded teams, above 1.25% for doomed overshared teams :).

The formula in a Perl code

$proj_amount = 6; #sample value
$team_members = 3; #sample value
$proj_sow = 0.1 * $proj_amount;
$proj_expert = 0.1 * $proj_amount;
$team_expert = 0.1 * $proj_amount;
$proj_tools = 0.1 * $proj_amount;
$proj_proc = 0.1 * $proj_amount;
$proj_KPI = 0.1 * $proj_amount;
$team_tasks = 0.1 * $proj_amount;
$team_mgmt = 0.1 * $proj_amount;
$team_capct = 0.1 * $proj_amount;
$complexity = ($proj_sow + $proj_expert + $team_expert + $proj_tools + $proj_proc + $proj_KPI + $team_tasks + $team_mgmt + $team_capct) / $team_members;
printf "Project complexity: $complexity \n";
printf "Team members required: $team_members * $complexity = ";
print $complexity*$team_members;

Sample run


Всю жизнь я считал, что зубочистка по-английски пишется "toothpike", на счет чего имел смелые этимологические фантазии о том, как находчивые англичане взяли pike (копье), которое применили для борьбы с пищей в зубах, что рождало богатые образы.

Оказалось, что зубочиска пишется "toothpick", где pick уже не копье, а ковырялка. Ковырялка! Копье разжалавоно в ковырялку! Этимологическое разочарование века.

Instagram is a perfect showcase of one's BORING REALITY