Amazon.com Widgets Leadership

Rock-n-Roll Leadership

By Nick at December 09, 2012 11:03
Filed Under: Leadership

Who ever knew that the great .38 Special held the secret to a good leadership viewpoint?

Just hold on loosely
But don't let her go
If you cling too tightly
You're gonna lose control

Hold on Loosely” by .38 Special

That simple lyric holds a valuable viewpoint for leaders. The song, of course, is about a girl.  But imagine you are holding a small bird in your hand.  If you hold the bird too tightly, you’ll crush it.  If you hold the bird too loosely, it will escape. But if you hold it just right, not too loosely and not too tightly, then the bird will stay in your hand, and maybe even feel safe.  And if you focus on it, it’s probably not too hard to figure out just the right amount of pressure to keep the bird in your grasp.

It’s the same way with leadership.  One of the toughest decisions leaders make is how much control to exert over their people.  It’s a delicate balance.  Both too much and too little can cause difficulties and cause you to lose your team.  Finding just the right amount of control is a large challenge. 

The tendency of many leaders is to “cling too tightly”.  They tend to want to have close control over their people.  They want to make sure every little detail is taken care of, setting rules, procedures, and processes for every little thing to ensure that things never get out of control.  They view their people as merely cogs in machine, and thus give them little autonomy to make decision, innovate, improvise, and otherwise come up with their own solutions.  They make every decision, ensuring (in their minds) that things are going perfectly.

There is a word for this – micro-management.  No one ever thinks that they are being a micro-manager.  In my experience, the more a leader micro-manages, the more he thinks he isn’t.  Micro-managers tend to think that they are providing leadership because it’s needed, because their team can’t be trusted, or, sadly, because they think that their team is simply incompetent to do the job.  Or perhaps they feel that they have to be involved in order to get the credit.

Whatever the reason, a leader who clings too tightly is being ineffective and usually has a negative effect on her team.  People feel the lack of trust, and that’s demoralizing.  Teams that are given little autonomy soon lose their desire to improve and find better ways to do things.  When their leader has all the answers and always knows what is best, why even try?

But holding on too loosely can have a similar effect.  If a team feels that their leader can’t make decisions or is wishy-washy, then they feel adrift and unsure.  No one likes a ship captain who doesn’t know where the ship should be going.  And a ship that is headed nowhere will surely get there.  Not making any decisions is no better than making all the decisions.

The trick or course, is to hold with just the right amount of pressure.  Good leaders find that perfect balance between control and chaos.  They let their team decide how to accomplish tasks within general guidelines.  They encourage improvisation and innovation in a search for better ways of doing things.  They know that there are some things that need to be done a certain way, but that there are many things that don’t.  They trust their team to get things done their own way. They know that if a team member gets credit, it reflects positively on their leadership. 

In general, they hold just tightly enough to keep things in control.  They let team members make decisions.  They recognize that mistakes will be made and that daring to do something different is a feature, not a bug.  They make decisions when the team needs a decision, and they delegate decisions as much as possible.  They recognize that they have a tendency to “squeeze to tightly” and thus, when in doubt, tend to err on the side of holding too loosely.  They understand that autonomy and self-direction are very satisfying, and do everything they can to provide that to their team. 

Just as a good veterinarian knows how to hold a bird with the right amount of pressure, a good leader knows the precise amount of control to exert over his team.

Blast from the Past: Takes One to Know One

By Nick at November 25, 2012 13:15
Filed Under: Delphi, Leadership, Software Development, TechBiz

This one is a Blast from the Past -- I originally wrote and posted it on December 15, 2005 -- but it is as true today as it was then.  I even considered palming it off as fresh material. Smile

It's a standard Dilbert joke that managers are idiots.  One doesn't have to hang around programmers too long to find out that many of them work for managers that don't have a clue about developing software and thus make many a nutty decision based on profound ignorance.  Plenty of  Delphi fans have had a boss that follows the "Nobody ever got fired for choosing Microsoft Development tools" rule and choose Visual Basic as a corporate standard. <shudder>  And the old adage states that programmers make crappy managers.

So, I guess, based on the above, it's impossible for someone to be a good manager of programmers.  If one doesn't know anything about programming and has never been a programmer, then apparently, he will suck as a manager.  And if one has been a programmer, and is so good at it that he gets promoted to be a manager, he,too, will suck as a manager.  Sounds like a lose/lose situation all around --   programmers doomed to a life of sucky supervisors.

Well, I'm not buying it.  Surely somewhere, somebody is managing programmers well.  Somebody has to be leading folks to build some of the insanely good software projects that are going on out there.  So, what does it take to manage programmers well?  Good question.  I'd say that such skills and capabilities exist.  I'd also say that they are, sadly, in relatively short supply.  Too many Dilbert strips end up on too many cubicles in software development shops.

First, to be a good manager of programmers you have to be,well, a good manager.  That's easier than people think, really.  Here's my basic list of things one can do and not do to be a good manager:

  • Place the careers of the people that work for you above your own.  Never, ever, ever, ever, ever take a dump on an employee to make yourself look good to your boss.  Always let the boss take a dump on you instead of your employee. Take responsibility for everything bad that happens under your watch.  Dole out all the credit for good things that happen to your people.  If you have some bizarre, overwhelming need to impress and brown-nose your boss, let your employees make you look good.  It's your job to make your employees happy and productive.  It's not your job to get promoted.  (And do I need to say that if your employees are happy and motivated, then they'll do a good job, which means you are doing a good job?)
  • Place the needs of the employees over your own.  What's the quickest way for a Marine Corps officer to be considered the biggest jerk since Josef Stalin? Get in the chow line ahead of his Marines.  Officers don't eat until the troops do.  Take the same attitude, and your people will love you and work hard for you.  Give them the good computers.  Give them the good chairs.  Don't take a perk for yourself until they all have it.  Believe me -- they will notice this.  Another way to state this is don't ask your employees to do anything you yourself aren't willing to do. If you want your folks to work 12 hours a day, you need to be there 13 hours a day.
  • Recognize that your employees know what they are talking about and might actually know more about some things than you do.  (If they don't know what they are talking about and they don't know more about some things than you do,  then you need to get new employees).  If your employees seem to think that the WonderWidget is a much better solution to a problem than the SuperSprocket, then, hey,  maybe, just maybe, they are right.  Just because you read about the SuperSprocket in some magazine that takes $4.6 million dollars a year in advertising from SuperSprocket, Inc., doesn't mean that is the way to go. 
  • As a follow on to that, don't try to impress your employees with your knowledge.  Don't spout buzzwords unless you know what they mean. They probably are going to think that you are an idiot anyway, so feel free to appear to be ignorant about things that, well, you are ignorant about.  If you don't have a clue about what the best printer is for the needs of your team, then let the folks on your team that do know about such things choose the printer.  If you don't know the answer to something, say so.  The quickest way to be thought an idiot is to try to act like you know what you are talking about when you don't.
  • Manage yourself out of  a job.  The best managers are the ones that sit in their office all day surfing the internet because they've set things up so that their people can take care of everything and thus they don't have anything to do.  People love being the ones with the power, authority and skill to do the work. If you are in their shorts all day, making all the decisions, doing all the work, and taking all the credit, you will be a crappy manager.  Once you've managed yourself out of a job, then, besides surfing the net, you can spend all your time making things even better for your employees and protecting them from the foibles of your boss. 
  • Encourage your employees to tell you what is bugging them.  When I was running a 24/7 Intelligence Watch, I told my people that if they found a Dilbert cartoon that exactly described a stupid, irritating, or aggravating situation in our organization or something that I was doing that was "pointy-haired-boss-ish", they could bring it to me or put it on my desk anonymously.  If you are totally committed to the first two items on this list, they will come to you. If you aren't, they never will.  And if your employees aren't bringing issues and complaints and problems to you, then you have a big problem.
  • Reward your employees with what they want to be rewarded with.  Frankly, this is usually good old cash money. But if you can't do that,  perhaps they want better computers, a nicer desk chair, a day off, whatever.  If you want to reward someone, find out what they want and give it to them.  But please, PLEASE -- I'm begging you here -- do not call a big meeting and pass out a "Worker of the Week" award with some cheesy certificate ginned up with Microsoft Publisher.  When I was in the Navy and at a joint command, I had an Air Force Colonel that did this, and he was universally mocked and reviled for it. Everyone thought it was a joke.  No one wanted that silly certificate and everyone hoped and prayed that they wouldn't "win" the thing.  Those that did posted them like they post Dilbert cartoons on their cubicles -- sort of like a badge of "dishonor".

Now, that's all general stuff.  It applies to all managers, whether they lead a team of auto workers or a group of Delphi programmers.  What does it take to manage programmers well?

  • I think that to be a good manager of programmers, you have to be, or at least have been, a programmer yourself.  This goes against the conventional wisdom, I know, but I think that in order to understand the way programmers work, you really have to have done it yourself.  It's true that many programmers would make bad managers, but it doesn't follow that every programmer guarantees that one will be a bad manager.  Programming is one of those strange professions that mixes right- and left-brained skills.  To program well, you have to have an ordered, mathematically oriented mind, but at the same time you have to come up with artistic, creative solutions to puzzles and problems.  One really needs to be one to understand one.  Now the hard part here is that most programmers don't want to be managers. Alas -- a quandry there, eh?  Well, if you run across one thatdoes, don't hesitate to consider it.  If you are a programmer and want to be a manager, let your bosses know, they'll probably be happy to hear it.
  • Give programmers what they want:  challenging work, a quite place to do that work, a good fast computer, a good salary, and the opportunity to expand their skillset.  Don't be cheap on these things.  This may cost a bit more,but you'll make it back in spades.
  • To as large a degree as possible, let programmers choose the tools that they use.  I know, I know, this isn't always possible.  Sometimes those decisions are made above your pay grade.  But then again, if you use Delphi under the table to produce a solution twice as fast for half the cost, then maybe Delphi won't be under the table for long.  If one of your guys wants to try to build that new intranet application in Ruby On Rails, let him.  Why not? Who's going to know?  If it works and gets deployed early, it's likely that no one will care what tool or language was used to make it, and now you have a new skill in your quiver.
  • Be flexible.  Some programmers do their best work between 10:00pm and 04:00am.  Let them.  Some hate to wear ties, dress shirts, khakis, etc.  Don't make them.  Some are flat out nuts.  Let them be.  Nothing wrong with all of that as long as they produce good code, eh?

Okay, that's a pretty good list.  I've been on both sides of the fence, and as a consultant, I see all sorts of management types and methods.  I deal with programmers on a daily basis, and I are one myself, so I think I have a pretty good grip on what's going on from a lot of angles.  I'm sure you all will come up with more stuff and comment on it.  Please do.  After all, I'm not an expert on this stuff and I only write this to try to make you look good.  ;-)

Measuring Developer Productivity

By Nick at November 11, 2012 03:19
Filed Under: Delphi, Leadership, Software Development

Introduction

If you go to Google and search for "measuring software developer productivity" you will find a whole lot of nothing. Seriously -- nothing.

Well, okay, not exactly nothing. You'll get a ton of links. But almost all of the links you find will talk about how measuring the productivity of software developers can't be done effectively. Some people will even argue that it shouldn't be attempted at all. Some others will describe techniques to measure developer productivity, that, well, everyone else knows don't really work.

There have been many valiant attempts to measure developer productivity, but all seem to end in less than successful territory. (We all know to laugh at "Lines of Code" as a productivity measure). Virtually any objective measurement you can apply to the software development process can be "gamed" into submission.

There are just too many variables to account for everything that goes into the development process. Measuring any one of them, or even a combination of them, simply cannot begin to capture effectively everything that is involved. You can't pick a surrogate thing to measure, but because of human nature, developers will react in ways that will skew the measurement.

Many studies have been done on this topic, with little to show for it. Every software development manager who has to fill out a developer's evaluation or determine who gets bonuses has struggled with this. Many a leading expert and guru has thought about and researched this thorny topic.

Experts Agree

And not one of the experts has come up with a good idea or method to measure individual productivity. There are plenty of good and effective ideas on measuring team and project productivity, but there is a severe if not complete shortage of ways to measure individual performance and productivity.

For instance, Robert D. Austin wrote an entire book on this subject called Measuring and Managing Performance in Organizations and came to the conclusion that unless you can measure 100% of something -- that is, every aspect of it -- then there is no point in measuring at all. If you attempt to measure less than 100% of the things involved in a given activity, you will get what he refers to as "dysfunction", or what you and I might call gaming the system. And since software development is an incredibly complex and creative endeavor, it's virtually impossible to measure every aspect of it. Often it quite literally involves sitting and staring at a computer screen. How do you measure the productivity of that?

Here's Martin Fowler's conclusion in an article he entitles " CannotMeasureProductivity":

"This is somewhere I think we have to admit to our ignorance."

Neil McAllister of InfoWorld writes in an article entitled " The futility of developer productivity metrics"

"For most other companies, however, it might be best simply to forget about the idea of measuring developer productivity and rely instead on tried and true methods. That's right: A highly effective, productive developer workforce is often the result of high-quality, effective management. Unfortunately, nobody has developed a metric for that yet. Coincidence?"

Joel Spolsky writes:

"It's rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it's very hard to get concrete data on large projects because it's very rare for two programmers to be told to do the same thing."

Steve McConnell, a widely regarded academic, author, and consultant says:

"So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects."

Like I said, it's hard to find a leading expert making the case for objective measurements, and easy to find plenty that say you shouldn't even try.

So I don't think that it's a tough leap to agree that there is no objective way to measure productivity in software developers. I know this is controversial, but it seems quite clear to me that software is more art than science, and measuring productivity in art is, well, simply not done. One does not tell Michelangelo that it took him too long to paint the Sistine Chapel because he should have been painting 1.4 square feet per day instead of 1.2. That would be preposterous.

So, What Are We to Do?

Anyone who is charged with managing and leading developers is left in a quandary. We want to be fair, but if everything is subjective, how can we be?

The fact that there is no objective measure of developer productivity doesn't mean you can't measure it. It just means that you have to measure it subjectively . And we do that, don't we. You can look around your shop and just know who the productive developers are. There are probably developers you know that simply crank out good code faster and fix bugs more efficiently than the rest. For ease of discussion, I'll give this developer the name "Jason".

And just how do you know Jason is more productive and more valuable? You just do. You can just tell. You know it when you see it. But if you stop and think about it, Jason has some characteristics that you can figure out and write down.

What I mean is that if you stop and examine Jason and his work, there are things that you can say about him that describe what he is all about. They are subjective, sure, but you can write them down and give an "objective" measure to these subjective things.

A Modest Proposal

So yeah, what I am proposing is a way to measure developer productivity and value via a subjective set of measurements. Think of it as a way to qualify the notion of "you just know that Jason is productive".

Here is the list:

  • Productivity
    • Does the developer get a reasonable amount of work done in a given period of time?
    • Is the developer's velocity on bug fixing sufficient?
  • Engagement
    • Is the developer dedicated to his/her craft?
    • Is the developer committed to delivering software on time?
    • Is the developer dedicated to company success?
  • Attention to Quality
    • To what degree does the developer's code work as designed?
    • Does the developer thoroughly test code and believe it to be correct before checking it in?
    • Do a minimal number of bugs get reported against his/her code?
    • Does the developer write unit tests for all new code?
    • Does the developer follow the Boy Scout Rule and leave a module cleaner than it was before he or she worked on it?
  • Code Base Knowledge and Management
    • To what degree does the developer understand the code base assigned to him/her?
    • Does the developer take responsibility for his/her team's code base, improving it at every opportunity?
  • Adherence to coding guidelines and techniques
    • Does developer's code routinely meet coding standards?
    • Do code reviews reveal a minimum of problems and discrepancies?
    • Does the developer use Dependency Injection to ensure decoupled code?
  • Learning and Skills
    • Is the developer constantly learning and improving his/her skills?
    • Does the developer show a passion for the craft of software development?
  • Personal Responsibility
    • Does the developer first assume that the error lies within his or her code?
    • Does the developer understand that he or she is solely responsible for their code working correctly?
    • Does the developer take pride in their code, ensuring it is clean, tested, easy to read, and easy to maintain?

Again, these seven items are all subjective measurements. All the questions require the evaluator to make subjective judgments. But a good lead/manager is presumably in their position because of their good judgment about such things, and so they should be able to make fair and accurate assessments about Jason's productivity using these "measurements".

Most of the questions ask for a yes or no answer, but all can spark a discussion with management or even the developer being evaluated. You could use these measures on a formal evaluation form. Whatever you do with them, it's probably better than the "just know it when I see it" approach you are probably taking now.

Conclusion

In the end, any evaluation, judgement, or other assessment of the productivity or value of a single developer will be subjective. No one has yet found an objective way to measure individual productivity in our excessively complex profession. But I am saying that it is possible to qualify and make judgments about a specific set of criteria as a small and humble step towards being able to do the thing that our industry has so far found very difficult.

My suggestion is that we accept reality and embrace the subjectivity -- and lack of objectivity -- in measuring developer performance.

On the EULA and the Delphi Community

By Nick at September 02, 2012 13:24
Filed Under: Delphi, Leadership, Personal

I won’t rehash the details of the recent “EULA Incident”.  You can read about it for yourselves in the newsgroups or on various blogs and comments.

I want to talk, instead, about the reaction, response, and behavior of some of the community to the event.

First, I’m well aware that because on the internet no one knows you are a dog, people feel free to behave in ways they never would in person.  I have been as guilty as anyone of this over the years, though I daresay that I like to think that I’ve become self-aware about the issue and been a much  better online citizen over the past few years.  However, being on the internet isn’t an excuse to be rude, offensive, and, well, a jerk.

And frankly, the response to the EULA issue by the Delphi community was shameful.  Seriously.  It wasn’t a rational discussion, it was a witch hunt.  I’ll not weigh in on the issue at all other than to say that I was glad to see Embarcadero respond to the uproar by deciding not to make the change.  And when I expressed that sentiment, I was pretty aggressively attacked for apparently not participating in what I called the “public flogging”.  And then I was aggressively attacked for calling it a public flogging.

And it was a public flogging.  It couldn’t even remotely be described as a professional discussion.  I understand that the proposed but never adopted change would have had a rather profound effect on many people.  But even so, that is simply not an excuse for meanness and vitriol.

Why am I writing this? Well, because I consider David Intersimone one of the finest men I’ve ever known and a good friend.  He is kind, gentle, smart beyond reason, and very, very dedicated to the Delphi community.  And for the Delphi community – whom he has served so well for many, many years – to treat him so badly was, well, very, very painful for me to see.  DavidI didn’t even remotely deserve the treatment he got, and those of you who were so unpleasant to him should be ashamed of yourselves. 

They say “All’s well that ends well”.  The Delphi XE3 EULA controversy apparently is ending well. 

But the Delphi community’s treatment of its longest and dearest friend did not end well at all.

Tweet Expansion: Butt Time and Brain Time

By Nick at April 29, 2012 08:53
Filed Under: Delphi, Leadership, Software Development, Tweet Expansion

A while back I tweeted the following:

In software development, we often measure Butt Time, when what we need from developers is Brain Time -- which is much harder to measure.

Some tweets call for further explanation and expansion, and so I’ve added a new category called Tweet Expansion to cover posts that do just that.

Here at Gateway Ticketing, we have an interesting development and business model.  At our core, we are an ISV.  We sell a software package that we build to customers.  But, we also will customize our software to meet customer specifications.  That makes us sort of a VAR to our own product.  Thus, we do both enhancements based on customer requests and our own internal product development projects to make our product more valuable in the marketplace. 

This distinction – between internal projects and projects driven by specific customer requirements – makes for some challenging project management.  But we have a solid team here at Gateway, and we make it all work.  But because we do work that amounts to us being consultants, we end up having to closely track our developer time.  We do that for a number of business reasons, the main one, of course, is profitability.  You need to track your time to ensure that you are actually making money on a given endeavor.

Now I know that no one really likes to track their time.  It’s a pain.  It’s challenging to be accurate.  It’s hard to get time properly categorized.  But it is also invaluable for making those important business decisions. 

But there is a bigger problem with measuring time.  The only thing you can really measure is “Butt Time”.  Butt Time is the actual amount of time someone has their butt in a chair while working on an issue.  You need Butt Time to get any work done, of course.

But Butt Time isn’t really what you want from your developers.  Butt Time isn’t at all equivalent to productive development time.  Butt Time includes reading email, answering questions and generally handling any number of interruptions, meetings, and other distractions.  And those distractions, however minor, break a developer’s concentration.

And when you get right down to it, development is all about concentration.  With a coding project of any size at all, doing development requires your complete focus and concentration.  You need to build up complex data structures and patterns in your mind in order to really be productive.  Doing so takes time --  I’ve heard it described as building a house of cards in your mind.  Building that house of cards can take upwards of fifteen minutes depending upon the project.  But here’s the bummer:  It only takes a second for that house of cards to come tumbling down.  One distraction can make your fifteen minute investment disappear. 

And of course, time spent in “The Zone” – with that house of cards constructed and true, highly productive work getting done – is what we all are seeking.  We’ve all probably had that awesome experience of getting into that zone for hours at a time and wondering where the time went.  We know how cool that is – and how precious.  That’s what we want to measure – Brain Time.

But that’s a really hard thing to do.  Getting accurate, meaningful Butt Time measurements is difficult enough.  But how in the world can you actually measure Brain Time?

I’ll argue that you really can’t.  In the end, Butt Time is only a poor proxy for Brain Time.  What we need to do is to try to increase the Butt Time to Brain Time ratio by providing an environment where Brain Time is maximized as a percentage of total Butt Time.

There are ways to do that – ensuring that your developers have an office with a door that they can close is an important first step.  The book Peopleware is really the Bible for this, and Joel Spolsky has talked a lot about it as well.  Uninterrupted quite time is the key.  Leaving developers alone is the key to maximizing Brain Time.

Seriously – you need to get and read Peopleware if you have anything at all to do with leading developers.  This is the definitive book on managing software developers.  Be sure to get the Second Edition.  The physical book is, I believe, out of print, causing the price to be pretty high,  but I was delighted to notice that you can now order it on the Kindle

Another thing we need to do is to respect – indeed, celebrate – those developers that are quiet and don’t say much.  We have a not small number of developers here at Gateway that, well, don’t say much at all.  They come to work, write great code, and go home.  They don’t have a lot to say.  But sadly, we don’t always respect this.  I’m as guilty of anyone of too often saying super-clever things like “Stop being so boisterous, Meredith” or “Did you say six words today?”, instead of recognizing that Meredith is maximizing her Brain Time and, by being quiet, not breaking other team members’ concentration.  Being quiet is a very valuable virtue in a software developer – both because they themselves are being productive and they aren’t breaking other’s concentration -- and we should give honor and respect to that.

Butt Time is easy to come by and fairly easy to measure.  Brain Time, however, is a precious and hard to measure commodity that needs to be nurtured and respected.

Listening

By Nick at December 12, 2010 05:23
Filed Under: Leadership

Imagine this (it shouldn’t be all that hard):  You are a widget manufacturer.  You’ve been tasked to figure out how to make 1000 widgets.  You’ve been planning for weeks.  You’ve gathered data, run the numbers, made estimates, and come up with a plan you believe in. You’ve left a little wiggle room for inevitable unknown obstacles.  You’ve put it all into MS Project and up on the screen in Powerpoint slides.  You are an experienced team – you’ve done this all before many times --  and the guys doing the work are battle-hardened  veterans who know their business.  Everything looks good.

Now it’s time to present your plan to the executive team. You lay everything out in a Powerpoint presentation that you’ve reviewed seventeen times.  But when they hear the plan, they say:  “Sorry, but that’s all wrong.  You say you can make 1000 widgets in fourteen months.  We say it only takes eight months to make that many widgets.  Get to work”.

Terrific.

Now you and your team know how long it will take to make 1000 widgets – 14 months.  But somehow your “leadership” has decided that it only takes much less time than that.  Never mind that these guys have only been with the company for a year or so, and have no real experience with the difficulties and the process of building 1000 widgets.  They are the bosses and their style of “leadership” seems to be to assert their all-knowing authority over the guys who actually know what is going on.  It seems to them that “leadership” means being a hard-ass and “pushing” the team to get more out of them than is possible.  Bottom line:  They didn’t listen and they didn’t trust you.  Why did they ask you to do all that planning when they were just going to tell you the schedule anyway?

We all know what happens next: after about seven months, it becomes hopelessly, overwhelmingly, manifestly clear that there is not going be 1000 widgets on the loading dock in a month.  Now everyone is scrambling to adjust course.  This, naturally, is a vastly worse situation than if they had merely planned on the 1000 widgets being available in 14 months from the start. Or agreed to make the number 500 in seven months instead.

True leaders listen to their people and believe them.  Good people tell you the truth they know they will be trusted.  The last thing you want to do is create a situation where your folks start “gaming” you and telling you what they think you want to hear.  This is a direct result of not trusting them.

If you are a leader and you don’t believe what you are being told, then it is overwhelmingly likely that you are the one with the problem.  You either need to radically change what you are doing or get new people – and again, it is very, very likely that you are the one that needs to change, not your people.  And if you have the wrong people, that is probably your fault, too.

The people in the trenches are the ones closest to the issue, and they know best what is happening “on the ground”.  Believe them, and you can adjust your plans and needs accordingly from the start.  Don’t believe them, and your plans will get adjusted anyway.  You can’t  make a baby with three women in three months, and if your plan requires that you do that, your plan is in trouble no matter how much of a hard-ass you are.  And the team knows that you can’t get a baby in three months, and they will be the ones who suffer for a bad plan.  They learn not to trust you and their morale goes into the tank.

Building and maintaining trust in both directions is a critical requirement for a good leader.  Trusting your people will engender their trust in you. It’s a virtuous circle.  Sometimes you even need to trust them even when they are wrong to help build future trust and to show that you believe in them.  If they trust you, they’ll follow you. Their morale will be up.  They’ll do the extra work and they’ll put in the effort because they want to.  People who are trusted and believed do that as a matter of course.

And isn’t that what we want our folks to do?

A Tale of Two Companies

By Nick at October 22, 2010 07:49
Filed Under: Leadership

I had two very interesting conversations this week. I’ll describe them, and then I’ll have a question for you at the end.

First Story

Here at Gateway, we have a top notch Human resources (HR) Department.  I’m normally very wary of HR – especially given my recent experiences – but our folks here are great. They are squared away, generally concerned about all the employees, and they are very helpful and welcoming to new hires, me included. 

One of HR’s roles is recruiting, and we are actively working to find developers and QA people.  Earlier this week, I was meeting with one of our HR people on that topic, and she was telling me about being excited that she and her husband were buying their first  house.  They are a young couple with a baby, and so getting their first house is a big milestone.  However, there was a snag:  her husband couldn’t get the day off for their closing date.  And here’s the kicker – her husband works at a bank!  You’d think that a bank would now what a big, exciting, life-changing event a house closing is, but I guess he couldn’t get the day off for it. 

Second Story

One thing that happens for all new hires here is that we get an orientation from the two owner/founders.  They tell us how the company was founded, how it grew, what the company core values are, etc.  It is a really cool thing, because you see that our owners really value the company and us as employees.  One of the things that they stressed – and something that has been clear to me even before I started here – is that they really want to create a “job for themselves”; that is, a place where they themselves want to work.  That drives much of their decision-making about benefits, compensation, etc. 

Okay, so to follow up on that.   Two weeks ago, we had a new part-time developer start here.  She’s an interesting case – she’s got a Masters in CS but hasn’t had a job for the last eight years because she was a full-time mom.  Both of her kids are now in school, so she decided to re-enter the work force on a part-time basis.  She’s had her eye on Gateway Ticketing for a while as one of the few software development companies in the area, and we were very happy to find a skilled, capable developer to add to our staff.  It’s working out great for everyone. 

So, being “the boss”, I stopped by to see how things were going.  I asked her how her kids were doing, and she said they were fine – her hours are such that she is there when the get on and off the bus – but that they were concerned that she would have a meeting or something that would keep her from meeting them.  With great pleasure, I told her that there was nothing going on here – no meeting, no task, nothing – that was more important than her meeting her kids at the bus.  Why did I tell her that? Because I have kids, and I know that that is how I’d want the company to react if I were in her shoes. It was great to put that company value into action.  And our new hire seemed pleased to know that the company felt that way.

Okay, so now the question I mentioned up top:  Which company would you rather work for – Gateway Ticketing or that bank?

The End of the Chow Line

By Nick at July 29, 2010 12:55
Filed Under: Leadership

There is a very strong and steadfast rule in the United States Marine Corps:  Officers go to the end of the chow line.  No self-respecting Marine officer would ever think about getting in the chow line ahead of his troops.  He’ll make sure that every single guy, from the lowest Private up to his own Lieutenants get fed before he takes a bite.  It’s only right – rank hath its privileges, but rank also ensures that the men are taken care of before he is.

This is a tradition as old as the Marines.  One of the primary responsibilities of a leader is to see to the “health and welfare” of those under him.  The needs of the leader should be secondary to the needs of the troops.  Troops that see you at the end of the chow line know that you are placing them above yourself.  They’ll follow you. They know that if you are wise enough to let them eat first, you are wise enough to take care of them in other areas. Officers that “pull rank” and barge to the front are saying “I’m more important and I don’t care about you.”.  People don’t want to follow that kind of “leader”.

This same attitude can – and should – translate over to the “regular” world.  Do you have a better, more powerful computer than your guys?  Did you take the first widescreen monitor for yourself?  Do you order in sandwiches for the executive team when they meet over lunch, but don’t do the same for your team who work evenings and weekends?

A leader should ensure that his team has the best equipment.  As a manager, you are mainly doing email and web surfing, with maybe the occasional spreadsheet.  For those of you in the software development business, your developers are doing builds, running complex IDE’s and debuggers, etc.  That is, they are doing the things that require processing horsepower.  If you are taking the hot new machines and the big monitors because “I’m the boss”, well, you are jumping the chow line.  The productivity of your team, not to mention the morale boost from seeing that you put their needs above yours, are well worth you working with an adequate machine. 

So you want to be a good leader and have people follow you and be part of the team?  Get at the end of the chow line.

Credit Where Credit is Due

By Nick at July 23, 2010 02:54
Filed Under: Leadership

When I was in the Navy, a large part of my job was to provide daily briefings to a senior officer.  Very often that senior officer was of flag rank (an Admiral or a General).  It is the job of intelligence guys to keep an eye on things and make sure that the decision makers had the latest information.  That usually took the form of a daily briefing.  Intelligence is a 24/7 business, and so I would have a team working overnight to prepare a briefing every morning at, say 0700.  I usually ended up giving the briefings, because the average enlisted guy doesn’t want to stand up in front of the “big brass”. 

Now, this is a leadership “two-fer”.   First, you get to take credit with your team for “taking the bullet” and being the one to stand up in front of the man, give the briefing and fielding the hard questions.  Second, you can use this as an opportunity for giving credit where credit is due.

Few things can be more frustrating for a team than when the boss takes all the credit for the team’s work.  This has happened to you, I’ll bet.  You come up with an idea.  The idea is shot down.  And then two weeks later, your boss repeats that idea right back to you as if he thought it up.  Or you find out later that he told his boss your idea as if it were his own.  Good leaders have strong egos and don’t need to steal ideas. Instead, if they pass the idea up the chain, they go out of their way to give you credit for it.

Thus when giving those morning briefings, I never passed up an opportunity to give credit where credit was due.  I often tried to work in phrases like “As a result of the excellent analysis done by Petty Officer Johnstone….” or “I don’t know, General, but I know that Chief Lyle has the answer.”    This went a long way.  My team (who was sitting in the back of the room) could see clearly that I knew they were doing good work and that I didn’t want to take credit for what they had done. 

Some people might hesitate to do this because they think that they look bad if they don’t know everything themselves.  Nothing could be further from the truth.  The most effective leaders are the ones that nurture and develop effective people.  By giving credit where credit is due, you show that your entire team (led by you, remember) is up to the task.  Your team sees that their work is appreciated and recognized.  They see their boss standing up for them and promoting them. This engenders loyalty, trust, and more hard work.

That’s a win for everyone.

Leadership

By Nick at July 21, 2010 16:09
Filed Under: Leadership

One of the things that I want to do on this blog is to talk about leadership.

I’ve had a lot of experience with leadership.  I was an officer in the US Navy for twelve years, and as such I had many opportunities to both lead and be led.  I’ve also been both an observer and an actual leader and manager in the software business. In both worlds, I’ve seen how critical good leadership is, and how easy it is to be terrible at it.

I’ve been led by some great leaders and by some really bad leaders. Since I knew that I would some day be leading people, I spent a lot of time thinking on and contemplating leadership – you can hardly be an officer in the Navy without doing so.  Paradoxically, it is the bad leaders that taught me the most about leadership and what it means to be an effective leader.  By seeing (and suffering under) the actions of a poor leader – these things generally fell into the category of caring more about themselves than their people – gave me a strong sense of “I’m never going to do that!”, which then, in turn, helped me to figure out what the right thing to do is.  Don’t get me wrong, I’ve served under some fine leaders and emulating them is something I try to do, but it is the leaders that weren’t good at leading that really taught me the most. 

Now I’m not claiming to be a great leader – I don’t think that’s the case. But I do think that I’ve had a modicum of success as one, and I think that I have a few nuggets of wisdom to pass on to you fine people.  I’ll be drawing on a lot of my military experiences as well as those in the software industry to share my thoughts.

So pursuant to that,  I’ve created a “Leadership” category here in the blog, and you can follow that tag here if you want.  I won’t be blogging exclusively about Leadership – you might be surprised to find out that I have a lot to say about a lot of things (shocking, I know) --  but I do have a lot of thoughts on the matter that I feel compelled to share.

My Book

A Pithy Quote for You

"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid."    –  Albert Einstein

Amazon Gift Cards

General Disclaimer

The views I express here are entirely my own and not necessarily those of any other rational person or organization.  However, I strongly recommend that you agree with pretty much everything I say because, well, I'm right.  Most of the time. Except when I'm not, in which case, you shouldn't agree with me.