Archive for July, 2010

Manager Red Flags

Monday, July 26th, 2010

(Attention lawyers and previous employers: the following information does not specifically identify a particular entity. 
You have nothing to worry about unless you think this represents you or your company and you know there is some truth to it.)

As I have worked with a few different kinds of managers/supervisors throughout the years, I have encountered one or two that had various red flags that I ignored but should have paid attention to.  Here, I share some of these red flags with you in the hopes that you do not end up getting screwed.  Not saying I got screwed (well, much), but you may! :mrgreen:

Red Flag # 1 – People tell you to watch out for her/him.
That should be obvious, but sometimes your first impression (which was good, in my case) clouds your better judgement.  Pay attention to what other people are saying about this person.  Even if you treat it as rumor, keep it in the back of your mind.

Red Flag # 2 – She/he has a long history of dismissing or demoting employees with excuses of “no confidence.”
When this manager joined us, it was because of a merger with another company.  My current manager was demoted in short order because of “no confidence.”  Note that he had been with the original company from the start and had been supervising/managing developers (quite successfully, I might add), up to that point.  Other people in the company (the new one in the merger) often mentioned her/his tendency to do this.

(As an aside, I strongly believe that one of the things that would greatly benefit the business world in general is a process for employees to call for no confidence in their manager/supervisor.  Once managers/supervisors realize that they can be called to task for the otherwise unknown shit they pull on their subordinates, things may change for the better.  Companies need to realize that most of the real work is done by those that have not yet reached their level of incompetence.  It is time to move out the ones that are not just incompetent, but possibly abusive and reduce the productivity of their subordinates.)

Red Flag # 3 – She/he exhibits bipolar behavior.
Not in the clinical sense, but you notice that she/he can run hot and cold at the drop of a hat.  Be more caution if this flipping between states is a result of perceiving you as a threat.  For example, she/he once asked if I wanted to be a manager “because I was good at it,” referring to how I worked with developers.  But when I put on my yearly review form that I wanted to become a lead/manager of the team, I was informed that she/he did not think that I would be good at it.  WTF?

Red Flag # 4 – She/he takes credit for things that she/he has nothing (or very little) to do with.  These types may exaggerate their involvement in the conception and implementation of (novel) solutions, or have their name placed on things that were conceived and implemented long before they were even around.

Red Flag # 5 – She/he is personal friends with one or more people in upper management.  By “personal friends,” I do not mean taking the occasional plane ride together, I mean things like frequently getting together on weekends, crashing at each other’s place, etc.  In some (less professional) companies, this can end up being Carte Blanche to do just about anything.  People in this position can become assholes to their subordinates, just because they can, and they have in the past without being called on it.  As as you may find out, the human resources department is sometimes just upper management’s bitches, so people like this are never correctly identified by their pattern of behavior and removed from the company.

Red Flag # 6 – She/he will undermine your authority over, or the respect you receive from, other developers. 
One specific case I can recall is with a problem one of our plug-ins had with another plug-in from another group.  Both worked fine separately, but when loaded into the same application, the other plug-in would sometimes not cleanup its interface correctly and would leave a window on screen that was broken, and would raise exceptions whenever it was touched.
Now, we had access to that other plug-in’s source code, so I wanted to load it up in the debugger to see what was causing the crash.  My manager at the time effectively berated me for this idea, that it was not the way to do things, and saying that “in her/his time,” we never blamed stuff on other developers.  (I never said it was the other group’s fault, I just wanted to get more details on what was happening.)  And then she/he had me make (random) changes to our code to see if we could get the exception to go away.
After a couple of days(!) if no results, she/he then stated in an open conference call “I guess we will have to find someone that thinks outside the box, then,” with other members of my development team present.

Well, I hope that helps… someone…

Agile Development – Scrum Pitfalls

Monday, July 26th, 2010

I have been subjected to a few so-called agile development methodologies over the years.  Most recently, Scrum was the one in question.  Well, it was kinda-sorta-almost Scrummish, which means it was not really Scrum at all, but we will ignore that for now.

All in all, the use of stories and a Wiki to keep track of development, testing, etc. was a really good thing.  It kept developers (er, me) focused on what needed to be done, keep straight how it was gonna get done, and identify any problems that would prevent it from getting done.

Add to that the daily 10 minute standup meetings, which was the place to specify to everyone else on the team what you were going to be working on today, and what, if anything, was standing in your way.


There were also some things that got in the way of using all of these tools, and those things tended to be the immediate (and sometimes upper) management, and the business side people.  Here are the three biggest problems we (I) had with things.

Problem 1 – everyone needs to use the Wiki!

More often than not, stories were written by our immediate supervisor/manager after getting verbal(!) information from our business side person.  The resulting stories were usually spot-on for what the business side had in mind, but not always.  When they did not jive with the expectations of the business side person, the developers were to blame, even though we were just following the story!  The supervisor rarely took direct responsibility for any miscommunication.  This would not have been a problem if the business side (and any other interested parties) used the Wiki for its intended purpose.  At a minimum, they should have looked at the stories written by the supervisor to make sure that everything was kosher.

Problem 2everyone needs to use the Wiki!

The Wiki was used for just about everything development-related.  What needed to be done, how it was going to get done, how it was going to be tested (the QA team members would also use the same Wiki), and, most importantly, show the progress of a story and its tasks.  This was good.

What was bad, is that developers often would get contacted directly by either our supervisor or our business side person to check on the status of things, or get details on what was being done or how it was being done.  We just spent 10 minutes updating our stories so that anyone could find out what is going on just by clicking a few links.  Now we get to spend more time updating this person or that person.  It is not that the time taken is a big deal.  It is the act of being distracted away from whatever we were working on.  Having to switch gears throughout the day to answer questions that have already been answered on the Wiki is not just a waste of our time, it shows a lack of respect for our time and what we do.

Problem 3Everyone…  Needs…  To…  Use…  The…  Wiki!!!

Meetings further exacerbated this problem.  Sometimes, questions would be asked during the standup meeting that were already answered on the Wiki.  Sometimes, hours prior to the standup.  Not only does this show a lack of respect for the developers, it shows a lack of respect for other people in the meeting as well — their time is being wasted here, too.  It also shows a lack of respect for the development process — we have the Wiki there for a reason.  Use It!  If our examples (anyone above us in the food chain) do not respect the system, then why should we?

Standups were not the only problem.  If any meetings were called that involved other people (like the business side), we would often get stuck answering information that was not just recently on the Wiki, but stuff that may have been answered at the start of the iteration, which may have been more than a week ago!  This is not just disrespectful, but it is a waste of money as well.

Assume that we have a 7-member team that has 5 developers, one supervisor and one business side person.  Assume an average salary of $100K for each developer, $175 for the supervisor and $200 for the business side person.  If the business side person takes up 15 minutes of a meeting asking a question (and getting answers) for something that was already on the Wiki, that costs the company $$$ (remember: time is money).  How much money?  Well, going by contractor’s math, a salaried person’s corresponding hourly rate is ~salary * .0005.  Examples:

$100,000/year ~=  $50/hour.   Rational: assume ~250 working days in a year (including 2 weeks vacation), at 8 hours a day, that comes out to 2000 hours.  So, 2000 hours * $50/hr = $100,000/yr.

If the business person spent 15 minutes reading the Wiki, that would only be 15 minutes of their time, so that would cost the company $25.  By wasting 15 minutes of time in a meeting with the developers and the supervisor, this costs the company $109.37.  ($84.37 of everyone else’s time plus the $25 for the business person’s time.)  Check the math yourself if you do not believe me – more than 4 times as much time and money is wasted!  Big difference, eh?  Even by calling a single developer, and chatting for 15 minutes, this costs the company more than necessary – it costs the business person’s time, the developer’s time, and the time for them to switch gears back to whatever they were doing before the unnecessary interruption.  At a minimum, this is $37.50, and 15 minutes of developer time where they were doing something other than development.

A simple way to avoid this problem – everyone in a meeting should assume that everyone else’s time is at least as valuable/important as their own.  Once you start thinking like this, you may stop wasting other people’s time as easily as you once did.

Conclusion: using any agile development methodology and its tools is probably a good thing.  But you must get everyone involved to buy-in and use the system.  Having anyone (including those higher up on the food chain) refuse to use the system can make others wonder why.  If anyone is too good for the system, then why are we saddled with the burden of using it?  If there is a senior-level manager that thinks that they are too important to click a few links on a web page, then fine.  But this should be handled by a lower manager, not by the developers themselves.

The developers have a job to do – let them do it.