Leadership

Four things you should know about your technical staff


As a manager of technical projects teams, I have come to make some generalizations about IT people to help you gain a better understanding of the people in your group.

IT pros...

...tend to be introverts

An introvert is someone who is more comfortable with an inward focus in life while an extrovert is generally more comfortable with an outward focus. For example, when introverts receive a lot of new information, they tend to want to think for a while before speaking or drawing conclusions. Extroverts, on the other hand, are more comfortable expressing ideas to others. If they jump to the wrong conclusions, they just change their minds. Basically extroverts are comfortable thinking out loud. Introverts would rather think through the "rough drafts" in their minds and then talk when they think they have a coherent and logical position.

...tend to think more logically than emotionally

This tendency should be obvious. Technical staffers typically are not motivated by a lot of "rah-rah" speeches. In fact, they tend to be cynical of this type of motivation. They will usually listen politely (perhaps even snickering to themselves), but the effects are short-term. On the other hand, they can be persuaded and motivated by a logical argument. If the logical argument can be combined with some motivational techniques, you might have a chance to actually get them excited.

...tend to be problem solvers

This is a strength as well as a weakness. Most technical people love being confronted with a problem. They get excited and immediately start to apply their problem-solving skills. The weakness comes in because they have a tendency to jump on a problem without fully understanding it first. Habits like that can waste resources. In many cases, the technical person will attack a problem immediately, and then have to regroup when they realize they didn't really have a full understanding of the problem to begin with.

...tend to be technically creative

This may seem like a contradiction. Your first thought might be that the sales and marketing staffs are the creative people. In fact they are - in the sales and marketing areas. They will also be the first to tell you so - because they are extroverts. However, the technical discipline requires a fair degree of creativity as well. This is especially true in the IT world. In many cases, there's not one best solution to a business problem. In the development (programming) field, for instance, analysts need to be creative when they're defining a solution with the business clients. Designers need to be creative applying technology in the best manner.

Understanding these general characteristics is the place to start if you manage a technical staff. Once you begin to understand how people work and how they're motivated, you'll find the best way to manage them. In my next blog, I'll look at some techniques for managing IT people effectively.

32 comments
jamie
jamie

On point 3 Many times it is impossible to fully understand a problem, either because the specifications are incomplete or they are continually changing. At most as a developer, you can understand your small piece of the puzzle. Having said that it is still good to be given an overall map of the project landscape (I have been on a couple of projects where you don't get to know where you fit in). The only time you really fully understand the problem is when you are through the other side and looking back at it.

patclem
patclem

Ha! And, they won't do crap unless you convince them why it's important, and how it contributes to something important. So many times I've asked those on my team to do something and I know how important it was and what a big difference it will make, and failed to completely explain the WHY. Of course, they either didn't respond, or they did the bare minimum to keep me from firing them! (not really, but you know what I mean.) Make sure you sell the goal to them.

LocoLobo
LocoLobo

Been there, done that! But sometimes there is no way to fully understand a problem until you have tackled it. Yes, as I get older I tend to try to look at all angles before tackling a problem. But lots of problems need to be studied "hands on". I guess what I'm asking is how do you problem solve? Walk all the way around, kick the tires, lift the hood first? Then test drive it? Or?

jrichardsjm
jrichardsjm

Variety and balance are two of my personal tenets. I agree with the article and just want to add that in organizing a team, it is good to have variety. Situations will occassionally arise where you need a slightly extroverted problem solver, or a strong business minded individual with moderate technical ability. In hiring, I tend now to focus more on identifying persons closer to the middle of these spectra. From recent experience, I would say this has worked extremely well. One take-away from this article should be to use this knowledge to help IT leaders in forming balanced teams.

BukolaA
BukolaA

A nice piece we have here. I have a slight problem agreeing with the third point. If they are deep & logical thinkers, then it sound contradictory that they attack a problem without having a thorough understanding of the problem

peter
peter

Hi Tom, I came upon this posting thanks to a Google Alert, and I just wanted to thank you -- from the bottom of my introverted heart! -- for writing up such an accurate and helpful description about introverts in your post. Too often, introverts are misunderstood as wallflowers or, worse, stuck-up curmudgeons -- which only creates potential conflict from a manager-employee standpoint. It's helpful when someone (like you) who is reaching a lot of readers and thought leaders offers a description illustrating that introverts simply "tick" differently than extraverts. Anyway ... thanks! Peter Vogt Co-Founder Introvert Insights peter@introvertinsights.com www.introvertinsights.com

meryllogue
meryllogue

...but perhaps someone can articulate the cycle correctly: Plan, Execute, Check, Plan, Execute, Check... it's only supposed to be four, but I don't remember them exacdtly.

alaniane
alaniane

it seems that the problem lies with you and not your staff. If the project you want them to do really is important then you should have no problem explaining why it is important. What I find a lot is that someone comes up with a pet project that they feel is extremely important; however, they have never bothered to evaluate the project to see why it is important. The project gets implemented and then discarded because it turns out that it was not so important after all.

Tony Hopkinson
Tony Hopkinson

Somtimes a bosses 'ideas' are impossible, sometimes they are impossibly stupid, sometimes they are impractical without more resources, the rest of the time they get done. Which ever one it is, you seem to be struggling to communicate to your people, remember that takes at least two people. ! You do have to get the big picture across and you do have to remebber if you want buy in, they at least haave to believe the idea is of some benefit to them....

Jaqui
Jaqui

the goal is the project, if you get the interest in the project then any side issues are accepted as a part of it. just set your standards for quality very high on everything. That way your team are used to creating high quality and it is habit, not something you have to work to get out of them.

Oracle Architect
Oracle Architect

Not at all. Software techs tend to start solving a problem before either understanding it -- or the solution -- completely. I've been in this business for 39 years (an elder of the Geek tribe) and I've seen incredibly few techies who think completely through a problem before trying to solve it. And the best problem solvers can't even articulate how they came to their conclusions. Part of them is off thinking through the problem while another part is off solving it. It's a gift and curse. You never really stop thinking about the work.

geoff.baxter
geoff.baxter

a.."Oh, this rabbit hole looks interesting" b.."Explain 'project schedule' to me again" c.."I'll definitely have it done by tomorrow" (never admit defeat; never ask for help) d.."I thought 'project communication' was something to do with IP addresses" e.."There are other tasks in the project?" - "and they're depending on me?" f.."Explain this 'documentation' concept to me once more"? g.."What's 'business expectation' and what's it got to do with me?"

sudeep
sudeep

When the goal is the project and the standards are set high, if everyone give same 100%, yes you don't need to work towards motivating your team... But in 15 years, I saw more 60% than 100% in any projects. But again, I did not work on 10 year projects where 2 years is spent in discussions, 4 years in design, 2 years in execution and 2 year implementation.. Standards can go high towards end of the project if a technical lead work on the team. Cant expect it to happen naturally..

BukolaA
BukolaA

Hearing from one that is 39 years in the business.... lots of respect. It just got clearer that it's just a trend of doing all it takes to getting the problem sorted. I find myself several times getting the solution and then trying to flash back on how I arrivd there. As several posts explained, its a combination of having the right mix in the team, and some form of control to minimise wastage of resources & time. I agree......its a gift and a curse

drowningnotwaving
drowningnotwaving

... would, of course, depend upon the problem actually being defined in its entirety. For example, the business department / users actually having a clear and insightful understanding of their need. ROTF Hee ha hah ha ha hhheee ha ha hah hah! :) One may suggest that any development team that sat around waiting for that phenomenon to occur would have strong skills in Table Tennis or some other time-filling activity. It would be rare that they need concern themselves with solving that kind of problem!

DonSMau
DonSMau

As natural pattern-matchers, techos read/hear the problem description and see the solution(s) before they have even finished the paragraph. The little dears can't wait to get stuck into it and whip out some code. Their enthusiasm does need to be tempered by patience ... but being impatient is not a characteristic only of techos.

Tony Hopkinson
Tony Hopkinson

never meet the deadlines set by people who can't even describe the problem and wouldn't know how to even start solving it. The main reason it's called software engineering is because our job is to solve problems, understanding them is a bonus feature that explains why the solution worked. :D 39 years, a year to your next undiscovered incompetence badge, I got my first three months ago. :D

Jaqui
Jaqui

try having a visual problem solving technique and explaining that. ]:) I literally get images of solution options flashing through my mind until I get one that will work.

mark2631
mark2631

While Tom's points are valid in GENERAL - the realtiy is as you've described. Their problem-solving can turn into "gold plating" or "rabbit holes" without very close supervision. The other attributes are also a mixed blessing.

Shellbot
Shellbot

as i cannot tell from the tone, was that meant to be sarcastic or amusing ?

Tony Hopkinson
Tony Hopkinson

a useful deliverable at a maximum of every three months, and then review the goal(s) in light of where you are now and where you think you want to be now. Otherwise you end up with an expensive well designed white elephant at best. The business reasons behind a softwaee project with nebulous requirements are usually just as nebulous.

drowningnotwaving
drowningnotwaving

In 1986 IBM sent an internal memo throughout the internal development community (certainly throughout the Asia-Pac and EMEA regions; I can't comment on the US) to the effect that NO internal development project was to be undertaken if it could not be concluded within 12 months. The reason was that, in the internal experience, the chances of a successful outcome and a cost-benefit being achieved in longer projects was severely compromised, by changing requirements, changing environments, personnel movements etc etc etc. This concern for quality and a successful outcome has clearly not been replicated in the IBM customer environment such as GS !! Let's face it, successfully concluding projects are sometimes considered the antithesis of high billable percentages and ratios.

Timbo Zimbabwe
Timbo Zimbabwe

"and they can spot a condescending, pompous, chest-thumper of a manager from over-the-horizon. The obvious solution is retaliation: do what it takes to get on his nerves." WTF are you rambling about? Oh, sorry, now I see the problem; Oceanside, CA.

kijanka
kijanka

...and they can spot a condescending, pompous, chest-thumper of a manager from over-the-horizon. The obvious solution is retaliation: do what it takes to get on his nerves.

tripsma
tripsma

You got dat right....

almostfm
almostfm

A former co-workers described one of our project managers this way--"He doesn't know what he wants, until we give him what he asked for."

alaniane
alaniane

project managers have a tendency to be very vague about what they want. I have seen specs flip-flop weekly because the pm does not know what the users want. In some cases I have to had to bypass the pm altogether to just get workable specs. Of course that pm is no longer employed here.

kijanka
kijanka

I'll say it again: Bunk! What you describe are the attributes of an undisciplined, immature, amateur. When you go for young, inexperienced, and cheap staff, you deserve what you get. There are plenty of mature *professionals* in the IT field who don't fall into those traps. If you can't find them, it's because you don't want to pay for a professional level of work. If the people around you consistently fall into those traps, it's your own fault: you hired them.

geoff.baxter
geoff.baxter

hey, I ran those past some of our techies and they laughed (then went silent for a brief moment of inner reflection)... then it was straight to the Coke vending machine and back to work as usual. Got to luv 'em....