Overview

I wrote the following section to provide deeper insight into how I operate as a manager. Too often I have seen examples of one's professional experience compressed down to a single self-praising marketing summary like the paragraph below.

A true IT visionary and student of the technology industry. Repeatedly and consistently led organizations with the adoption of new technology and application of new techniques while minimizing risk. Proven ability to conduct accurate needs analysis, solve problems, assess technical capabilities, conduct strategic planning, build and motivate teams, and manage projects. Widely recognized by employees, peers, management, and consultants as an expert authority on technology matters.

The biggest problem with the statement above is validation. Why is that person considered a visionary? Who can verify the consistency of leadership with new technology? Where is the proven ability to solve problems and motivate teams and how was that accomplished? And most importantly, it does not answer how well that person's management "style" will fit into the management culture of a given corporation.

What follows below is an honest attempt describing how I operate as a manager and some of my views toward an assortment of management related topics.

Qualities

Listed below are a few qualities that I believe most accurately represents my management style.

• Analytically fair - I try my best to suppress any preconceived biases I might have and make decisions based on factual data. Through experience, I have found that fairness reduces the management overhead with resolving inter/intra team conflict and keeps people focused on business value.
• Technically orientated - I spend considerable amounts of time researching job related material and believe it is important to know as much as possible about what it is you do. I also have the same expectation of those who report to me.
• Complete to a degree - I would rather put in 10-20% more effort upfront if it means a higher quality solution. However, I'm at the same time reluctant to put in 50-100% more effort to solve future problems that don't yet exist.
• Responsive - I like to keep my input queue pretty clean. Everyone gets an answer, even if that answer is to say a more complete answer will come later.
• Direct - I tend to answer questions directly without a lot of business speak. My preferred method of communication is written and at a level that is void of ambiguity.
• Aggressive - On a scale of 1 to 10 where 1 would be ultra-cautious and 10 would be ultra-aggressive, I would rate myself about an 8. I actually would like this to be about a 2, but I have not engaged in many situations either in the business world or life in general where you can assume minimal risk and achieve a high level of success.
• Leadership by example - I have found that once I can gain respect from another individual that I am a competent responsible person who has earned my position as their manager, it makes that role easier. This also seems to apply equally to peers and management.

My preference is to work with experienced, can-do people.  I believe smart people with initiative typically come up to speed quickly and know how to overcome obstacles. In training situations, I prefer to create documents to be used as instructional references.

I attempt to use probability based decisions as much as possible. My Dad used to say "You think you can just throw logic at any problem and it can be fixed, but that's not always the case." That maybe true, but it probably works about 95% of the time.  Since I typically deal with technical people, the boundary condition or theoretical position is often presented leading to overly complicating a design.  Sometimes being 100% accurate for 100% of the possibilities is more effort than the return off that effort. You have to almost independently access the cost benefit on every decision. Like horseshoes and hand grenades, close enough many times meets the end goal.

Since I have usually had the privilege of managing highly experienced people, most of those that do report to me participate quite heavily in self-management. My role than becomes more of a leader/enabler than a "do exactly as I say" boss. I prefer to present tasks as larger business requirements and leave the implementation and design details to the individual. That said, I also meet both formally and informally with most of the team on a regular basis. I feel it is important to keep a pulse on what the current status is with projects and help remove obstacles thereby keeping everyone operating as effectively as possible.

My biggest motivation comes from receiving positive results of my ideas or those of the team come to fruition.  I remember getting a extremely brief email one time from a sales representative whom I never met that had just got a hold of a new release of a software product we had just finished.

Subject: The New X.X Release
Message Body: This Rocks! Thanks.

No, Thank you.

Management Thoughts...

Below are some thoughts I have about a variety of management topics.

Communication

It is pretty hard to apply for a job nowadays where you don't see "Excellent Communications" listed in the description.  So how does one know if they are poor, good, or excellent communicator?  Easy, ask someone to read what you have written and critique it. 

I used to think excellent communications (at least the written form) equated to perfect grammatical sentence structure and using a lot of impressive words.  On my quest to become a better written communicator, I dusted off some of my college English and grammar books and engaged in hours of self study.  I think this helped a little, but for some reason not as much as I had hoped.  Plus, it was hard to retain all those rules once I stopped studying.  So while perusing my favorite online library - 24x7 books - I found a book with some excellent, yet simple, advice.  Basically the message was to stop worrying about grammar, and think more about what it is you are trying to communicate.  Huge vocabularies and perfect grammatical sentence structure mean nothing if 75% of your intended audience is missing the point of your message.  So I took this to heart and began my own communication journey. 

Below are some examples of documents I created from my 5 years spent on a Networking Management product.  Yes, the subject matter might be considered a bit dry, but with each I hope to leave the reader with a better understanding of the topic than they had prior to reading the document.

• Application Decodes
• Name Resolution
• VoIP FAQ
• Timing Statistics

A smaller talented team can provide more bang for the same buck

It's pretty obvious that most managers desire all-star teams but often fall short of ever building one. Why this occurs can usually be blamed on two numeric foes: head counts and budgets. Since the budget part never seems to reach unlimited, and top talent usually means more $$s, the manager is forced to fill the team based on the allotted budget which often means compromising a bit on talent. Taking a page from Math 101, if the budget is kept constant, but the head count is reduced, then the money allotted per headcount increases. This suggests if the manager could get by with a smaller team, the quality of each member should be higher than a team comprised of more members paid collectively the same.

Unfortunately, I've discovered some mangers are more concerned with creating fiefdoms over corporate value.  When confronted with potential loss of head count and the status consequences of what a smaller number appearing on an org chart might do to their perceive importance to an organization, most managers will choose to keep the head count. Large head counts are so vital to some managers, it is not all that uncommon for teams to be kept artificially large even when many of the members have virtually nothing to do.

I've never really bought into the "bigger is better" philosophy at least when it comes to team size. What you might gain in prestige points from your management peers can rapidly diminish when it comes to actually getting real projects completed. I have managed teams with as little as 6 highly skilled (and paid) direct reports and achieved a higher output than with other teams with twice the number of members.

In the company I presently work for, there have a title of "Eagle" that applies to a super developer/architect.  One of the listed attributes of an eagle is the ability to accomplish 10 times the work as the average developer.  Well I have worked with eagles on my teams and I not sure about the 10X value, but 3X probably.  The beauty of this arrangement is that eagles don't even make twice as much as the average developer.  So not only do you get more output for the same money, you cut your management overhead as well.  Not to mention there are some assignments just to complicated for the average developer to accomplish.

Be a can-do person

Just because it is easier to say "No" than "Yes" or to deflect an assignment rather than making a commitment to deliver on one, doesn't mean you always should. No one wants to necessarily be over worked, but typically people will like working with you better and respect your ideas and opinions more if you attempt to say yes we can do something or something like it, rather than always saying no. Common excuses as to why a task can't be performed vary but a few of my favorites are listed below:

• I really don't have the resources at this time to undertake any extra work.
• We are all fully committed to the current task at hand and cannot divert our attention to other matters at this time.
• Making those type of changes would introduce significant risk to the project plan and I would advise holding off any further changes until a full impact analysis can be conducted.
• This is really not my problem or responsibility.

This is not to imply that those conditions never exist, but for some people they make their living off of diverting work. In some cases, I've been involved in the person spending more time defending why they cannot perform the task than it actually would have taken them to complete the request.

Being somewhat aggressive toward deliverables and capable of absorbing some risk, I attempt to convey a "can-do" attitude. This is not to say, "Yes, we can do that", is the only utterance I will ever make, but I don't wear Teflon armor either.

Getting your team firing on all cylinders

Efficiency, productivity - how does one get the most quality output from any given team?

Well the first area to tackle is team harmony. Teams with a lot of internal issues typically are not highly productive teams. If there are any issues between any members of the team they must be addressed sooner than later and resolved. If it means ultimately moving individuals to another team or out of the company entirely, then as the Nike slogan says - "Just Do It".  Also a team with minimal to no interpersonal conflicts can spend more time doing actual work not to mention help each other achieve team goals.

Increasing worker output can be accomplished in a couple of ways: have a person work longer hours, or optimize the efficiency at which work is performed. Adding hours is necessary at times, but not the best long-term solution. Just because a person is physically present more hours doesn't mean they are anymore productive. In my opinion, the real key to worker productivity is that the person should "want" to do their tasks as opposed to "having" to do them. It's a bit of utopian thinking of course to assume it is possible to get everyone on a team to love their job so much that if given complete freedom to choose how they would be spending their time, the choice would be doing their current job. But the more they like it, the higher the output. Ways to aid in increasing worker satisfaction are listed below:

• As a manager, never let your ego get in the way of good ideas. Everyone would like to have the most creative ideas and be right all the time, but for people to be motivated to work they need to feel like they are making a contribution. I remember once putting in 3 to 4 days of thought and design work for a particular enhancement and one of my reports came to me and said he thought it should be done differently. After about 1 minute of explanation, it was totally convinced that he had the better idea and that's the direction we pursued.
• On a similar note, don't always take credit for other people's accomplishments.  If someone did a great job then make sure others know about it when they are patting you on the back.  This may ultimately lead to that person getting recruited to another team or position, but that's what will drive other good people to want to work with you. 
• Always listen and try to figure out what will motivate each individual.  Each team member is a person even if they are counted as an interchangeable development resource.  To be effective, you need to understand each individuals working style.

Job Role

Knowing your role should be pretty obvious, but in my 20-some years working for technology companies, this is where I have observed the greatest level of variation.  The first issue is with respect to job title.  In a current article which tabulated IT hiring projections and salaries for 2008, almost half of the sample respondents claimed their title did not match their duties.  Assuming that number is accurate, then is this because people are actually performing the correct job function and the title is wrong, or the title is correct and people are not understanding what is expected of them in that role?

It's hard to know the answer to that question, but I've experience first hand quite a range of "management styles" in my years as a manager.  I've taken part in experiments run at a company where management was put in rotation.  That is, every couple years an executive manager over one part of development was reassigned to another.  During this rotation, my title remained constant.  Now I would have expected some level of consistency from the executive role, but there was very little.  Each manager had their own style and how they operated ran the spectrum.  In one case, there was constant interaction and delegated work assignments.  In another case, there was almost none.  One showed great leadership, a couple others almost none.  Some were focused on strategic direction while others only wanted status on the tactical side.  One had a lab setup in his house where he evaluated all the products under his responsibility, others barely understood what the products did.  All of these people shared the same title and presumably the same role, so were all of these styles acceptable?

My answer to that is no.  No matter what level in the management hierarchy you fall, at the minimum you should provide leadership and direction to those that report to you.  That's not to say you need to tell people what to do all the time, but some guidance is a must.  I feel you also should know a little about the products you have responsibility for.  Maybe setting up a lab in your basement is overkill, but at least read the manuals.  Also, if all you are doing is collecting status and reporting up, then you better be good friends with the CEO or else your days could be numbered.  I realize people are individuals and individuals are unique.  Some are very controlling, demanding and high-strung, while others are less stringent and calm.  But I feel it is important to know your role.  If you are unsure of what that is, ask.  If you want to know if you are providing some tangible value in your position, ask your reports. 

Development Process

Open up any status meeting involving a large amount of developers with the topic - "Today we will discuss our new process for developing software" - and before any explanation can be had, you are likely to get back a collective groan.  Why is this?  Because most developers associate process with everything they don't like about their job.  In the decade I've been managing software teams, never once has a person come up and said - "I really can't wait to provide you with weekly status and time estimates" or "filling in that bloated design template and doing that PowerPoint covering my progress was a blast" or "CMM level III, I can hardly wait until we get to level IV".

Since most developers are not fans of process, why have it?  Two reasons: project management types love it; and two, projects involving more than 3 people can actually benefit from a good one.  It's been my experience that most of the negativity toward process from the development staff has to do with a formal process that doesn't align with how work actually gets done.  And of course the general sentiment that some/much/all of the process adds no value at all.  Process in itself is not the end goal for a development organization, product is.  That's why it is very important to have the most efficient process in place for achieving the highest quality product produced for the lowest cost.

OK, that's a pretty obvious, employ the most efficient process, but how does one do that exactly? First, document what your process really is.  I know this can sometime be scary since executive management may actually believe software projects can be mapped out in Microsoft Project a year in advance and magically meet the delivery date with each developer completing their 10 assignments right on time.  But once the shock of knowing - "it doesn't really work this way" - wears off, some meaningful dialog can really take place.  Next, find a way to measure progress.  And lastly, continually look for optimizations (see CMM does fit in after all).

Presently, the team I'm currently managing is officially using an agile approach to project management.  I say officially, because for the past five years, we were operating under the guise of a waterfall methodology, while actually developing using more of a agile process.  Under the waterfall process, some of our "release definitions" and "project plans" got approval after our development complete dates.  Well, at least it made planning easy.  I'm not necessarily pro-agile and anti-waterfall, but it's nice to have everyone involved with projects all grounded in the reality of how product is really developed.