Archive for December, 2007

Book review: Managing Humans

Thursday, December 27th, 2007

Recently started reading this interesting non-mechanical book on people management written by Michael Lopp. I borrowed from him the term ”mechanical” manager to describe his book as non-mechanical. The second chapter ”Managers are no Evil” is worth alone as it provides a simple answer to venerable question asked by engineers: ”What does my manager do?”… The stories in this book come from software engineering companies ranging from startups to big ones. Highly recommended for software and technical support engineers and team leaders promoted to management positions to get insight into their new role, avoid mistakes and blow-ups. 

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager

Buy from Amazon

- Dmitry Vostokov @ ManagementBits.com -

Digitizing a Manager

Wednesday, December 26th, 2007

As you might have noticed I have already described 4 essential management bits forming the part of a management bit vector. For example,  

0110… bit vector describes a manager who

  • writes with mistakes (0×1)
  • never misspells names (0×2)
  • writes reports on time (0×4)
  • doesn’t read management books (0×8)
  • … (0×10)
  • … (0×20)

So you can digitize any manager using management bits as observables. This sounds like a reductionist approach to life sciences but at least it is manageable. You can also digitize any employee or job candidate to form their employee bit vector or candidate bit vector and see how their bit vectors are close to your acceptable bit mask or even your own bit vector and this can be the basis for promotional assessment or hiring decision.

Also you can see that 32 essential management bits result in 4 billion different managers. To cope with such combinatorial explosion we might need to introduce management subsets or management bit masks later on.

- Dmitry Vostokov @ ManagementBits.com -

Project Failure Analysis Patterns (Part 1)

Tuesday, December 25th, 2007

Recall from my motivation for this pattern series the analogy between the following entities:

  • Computer Application/Process - Team

  • Thread of activity - Team member

  • Operating system - Company organization and management

  • Computer system - Company organization and management plus teams

  • User process dump - Team state snapshot

  • Kernel memory dump  - Organization state snapshot

  • Complete memory dump - Organization state plus teams internal state snapshot

  • Exception - Fault, mistake

  • Crash or hang - Failure

The first pattern is called Multiple Faults and it is a direct mapping from application crash analysis Multiple Exceptions pattern. The running instance of a computer application (process) can experience multiple exceptions from different execution threads before it hangs or crashes. The latter causes the process to disappear from external observers watching Task Manager. The same can be true for any functional team. Multiple faults from different team members can happen and if a team fails we shouldn’t attribute the overall failure to just one member’s fault that is on a surface but look for other possible mistakes too. 

- Dmitry Vostokov @ ManagementBits.com -

Management Bit and Tip 0×8

Monday, December 24th, 2007

Day-to-day hands-on experience only is limiting (bit). Read books, articles and blogs to deepen your understanding and broaden your knowledge and then apply to your day-to-day work (tip).

Sounds obvious but so far I have seen that engineers and managers en masse don’t read or only read on per-problem or per-task basis. It is a known fact that in order to really understand our subject matter we need to read about other experiences as well, be it science, engineering or management. Even reading one book or article about a particular topic is not enough, it is better to read several of them to avoid biases and see different viewpoints. From my personal experience, I got much deeper understanding of C++ merely by reading the vast amount of books. Although I applied hands-on C++ knowledge to the variety of projects, the real life experience was very limiting even when I happened to write and maintain parts of C++ compiler. For management roles it is even more important to read because managers cannot afford to learn from day-to-day feedback only. It might be too costly. In the future I’ll put some links and reviews for management books I found worth reading.

- Dmitry Vostokov @ ManagementBits.com -

Expertise-Driven Motivation

Saturday, December 22nd, 2007

There are many X-Driven motivations out there but I prefer expertise-driven individuals, motivated by the desire to become experts. It is not bullshit as you might think. It is more like a persistent psychological state found in researchers and scientists and the best results are guaranteed when it is supplemented by money-driven positive feedback loop. I’ve seen such people in both software engineering and software technical support environments.

Copied with corrections from my Crash Dump Analysis blog

- Dmitry Vostokov @ ManagementBits.com -

Management: Analysis and Synthesis

Thursday, December 20th, 2007

I created “Management Bits and Tips” category to write my thoughts on management and then realized how this category title is metaphorically similar to scientific modeling approach:

Analysis (Bits) -> Synthesis (Tips)

There are books and blogs with pure “analytic” titles:

  • “Management Bits”
  • “Management Bytes”
  • “Management Bits and Bytes”

or with pure “synthetic” titles like “Management Tips”.

I was thinking about “Management QWords” category but abandoned that thought because ”QWord” sounds to me as an abbreviation to “Cursing Words”. “Management DWords”? DWORD is an abbreviation to computer memory term “Double Word” but it doesn’t sound good from management perspective. ”Management Words” sounds like a dictionary title. 

Regarding the domain name managementbits I decided to register the shorter name than managementbitsandtips.

Copied with corrections and additions from my Crash Dump Analysis blog

- Dmitry Vostokov @ ManagementBits.com -

Management Bit and Tip 0×4

Wednesday, December 19th, 2007

Your boss needs a report, your boss’s boss needs a report from your boss, your boss’s boss’s boss needs a report from your boss’s boss and so on, and everyone needs it before a certain date or even an hour. No one likes delayed reports and no one likes to write them in a hurry (bit). Use IIRW process, Iterative and Incremental Report Writing (tip).

People feel anxiety when time approaches a deadline and reports are delayed. This affects both who needs to read a report and who needs to write it. So don’t leave report writing to the last hour before deadline to avoid delays. If you are in software industry you probably know about iterative and incremental software development. Apply it to report writing too. Write reports incrementally as soon as you finish a task, subtask or milestone and revise them iteratively. This will also accommodate unexpected risks to report delivery when suddenly another boss is added in the middle of reporting chain and people below have to shift reporting time.

- Dmitry Vostokov @ ManagementBits.com -

Project Failure Analysis Patterns

Tuesday, December 18th, 2007

There is something similar, at least metaphorically, between computer system crashes and hangs and software project failures. Software projects deliver software that crashes and these software failures via negative feedback loop either slow projects down or simply lead to their abandonment. The structure of a software development team resembles that of a running application (called a process) with team members acting in parallel (threads) and the structure of operating system with multiple running processes competing for resources resembles a software company struggling to stay alive. When projects fail there is something left as artifacts available for study and the same is true for crashed processes or operating systems leaving crash memory dumps behind for postmortem analysis.  

In some future posts I’m going to map Crash Dump Analysis patterns to Project Failure Analysis patterns and see what comes out of this attempt.

- Dmitry Vostokov @ ManagementBits.com -

Management Bit and Tip 0×2

Tuesday, December 18th, 2007

People feel uncomfortable if not irritated or alienated when they see their misspelled names (bit). Don’t rely on your native language patterns or automatic spell checking. Verify names manually before hitting “Send” button (tip).

For example, in English it is rare when a name starts with both consonants and it is not easy to pronounce Dmitry or Dmitri (both are English and French spelling of the same Russian name) than Dimitry. Therefore people tend to write the latter. Once I got an email starting with “Dear Dirty”. At that time that was the default suggestion from Microsoft Word spell checker.

- Dmitry Vostokov @ ManagementBits.com -

Management Bit and Tip 0×1

Monday, December 17th, 2007

Flawless writing skills are very important to avoid negative impression (bit). Use Google to check your writing (tip).

It is especially important for non-native English speakers like me. You can search simple sub-sentences and their alterations to compare search results.

For example, today I had a discussion about this sub-sentence:

“It’s main advantage is “

It gives 539 search results. However the sentence without apostrophe

“Its main advantage is “

gives 8,870 search results. Let’s check combinations with two “it”.

  • “It’s main advantage is it’s ” - 192 results
  • “Its main advantage is it’s ” - 0 results
  • “It’s main advantage is its “ - 299 results
  • “Its main advantage is its ” - 836 results

So you get the idea of what is more correct or more widely used from descriptive grammar point of view.

Copied with minor corrections from my Crash Dump Analysis blog

- Dmitry Vostokov @ ManagementBits.com -