From the category archives:

Management

Interesting analysis today over on Jeffrey Phillips’ Thinking Faster Blog in an article titled “Productivity Barriers“.

In the article, Phillips discusses a recent newsletter from IFS (an ERP software vendor) that discussed the issues of usability of ERP systems. In the newsletter, IFS relates survey results that tried to, in Phillips’ words, understand:

…how much of a barrier the enterprise software most of us use everyday presents to becoming more productive

The research that IFS presented is quite interesting (click here to read the results on CIO.com). In addition to looking at usability, the research looked at productivity and asked questions around what factors caused a loss in productivity in the organization. The results aren’t surprising…results included things like (not in any order):

  • too many emails
  • too much work
  • lack of clear priorities
  • poor IT optimization
  • too many meetings

The survey respondents were than asked to supply factors that effected their own productivity and, again, the results aren’t really that surprising…results included things such as unclear objectives, not enough resources, too many meetings, etc etc.

What I found most interesting was Phillips’ take on the root causes of the above issue. He writes:

  • Unclear objectives/priorities - poor management strategic direction and communication
  • Too many meetings - poor management skills and time management
  • Too much work/Lack of resources - downsizing and “doing more with less”
  • IT not optimized/doesn’t work the way the company works - inflexible technology supporting a business that is required to be flexible and change
  • So, in my simple analysis, many of the issues related to productivity have to do with clear management direction and communication, and the ability to communicate what’s important. Additionally, in today’s market, flexibility and adaptability are just as important as established processes and operational excellence, but our technology, systems and processes aren’t designed that way.

Jeffrey Phillips’ hits it on the head.

Most problems with productivity today can be traced to a few factors (at least in my experience). These are:

  1. Poor Alignment of Information Technology and/or IT Process to the Business goals - If your organization needs to be flexible, don’t put in an inflexible IT system and/or IT process.
  2. Reliance on formal IT process - Process is good. Process is necessary. Create process to allow for flexibility, speed and change. Most processes today in the IT world do not follow this mantra. They are created and then their creators expect people to follow them closely with no deviation and no room for change.
  3. Poor Communication - Managers need to understand that in order to get the most of their teams, they need to clearly outline the responsibilities and expectations of the people in their teams. Without this clear communications, people will spend time trying to determine what they should be doing and/or who should be doing it.
  4. Poor Leadership - with good leadership, an organization can overcome many things. Excellent leaders will overcome poor process (by changing the process), poor alignment (by aligning IT and business), and poor communication (by ensuring communication improves).

Phillips’ analysis of the results of the IFS study were right on the mark….or at least they match up with my own thougths :)

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 5 comments }

When half an hour is greater than 14.5 hours

by Eric D. Brown on May 3, 2008

Heard a wonderful story last week from a developer friend of mine and thought I’d share (with commentary of course!).

He had taken a full-time job at an organization as a Senior .NET developer and was working an average of 55 hours a week for them. He liked the work he was doing but wasn’t too keen on the ‘punch-in/punch-out’ timeclock that they used to track all employees. Nonetheless, he was happy…it was interesting work and good pay.

At the end of his third week there, he decided to head out early one Friday afternoon and get an early start on the weekend. He ‘clocked out’ 1/2 hour early and enjoyed his weekend.

Monday morning comes along and what does he find in his email? A message from his boss stating that he would need to stay an extra 1/2 hour to make up for the previous week. He went to see his boss figuring it might be an automated message from HR but was told that he was expected to work a minimum eight hour day and would need to make up the time.

His response to his boss? A respectful question about the additional 14.5 hours he had worked the previous week and why those hours didn’t make up for early departure the previous week. ‘

The response from his boss is classic ignorance: “we pay you for 8 hours a day…we expect a full 8 hour day from you“. It also shows his ignorance in math…..since when did 0.5 become greater than 14.5 (the number of hours he worked in addition to the 40 hours)?

Needless to say, my friend resigned and is now working as a contractor being paid hourly for the work that he does.

His boss, and the company that he had worked for, were a classic example of the ‘old school’ business management mindset: You must be in your chair for 8 hours a day to do your job. This is so wrong…especially with the research studies that are coming out left and right (see this post and this one).

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 2 comments }

Carpe Factum: Hit and Run Project Managers

by Eric D. Brown on March 31, 2008

Timothy Johnson, author of the Carpe Factum blog (great blog…check it out), had an interesting St. Patrick’s Day post titled “The Luck of the Irate” where he talks about the wonderful “hit and run” managers. You know, this managers that step into a situation that they know very little about, offer their opinions and/or bark orders and then leave with the thought that they’ve “solved the problem”.

We all know managers and project managers like this…they don’t wait to find out the details…they barge in and ‘get things done’ but most times they end up confusing the issue and causing more work than needed. I’m a big believer in being hands-off as much as possible and expect my folks to bring up any issues that they need my help with…and it appears that Timothy believes this as well…he writes:

There’s a lot to be said for the finer art of facilitation as opposed to going into a conflict like a bulldozer on a steroid overdose

The “Tao of Project Management Blog” is quoted by Timothy to help make his point about using less of a bulldozer and more of a facilitator:

The wise project manager does not interfere with the work of the team unless all else has failed. Delicate facilitation is the way not sudden intervention. By using a sudden intervention the work of one or more members of the team is cast aside and they will feel violated. The team will be weakened and what may, at the time feel like a victory, is actually a failure.

Managing a team of people requires a lot of skills…being a bulldozer isn’t one of them. :)

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 5 comments }

Experience vs Ability Redux

by Eric D. Brown on March 28, 2008

In early March, Mind Hacks had an interesting article titled “Are you experienced? Does it matter?” which adds another wrinkle to my the argument I made in my Experience vs Ability post.

The article, which cites a Time magazine article titled “The Science of Experience“, states that, according to research reported in the Time article:

research has failed to show that experience, on its own, predicts task performance. In other words, old hands often do no better than novices (Reference).

The Time article reports on a study conducted at Florida State University over the last 30 years. This study claims that:

three decades of research into expert performance has shown that experience itself — the raw amount of time you spend pursuing any particular activity, from brain surgery to skiing — can actually hinder your ability to deliver reproducibly superior performance (Reference).

The article quotes Anders Ericsson, author of Cambridge Handbook of Expertise and Expert Performance (2006) as pointing out the following:

rather than mere experience or even raw talent, it is dedicated, slogging, generally solitary exertion — repeatedly practicing the most difficult physical tasks for an athlete, repeatedly performing new and highly intricate computations for a mathematician — that leads to first-rate performance (Reference)

The basic point of the article and the Mind Hacks post was the following: Experience doesn’t guarantee a higher performing employee….it might…but it might not. The performance will come down to how passionate, how committed, and how interested the employee is in constantly pushing themselves. The question now is: how do you quantify these traits when looking to hire?

I still say that innate ability + passion + an interest in constantly learning will bring an extremely high performing employee, and therefore a high performing organization.

[tags] ability, experience, Florida State University, Mind Hacks, Research, Time [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 2 comments }

Is Perfect worth it?

by Eric D. Brown on March 19, 2008

“Don’t let perfect ruin good”

That’s what Harry Beckwith, author of “Selling the Invisible” has to say on the subject. He goes on to say the following:

“You easily can get stalled in the shift from strategy to tactics because you are paralyzed by your desire for excellence”

I see this type of thing all the time in the shift from an ‘idea’ to a ‘plan’ when people get paralyzed by analysis….everyone gets caught up in making the plan perfect (and therefore the realization of the idea) that they don’t actually start anything.

There’s nothing wrong with striving for perfection…but you’ll never reach it so why hold back a project or an idea trying to make it perfect? I say make your plan very good and start executing…you can tweak your plan while executing.  Once you’ve started, you may realize that your original idea was flawed and find a more innovative way to accomplish your goal.

Don’t get caught up in the ‘analysis paralysis’ trap…make a plan that will work, execute on it and then be willing to change at a moments notice. Spend your time (and money) on being more flexible (i.e., agile) rather than crafting the perfect plan.

[tags] planning, agile, seeking perfection [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 5 comments }

Tyner Blain - “Specializing Generalists’

by Eric D. Brown on February 16, 2008

I just read an interesting article at Tyner Blain titled “Specializing Generalists and the Politics of Agile“that is a good follow up to my “Better to be a Generalist or Expert?“article. An excerpt is:

By staffing a team with people who have an area of expertise, but can do anything, you can maximize the value of each delivery cycle. In our example, where all of the tasks for a release are UI tasks, they can be interchangeably assigned to any of the developers. The UI expert may suggest an implementation approach, do code reviews, or provide guidance to all the other developers. But every developer (including the database guy) can sling code effectively to get the job done. Specializing generalists.

Go read the article…very interesting.

[tags] Expert, Generalist, Specialist [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

Experience vs ability

by Eric D. Brown on February 14, 2008

Jeff Attwood over at Coding Horror wrote a great article titled “The Years of Experience Myth” that everyone should add to their ‘must read’ list.

The article discusses the use of phone screens to in the hiring process (and points to a couple of great articles on the topic) but the point of the article pertains to the trap of trying to be overly specific in your hiring.

Jeff writes about the myth of ‘years of experience’ and how many organizations fall into the trap of trying to hire the perfect person. You know the job descriptions that require “7 years experience in J2EE in a manufacaturing environment”. An excerpt from the article is:

This toxic, counterproductive years of experience myth has permeated the software industry for as long as I can remember. Imagine how many brilliant software engineers companies are missing out on because they are completely obsessed with finding people who match– exactly and to the letter– some highly specific laundry list of skills.

Somehow, they’ve forgetten that what software developers do best is learn. Employers should be loooking for passionate, driven, flexible self-educators who have a proven ability to code in whatever language — and serving them up interesting projects they can engage with.

Emphasis mine.

Jeff’s article discusses software engineers specifically but this same issue can be found in any technical area and many other areas. I’ve talked with recruiters and organizations are filter out way too many excellent candidates. For example, the “7 years in J2EE in Manufacturing environment” sample I gave earlier is one that I saw while searching indeed.com (great site btw) for this post. What does someone with 7 years in experience know that someone with 6 years experience doesn’t? Does it really matter that the J2EE experience come from the manufacturing environment?

I’m of the mindset that you hire the best person you can regardless of the number of years of experience that they have. I’m not convinced that someone with 20 years experience is a better hire than someone with 2 years. I’d rather hire the person that will get the job done. As Jeff writes:

Employers should be looking for passionate, driven, flexible self-educators who have a proven ability

Absolutely.

Next time you go to hire someone…look at what they can do and what they have the potential to do; not what they may have done in the past.

[tags] Hiring, Experience vs ability, Coding Horror, Human Resources, Management [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 4 comments }

Follow-up to Employee Onboarding

by Eric D. Brown on September 18, 2007

This post is a follow up to my post titled “Employee Onboarding“.

Research reported on a recent Management Issues article titled “How to lose half your hires within a year” provides a bit more insight into the Employee Onboarding problem in the US. They report (bolded text is my emphasis):

A study by consultancy Novations has found a third of employers report that a quarter of their new hires leave within the first year, while more than a fifth carelessly lose nearly half of their recruits within the same timeframe.

The research, reported by SHRM Online, the website for the Society for Human Resource Management, found fewer than half of employers have a structured programme to help new recruits settle in, or “onboarding” as it is called.

Under a third of employers train their hiring managers in onboarding techniqures, with 15 per cent even leaving it up to their hiring managers to sort out all the paperwork.

Similarly, fewer than half give candidates a realistic job preview or provide interviewers with tools to help them evaluate a candidate’s skills.

While six out of 10 do follow a structured selection process, just 46 per cent establish objective hiring criteria for all open positions.

Can you imagine?

How much money is wasted every year by organizations by selecting employees and then just ‘throwing them to the sharks’.

You can read the SHRM article on this research at “Many Employers Admit They ‘Wing’ Support of New Hires“. Some other interesting stats from the research report are:

  • 57 percent of all those surveyed have never had a performance review, or, if they did have a review, they found it neutral or not useful.
  • 79 percent don’t receive career mentoring.
  • Only 12 percent said their employer offers them a career path plan.

Other articles you may find interesting:

[tags] Organizaitons, Hiring Challenges, Employee Onboarding, Onboarding, Culture [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

What I learned from lifting weights

by Eric D. Brown on September 4, 2007

As some of you may have read in my previous post titled “I’ve been tagged…8 Random Facts“, I used to lift weights and compete as a powerlifter while in high school.

Being a competitive powerlifter (or any competitive athlete) takes a lot of hard work and ‘practice’ although powerlifting doesn’t really require practice like football or baseball, but does require a considerable amount of time in the gym to increase your strength.

When I started lifting weights I didn’t know what I was doing and did what everyone else did. I did a lot of different exercises for different body parts but there wasn’t any focus on an outcome (e.g., get stronger, more agility, etc) …sounds familiar to most organizations these days doesn’t it?

I continued with these unfocused workouts for about a year and never really gained much strength or size and didn’t seem to get any quicker or faster either. I though about it a bit and decided to start studying the science of building muscle and see what it took to build strength and increase speed and/or quickness.

After considerable study, I realized strength didn’t come from overworking all your muscles..it came from a very focused approach to exercise each muscle. I started reading and talking to people and soon realized that spending hours in the gym going from one exercise to the next wasn’t doing what I needed it to do, which was build strength.

After a few months of studying, talking with people and experimenting, I came up with a routine that worked very very well for me. I drastically cut the number of exercises down to just the basics for each type of powerlifting movement (bench press, squat, deadlift) and came up with the following ‘workout rules’ to help guide me in developing my workout plans:

  1. Keep it simple.
  2. Keep it focused.
  3. Constantly Change.
  4. Keep learning.
  5. Keep it short.

After changing my routines to follow these rules, I started seeing a significant increase in my strength and muscle mass. I also went from spending hours in the gym to spending less than an hour working out.

What were the results?

I went from being one of the smallest kids in my class to being a 220 pound ball of muscle. I won two national championships when I was sixteen years old by bench pressing 350 pounds, squatting 575 pounds and deadlifting 500 pounds. In addition, all of this was done without steroids or any other performance enhancing drugs.

Why am I sharing this story?
I’ve used these same ‘rules’ throughout my life with similar success. I’ve adopted these rules to my life and my career to help guide me in the jobs and engagements I’ve been in. They have helped me to keep clients happy and helped me change when I needed to. The rules and reasons to consider using them are:

  1. Keep it simple
    There’s a well known principle in engineering called the KISS (stands for Keep It Simple Stupid) principle. This principle, which states that you should always do the simplest thing possible and avoid complex solutions, has proven invaluable to me during many consulting engagements.
  2. Keep it focused
    Focus is a significant factor in success for a person and organizations. Focus on the customer. Focus on the team. Focus on the project. Focus on the results. When you focus, you bring more energy to the issue at hand.
  3. Constantly Change
    Change is good. While lifting weights, if you continue to do the same exercise over and over, your muscles start to get used to the movement and stop responding to it. You must change to keep your muscles growing. The same is true in all aspects of life. Like most people change does scare me sometimes but I’ve learned that it is a good thing. Change keeps you uncomfortable, which helps you grow.
  4. Keep learning
    I love to learn. When lifting weights, I constantly read everything about weightlifting and working out that I could get my hands on. I read scientific material as well as magazines such as Muscle & Fitness. I love to learn new exercises and new techniques. The same holds true today in my career. I devour books and am usually reading 3 or 4 at a time plus I’m always talking to other people to learn from their experiences. Of course, nothing is as good as experiencing something first hand (e.g., reading about how to fly an aircraft vs. actually flying one) but learning keeps your mind sharp and allows for continuous growth.
  5. Keep it short
    Unlike this blog post (and many others I’ve written lately), I tend to like to keep most things short and to the point. I’ve found that short and sweet is much easier for people to read and comprehend and there is less room for misinterpretation.

I’ve used the above rules to my advantage throughout my career…I like to think they have helped me become the person I am today. I’d be interested in hearing other’s ideas on how these rules (or any others) have helped you in your career.

[tags] powerlifting, focus, learning, simplicity, KISS [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot
  • Reddit

{ 0 comments }

Agile Management

by Eric D. Brown on July 30, 2007

I’ve been doing quite a bit of reading lately on Agile Software Development and Agile Project Management and have come to the conclusion that the folks that created the Manifesto for Agile Software Development could have just as easily named it the Manifesto for Agile Management (with a few minor changes of course).

If you’ve never read the manifesto, please don’t get put off by the Software Development terminology…it’s definitely worth reading.

The main theme of the manifesto is as follows:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

If you take a second to think about it, this can be rewritten as the Manifesto for Agile Management by changing a few words. After rewording, the manifesto is:

Individuals over processes
Engaged teams
over organizational charts
Customer collaboration over contract negotiation
Responding to change over following a plan

If you were able to run an organization business with the Agile Management Manifesto in mind, I truly believe employees would be excited to come to work and clients would love you. Think about how engaged a person would be if they knew that they had the ability to do their job unencumbered (or at least less encumbered) by formal processes that do but impede their ability to deliver value to the client.

I think the Agile Management Manifesto is a great way to run an organization and/or project team.

There seems to be a lot out there in the blogosphere and internet about Agile Management and Agile Leadership…a few interesting and noteworthy posts on the subject can be found at:

[tags] Agile Management, Agile, Lean, Project Management, Leadership [/tags]

Share and Enjoy:
  • E-mail this story to a friend!
  • Digg
  • Google
  • del.icio.us
  • Technorati
  • Facebook
  • LinkedIn
  • Mixx
  • StumbleUpon
  • Live
  • NewsVine
  • Slashdot