Take, for example, the software project in trouble.  In manufacturing, each person involved in the job is responsible for overall success.  When the machines are being set up prior to starting to make something, the setup men are responsible for noting when something is wrong with the tooling and letting people know.  Before the line starts up, the setup men and the line leader are responsible for running a test run and validating that they are building the right thing, that it meets specifications, and that there is nothing wrong with the end result before they waste the company’s money building thousands of wrong widgets.  Once the line starts up, each worker is responsible for stopping the process if they discover something wrong.  Toyota and other manufacturers have been famous since the 80s for the ubiquitous “quality line”, the magic line that any worker can pull and is responsible to pull if they see that the process has gone off the tracks.  Manufacturing knows that the longer you wait to address a problem, the more it costs, and that you are better off to stop and fix things and miss your deadline than you are to deliver the wrong thing.

Not so in the software world. The industry is rife with discussion on the topic.  New articles pop up online.  Depending on who you read, the Project Manager is responsible, the development manager is responsible, the BA is responsible, the list goes on and on.  Some (rightly) declare that, like in Manufacturing, everyone is responsible.

One could debate this all day long, but the reality is, we’re all asking the wrong question.  People want to do good work (unless they’re just worthless employees).  They want to do the right thing.  They don’t like to waste their time.  Everyone is willing to declare that projects are going down the wrong path if it is the right thing to do.  Assuming you believe that about your employees (and if you don’t, you have the wrong staff), why do they not pull the line?  Why is not pulling the line an epidemic in software development and project management?

The answer is because corporate leadership is teaching us all that pulling the line is wrong.  Leadership shoots the messenger 99 times out of 100.  The Death March must continue.  No one wants to tell the customer we’ll be late.  We’re teaching our workers through an almost Pavlovian punishment model that somehow the customer will be happier if we deliver a half-working thing that isn’t what they asked for instead.  This is driven by a lot of things- fear of conflict with the customer (pretending there won’t be conflict when we deliver garbage), fear of telling the stockholders (pretending the stock isn’t affected by delivering garbage), fear of trying to stop the inertia or being called a finger pointer (pretending that if someone has screwed up and not taken responsibility for it, the finger should not be pointed).

Of all the problems in corporate culture today, this, more than any other, needs to change.  In the last fifteen years I have changed companies a half-dozen times.  A number of my friends have changed jobs as many as a dozen.  In almost every case, the root cause has traced back to this.  Company leadership refuses to face their problems and shoots messengers until either the company folds or so many projects fail that there is a significant purge of personnel within the company.  You will never, ever deliver the right thing until you enable your employees to be able to stop delivering the wrong thing.  If you are a corporate leader out there today, ask yourself some questions:

• Do I have a culture in my company where people can pull the line without fear?
• Do I even have a line?  Is there a true, properly managed process for raising the red flag on projects with appropriate visibility?
• Do people know the process for raising red flags?  Is making sure they know how part of project kickoff and project management?
• Is the process effective?  Are there actual action items can be addressed as a result of the red flag process?  Are they monitored and followed through on?
• Do I have a REWARD system for raising the flag?  If raising the flag saves me from wasting money, why on earth not?
• If I am responsible for leading, is it not ultimately my fault if we fail due to flags not raised?  Isn’t my own career ultimately on the line here?

There is a popular saying in the corporate IT world that has always amused me:  ”No one was ever fired for buying IBM.”  We live in a risk-adverse culture where the main risk we avoid is conflict.  I challenge you to address this problem and pound the solution home until you overhear this in meetings in your company instead:  ”No one was ever promoted for covering up problems”.

Today I’m going to talk about a less comfortable subject- the value of your various customers.  Or, more specifically, the value of each market segment.  Do you understand the following about the markets you are trying to address:

• How many customers are there in each market?
• How much revenue will you gain per customer?  How much profit?
• What does the acquisition cost per customer look like?  What is the lead time?
• Does the costs to address the full needs of each market provide enough money to make that market worthwhile?
• Is the market for new feature X or bug Y important enough to pay for the cost or addressing the feature?

Knowing and understanding these numbers is a critical component of planning and prioritizing your backlog.  You must plan not only to take care of your customers, but to use the company’s resources responsibly.  With limited resources, some of your customers will simply have to wait for certain things.  Working like this will help your product make more money faster, allow it to grow available resources to fix problems and build new features, and get everyone what they want faster.  In some cases, it may lead to a counter-intuitive business decision- accepting that the cost to maintain your product in market X is not worth the value of the market in the foreseeable future.

This may sound like the old “Where do you see yourself in five years” interview question, but it’s something everyone should reflect on from time to time.  The old adage “If you don’t know where you’re going, you’ll end up standing still” is very true.

One of the best and most underutilized methods to work towards your career goals is the Mentor.  Finding someone who’s been there, done that, who can and will offer you guidance.  I personally never bothered with this for many years; I was convinced that somehow I was different (which maybe I was), and so their experience wasn’t that applicable to me (which is foolish; where they were is where I wanted to be).

The simple truth is that if you want to get somewhere in life, if there’s people you know who you admire or admire their success, the best way to learn how to get where they are is simply to ask and see advice.  This may seem awkward, and if you’ve chosen the wrong mentor, then it will be.  A good mentor, especially for a leadership role, is the kind of person who nurtures success in others.  The right mentor for you will be happy to help you.

The second major hurdle with mentors is this:  Great, I have a mentor, what do I do now?  What do I ask?  How does this work?

Pamela Trunk over at the Brazen Careerist blog has a good article related to this entitled “How I got my current favorite mentor“.  All of her points are good ones; my favorite (which I must admit was originally pointed out over at Lifehacker) is to ask “What should I be asking now?”  Remember, your mentor has been the road you’re trying to walk.  Little in business is truly unique rocketscience.  They can assess where you are, what you need to know next, and will lead you the right direction- even when you don’t know where to begin.

While the relationship isn’t formal, I have a mentor now- several, in fact, but a primary one, and it’s extremely valuable to me and where I want to go.  There’s certain areas of my career that I need to grow that I can learn about talking to my mentor in a simple conversation; the same learning would take me ages on my own to stumble in to.  The value is tremendous.  If you don’t have a mentor, seek one out.

Let’s assume you succeed at what you’re doing.  What do you need next?  Most likely, you need to do what you are doing better, cheaper, and in a repeatable fashion.  Why not prepare for a successful tomorrow now, while your company or project is small enough that you don’t have to fight the inertia of its size to implement process?  You need to organize your business processes. Document them. Figure out your retention policies for information. Organize your information smartly, and in a documented way. Automate when you can do so. Don’t spend huge time or money on any of it, but be sure to do it. Why?

1) Someday your company will grow. You will hire new employees to do these tasks you do yourself right now. Documented processes will help you transfer these processes to them more easily.

2) Someday you will hire new management in your company. These people will manage the processes that you are doing now. If they can be improved upon, you of course will want the new managers to do so. Will their changes be better? If you do not document your processes *and* your lessons learned, they may take steps backwards. They may re-make mistakes already made in the past and cost your company money. A well-documented process not only explains the process, but explains why the process is the way it is. This will help others improve these processes in a more efficient manner.

3) Someday your company will have an information management problem. If you are successful, I guarantee it. It will either consist of a) you stuffed essentially the same information in a dozen places and don’t know which version is right, b) you have so much information you can’t find what you need, or c) you have bits of information in twenty different databases, and you need them all in one. Customer information is a fine example of this. You’ll have sales databases, marketing databases, customer service databases, and everything in between. If you plan well now, you’ll have everything you need in the right place at the right time.

If you want to understand better, pick up a copy of CIO magazine. Read articles from Gartner or Forrester. Look at them to see what problems that CIOs in big companies are trying to solve. They are all trying to solve how to organize information, how to get it in the hands of the business, how to automate processes that no one knows the details of. You can cut these problems off now by thinking ahead. When your business hits its stride, you will have an advantage. Your company will know what its doing, have access to its data better and faster, and be able to devote its IT department to things that enhance the company, not fix the company.

POSTED BY Stacey Douglas ON

Getting stakeholders involved, though, is a difficult task. It requires constant communication- but not too much communication. It requires dealing with many different groups which have different, varied and occasionally opposing interests in your project. Here’s some advice on involving stakeholders:

1) Get all stakeholders involved as is reasonably possible in your project. You need their input and their support. Their input will make your project better in the long run. Giving them a say will help get their support, which will help you get your project complete on time and successfully.

2) There is no valid reason to exclude any stakeholder from your project (no matter how much of a pain they may be). If the project affects them, they deserve a say. They also can add value if engaged properly.

3) Stakeholders do not need to be involved 100% of the time. In fact, most of them have other job duties which are designed to take up their entire work day. Trying to involve them full-time will make you a pest. Recognize when is the right time to involve them and make sure they’re there. The rest of the time, let them do their jobs.

4) Stakeholders *do* need to be involved regularly in some way, even if it’s only sending them a status of the project with notes relevent to their interest. Notice I said relevent to their interest. You must involve stakeholders at some level regularly to keep enough of their attention engaged. If you lose their attention, you will have trouble getting their help later on. Only involving them in relevent tasks and sending them relevent information is important because you don’t want to bore or confuse them. Remember, you want their interest. Work to get it, but also take care not to waste it.

Remember, the best way to gain access to stakeholders and get help from stakeholders is to keep their interest and attention. Never waste their time with details that do not matter to them. You want to show them that the time you receive from them is valuable to you. If their time is valuable to you, then what you are doing with their time (that is, accomplishing your project) will seem valuable to them.

1. Have an itemized plan of things to accomplish and talk about in the meeting.  Don’t leave without at least talking about each item constructively.
2. Create a parking lot.  Use it.  When things get off track, push things (tactfully) onto the parking lot.  Keep on target.
3. Never end a meeting with hanging tasks.  If tasks or action items come out of your meeting, make certain to review who is responsible for carrying out that task and when it is due.  This is the worst kind of dangling meeting participle- everyone agrees that something must be done, but no one owns the item when they leave, no due date is due, etc, and thus nothing gets done.  The result?  The meeting is a waste.

Follow these simple points, and you’ll never waste another meeting.

1) Make a list of all of your responsibilities in your current position.

2) Do the same for all skills needed, then all relationships.

3) Go through each one, item by item, and apply a simple self-evaluation.  What do I do well?  What do I not?  For the things I don’t do well, what is it about them that I don’t do well?

4) Write a plan of action for each item defining what you believe will make you improve.  Make the plan smart- simple, measurable, and objective.  Do it like a project plan- write a scope, create task list, organize into ordered task list, then move on to a project schedule.

5) Set priorities, organize your project plans as you would any other program portfolio of projects, and execute the plan.

It’s that simple.  Will it make you a perfect manager?  No.  Will it make you a better one?  Absolutely.  The key is to take intelligent, measured action.  Take action and follow up on it daily.  The effort of thinking about it, the effort of following your plan, and the effort of holding yourself accountable to your plans will make you change what you are doing for the better.  Too many times, we want to improve, but we end up so busy that we fall back to the familiar, we fall back into our old patterns- and that gets us nowhere.

There’s of course many things you can do to expand on this- ask others to review you on your task list and provide feedback, for example, create a blog and be public about your accountability to your plan (nothing like the pressure of the public eye to keep you on track), or a hundred other things.

However you do this, do it now.  Take action.  Today.

That being the case, how easy is it for your partners to get rid of you? If they were unhappy with your product, what would they have to do to change roads?

This sounds like a suicidal thought to consider. Why would you want it to be easy for customers to go to the competition?

Hear me out before you get the tar and feathers. Strong business relationships are built on trust and mutual advantage. Customer relationships are equally built on trust and mutual advantage. Both of these are reasons to make it easy for your customers/partners to walk away if they need to do so.

Not good enough? How about your reputation? If you want to scare away new customers, just let one horror story about how bad it is to migrate away from your product to get out. Never mind just getting out. In the current era of the ‘blogosphere’, one story can turn into 10,000 seperate articles and opinion pieces blossoming on the internet inside of a week. Nevermind that it’s all over five cases of a problem. When customers research you, they’re likely to do something like this:

1) Open web browser.
2) Go to google.
3) Type in your product name.
4) Hit enter.
5) Read an entire first page of hits from websites that sound like unhappy customers and/or bad reviews of your product.
6) Click an article at random.
7) Read a horror story about how your product is a nightmare to uninstall and/or get the customer’s data out of and how badly your product is engineered, complete with at least one link (probably to another blog) promising more horror stories.
Close browser and call your competitor.

Sound like a problem you should worry about now?

No one wants a customer to leave their product line. The fact is, though, that if a customer chooses to leave your product line, they will probably do so anyway. Someone else’s saleman is going to have sold them already on how easy it is to migrate to their products. When it’s not so easy to do, they’re going to blame your product and feel relieved that they left you. They will use this as justification for their decision, and thank the new vendor for saving them.

If you are compliant with the latest standards, have good export tools, and otherwise think through how to migrate away from your product if needed, then you insulate yourself from this. Maybe the customer trying to migrate might not understand, and maybe they’ll believe the competitor’s salesman, but once the story starts to float around, some experts are going to get ahold of your product and the exports, and they’re going to come to your defense. Ease of migration will become a reason to praise your product.

This is also a sell point for you.  Fear of lock-in is a real problem for your sales force.  Everyone’s bought at least one technology product that they hated.  They also went through the pain of getting their data out of it.  Fear of lock-in and painful migrations will keep them from buying. Being able to show your customer how to get themselves free if they are unhappy is a marvelous sell point. Demonstrate your migration tools, show them how you make them safe from you, and you will remove the number one ‘but’ against buying your product. This automatically puts you way ahead of the competition.

Third, this makes life easier for you over time. Need to overhaul your product line? Do the new features of your next product generation require a complete reinstall? Sticking with standards in migration tools keep your options, and the options you offer your customers on upgrading, more flexible. If your customers can get their information out easily, you can do more radical things if necessary to upgrade your product lines, and it will be easier for your customers to stick with you.

The ability to leave your product is in fact a strong trust-building tool. Trust and credibility sells in today’s economy. Don’t sabotage a terrific tool for yourself with your own fears about your customers’ plans.

“Best Practices” are one of the most overused words in business. The theory behind them is sound: identify the best way of doing a given task, then spread that knowledge so that all instances of this task can be optimized. It is a good idea, and I highly recommend it. I recommend, however, that you think carefully about these pitfalls before adopting any given Best Practice:

1) Never assume the “industry” is smarter than you are. It is just possible that the “Best Practice” of the rest of the industry is one of the differences between your company and everyone else that gives you a competitive advantage!

2) Never assume that the Best Practices of others apply to your unique business model. Many people write “Best Practices” and distribute them online or through print, but these folks often do not know your business model. They are speaking based on the business models that they are familiar with.

3) Never assume that the Best Practice you have adopted is the best there will ever be. Implementing a policy of using Best Practices is a perpetual cycle of improvement and change. Whenever a new idea appears, always hear it out and weigh it against what you do today.

Amazingly enough, project management, IT and in particular IT Security are the most succeptible groups to adopting the Best Practices of others. Consider security as an example: if your data is protected the same way that everyone else’s is, then all a criminal has to do is find a security exploit for one company, and they have the keys to everyone’s doors. Never be satisfied with just “what everyone else says is best”.

Best Practices are indeed a very good idea in any business. Never forget this rule, though: If you do things the same way that everyone else does, the only difference is the people performing the task. You are betting that your people are better than the next guy, and that they always will be. Your people are fluid, though; they get promoted, hired away, burn out, sometimes they even retire. Don’t be satisfied. Innovate. Improve your processes every day. Never stop looking for a better way.

The reason to bother is obvious:  to note things worth remembering.  Most projects span a considerable amount of time.  Building a new piece of software can span months or years.  People also usually are involved in multiple projects.  Remembering the details of each project is a real challenge.  When confusion eventually sets in on what was decided, who said what, who committed to do what, and so on, meeting notes become invaluable.

Considering that, when is the last time you reviewed your meeting notes?  Who is writing them?  Are they capturing all of the valid points?  Are they capturing all of the decisions made?  The commitments?  Are they capturing any details that you don’t remember happening?  If so, are you following up on those details to ensure that they’re valid?

He who writes history defines history.  So too with meeting notes.  Once enough time has past that people do not remember every detail of a given meeting, it’s meeting notes become reality, not the meeting itself.  Set up a regular time each week to review meeting notes from that week and ensure accuracy.  Commit to spend 30 minutes once a week to read everything.  Add addendums as needed and check all points that you have questions on for validity.  If you don’t, it can bite you later.

Transparency can be a double-edged sword.  There are aspects of any process that may be par for the course, but to an outsider, look like unmanaged, undisciplined chaos.  Watch any of the “reality show” series like Mythbusters or Junkyard Wars, where people build very complex things very quickly, and you’ll see what I mean.  The team that looks under control sometimes is not, and vice versa.

This is particularly true in software development, where developers often debate the hows of solving a problem until just the right detail shows up; where it’s hard to commit to a final deadline or even an order in which you will do things until the last detail shows up, where what appears to be small detail changes to the outsider can lead to huge changes in the software.  A good friend of mine refers to this process as “making the sausage”.  Most people love sausage; if they saw how it was made or what went into it, they wouldn’t be able to eat it.

So if transparency is so dangerous, why is everyone doing it?  Why shouldn’t we run from it?  Why aren’t projects falling apart all over the business world globally because of it?  The truth is that some are.  Like all tools, before you can use Transparency to its fullest potential, you need to understand what it’s for and what you are trying to do with it.  if you use it incorrectly, it will hinder rather than help.

Transparency lends value in two important ways:  it spreads useful information, and it builds trust between groups.  There are two key words there:  useful information, and trust.  These are actually very easy to apply here if you think about it:  information people do not understand is not useful.  People do not trust things that they do not understand.  Also, in the category of trust, no one trusts anything or anyone that surprises them in a negative way.

Drawing from this, we can apply a set of simple do’s and don’t's to Transparency to make it work better:

• Do share anything that is a roadblock.  Never let people get surprised when your team runs into trouble.
• Do summarize wherever possible.  Keep things in terms that all teams understand.  Ditch jargon.
• Do be prepared to explain details, especially related to roadblocks.
• Do be prepared to rate the amount of trouble the roadblock really is- people fear the unknown; quantify it where possible.
• Do not share details for the sake of sharing them, unless you’re specifically having some type of true learning session.  Respect people’s limits in how much data that they can take on a time.  If you bury people in information, they’ll miss the important parts you share.  Make sure the most important details are always at the top.
• Do be prepared for that there will be times that too much detail comes out, and you’ll have to handle it.  A lot of people are problem-solvers in the business world.  That’s what we all do.  If you get too much detail in front of them related to a problem, they will want to dig into it.  This is a delicate balance, because often the time you take explaining what’s going on just contributes to delaying the solution and contributes to your frustration.  On the other hand, not explaining enough frustrates the people you are sharing with- and it can make them feel you’re hiding things from them.  This is one of the slippery slopes of Transparency where you can build stronger trust, or you can do a lot of damage.
• Do not make shared decisions in a vacuum unless you have no choice.  Once you open things up, you hurt trust when you start leaving people out.

There’s a lot of other things to consider, but the bottom line is Transparency is about building Trust.  Follow your instincts around building Trust and respecting people’s time.

What about operations?  How does this fit in?

The reality of most companies is that they do not have seperate project-based resources versus operations-based resources.  Major operational initiatives and problems can derail your project quickly.  An over-abundance of projects can rob Operations so thoroughly that needed maintenance is ignored, and your operations deteriorate (just ask the american government about this).  Major operational problems clash with major project initiatives.  Huge political battles can ensue, creating inaction as people who need to do do the work in question instead go sit in meetings waiting for a decision on which work to do.  People end up making decisions on an island at times, just picking a direction based on their own personal knowledge rather than wait on the corporate machine to find a direction.

Rather than get lost in these situations, get a grip on your Operations.  Include them in the resource planning process.  Most importantly, include them in your prioritization process.  Is the most important project in the company more important than maintenance of the most important existing product?  What about the fifth most important product?  The fifteenth?  Which customers’ business is more important than your projects?  Customer problems can just as easily steal resources.  Not all of your customers will be more important than the development of your company’s future either.  You have to count them as part of your prioritization process, and you have to make hard decisions like this.

Doing this type of process is hard.  It is also vital to your company’s ability to react quickly and decisively to the unexpected.  You, and more importantly, your team, need to understand and agree on what comes first.

Often times I’ve seen this… someone asks for a solution for a simple problem.  During design, the designers say “and it really should do this” and the customer says “and it would be great if it did that”, and so on, and so on… and soon, you’ve spent a year in design, you panicked six months earlier and started developing, and the prototypes just made it worse, as more ideas creep in…

Or, even worse- you hit Acceptance Testing with the business, and now that they’ve seen the product, they have a dozen ideas as to new things that should be in there- and not only do they not like the product you’ve built now, because they like their new ideas better, they don’t even want to accept what you’ve built, even though it is to spec.

This scenario is often handled by effective scope management.  What do you do, though, when the new ideas are within scope?  There’s more to this than simply managing scope.  There’s keeping the buy-in to your project.  There’s the perceived success or failure.

My advice?  Keep bringing the customer (or designer, or anyone else involved) back to the main reason you are building this.  Remind people of the business problem that led to this project being started, and why the project needs to stay on scope and on schedule.  Assure them that getting them what they asked for is the real goal here.  Their new ideas are just that- new ideas, and they can be addressed, but doing it now will put off their real goal.

People fail to keep their eye on the ball sometimes.  Sometimes you have to remind them to hit the ball first, before they take off running for the home run.

I want to try this with some projects, but I also see value in it operationally.  For example, I want to try this with my development teams:

Imagine this scenario:  we just released the next major version of the product.  It was a spectacular failure.  The business is angry.  The customers are ringing the phone off the hook.  We completely blew the schedule to boot.  What things do you think went wrong to cause it?

I plan to open things up to suggestions as to what went wrong, write them down on the whiteboard, then we’ll have a problem-solving session on what we can do to prevent these things from happening.  I am hoping to come out of it with some significant process improvements.

This is a great tool in my opinion.  Post-mortems sometimes turn into blame sessions.  They also bring forth observations which would have been valuable before the project was underway, but now are of less value.  People also sometimes have trouble projecting what they learned forward- they see what went wrong, they resolve to ‘never do it again’, then they fail to apply what they learned to the next project, because it seems like a different situation.  If you run through a pre-mortem, then when people see the problems named in the same situation that they imagined the problems, the ‘lesson learned’ will instantly applicable and easy to relate to the problem.  I recommend trying this before taking on any major project or repeatable process.

Never deny your company’s problems.  Do not dwell on them either, of course.  Solve them.  Put together teams.  Recruit ideas.  Keep them out in the open, on the table.  Can you imagine a company where the business devoted all of the necessary resources to solving its business problems?  Can you imagine what it would be like to work in such a place?

I can.  I just can’t imagine what the market ceiling would be like at such a place.  The sky would be the limit.  Employees would be motivated by the progress.  Work would get done faster.  Processes would improve more and more each day.  Employee loyalty and devotion would be up.

What I can’t imagine is why people aren’t doing this.  What are the problems in your company?  Can you name them?  Can you name who is responsible for solving them?

If you can’t, doesn’t that worry you?

Communicating the Big Picture to your employees matters. It matters to your bottom line a lot more than you think. There’s two reasons for this.

The first reason is employee security and trust. In our modern (unfortunately debt-ridden) society, workers have a lot of pressure on them at home. They need their income and their jobs. They need to be made to feel secure about their jobs and the companies that provides them. When management doesn’t communicate with employees, employees often fear that there’s a good reason why. They start to think bad things are in the works. They start to gossip more in their search for information and work less. They distrust management more and more. They search for jobs. They quit and move to greener pastures. Even the employees who stay around do poorer work and feel more anxiety. They don’t know where the company is going, what its goals are, and therefore they don’t understand which way to run or do their work. Without knowing what the company values and wants, they don’t even know if they’re doing a good job or what their job performance is being judged based on.

The second reason is employee productivity. Employees that understand how what they do fits into the Big Picture will usually do a much better job at fulfilling their roles in that picture. They know what the company wants and is measuring them by, and they can concentrate their efforts better. Knowledge breeds confidence, security, and being included makes them feel more like a part of something greater. It’s fundamental to building the team that is your company.

1. Under-pricing
2. Over-committing
3. Failing to Sell (failure to demonstrate how you  or your service is truly valuable)
4. Always Saying Yes
5. Not Following Up

I would argue that this may also be five of the biggest mistakes that any business, any department, or even any individual in a given business makes.  Failing to do any of these things with your clients- whether your client is a coworker, another department, or a customer- are all things that can lead to your long-term failure.  They are all mistakes that damage your reputation, your integrity, and your perceived value.

Ask yourself now- am I guilty of any of these things?  Is my department?  Is my business?  What is the effect it is having?  How can I turn things around?

How so?  Let’s reimagine the seven points of their article from a leadership perspective:

1.  Keeping Stress to Yourself

Your team should not be burdened with your problems.  For example, what your budget looks like is not their problem.  The implications of the budget are- how many resources you can afford, what raises will look like this year, how much overtime they have to work, etc.  So too with your project status report- while they may be interested in the results of the report, the fact that you’re late on producing it is not their problem.  Complaining to them about your problems just undermines your own credibility as an effective leader who can deal with whatever problems your team has.  After all, if you can’t solve your problems, why should I believe that you can solve mine?  Or the company’s?

Manage the implications of your problems- don’t set your problems in their lap.  As with raising kids, keep your time with them about them- how the project is going, what problems they have, what can be done to improve things within the constraints that the team has to work under.

2.  Leading by Example

This one should be obvious.  You cannot expect employees to do as you say if you don’t follow your own advice.  If you’re chronically late to work, don’t expect to see everyone on time and there waiting for you every morning.

A good leader demonstrates accountability, credibility, reliability, and the behaviors that the leader desires to see in each and every team member.

3.  Being Consistent

This goes hand in hand with #2.  If you don’t do as you say and follow your own rules, you cannot expect others to do so.

4.  Staying Involved

Your people face problems that they often do not feel that you (or anyone else) can relate to.  Talk to them.  Get involved.  Often you can bring something to the table that helps them.  Even if you can’t, being involved with them and showing support makes them feel important, that what they do is important, and these things breed confidence and more effective action within your team.

5.  Scheduling Family Recreation

Family Recreation?  How does that apply?  This is where team building activities come into play- doing things from time to time togetherother than work to help your people socialize, get to know each other, and interact more.  Research has shown that people work better with others at work when they feel a level of friendship.  Do things to promote this among your team- whether its buying everyone pizza and giving them a little downtime to chat, going out for a team activity, or whatever works best for you.  One note of advice:  keep it informal.  Things like company picnics are too large and too formal to truly ‘team-build’.  People are not themselves when you get more than one exec involved in their activities.

6.  Teaching

Mentoring is a key part of leadership.  You got to be the leader because you have learned important lessons along the way.  Share these things with your team.

7.  Creating Family Rituals

Creating Family Rituals?  Rituals?  At work?

No, not rituals- expectations and standards.  Make mantras that reflect the values you want to see in your team, then demonstrate those mantras in your every day actions.  Provide positive examples.  Create processes to make things better and then follow those processes yourself.

The value of a great leader, unlike a great father, is almost never overlooked- companies value leaders.  The right steps to exhibiting leadership in a company, however, are often lost in the shuffle of endless deadlines and commitments of the modern workplace.  A good leader makes everyone around him better.  Don’t lose sight of these principles.

This does not mean, however, that you can’t bring someone onto your staff quickly, efficiently, and get them up to speed in the fastest method reasonably possible.  Here’s a few simple steps that will go a long way.

1.  Necessities First

Most folks get this part at least partly right.  Show them to their desk.  Show them where the bathrooms are, the copy machines, the break room.  Don’t forget the other essentials too:  where the mail room is, where they get office supplies, where the benefits folks are, where the helpdesk is, where their timesheet and expense report info is at.

2.  Put Them In Touch

Give them a desk.  Have their computer, their email, and their phone ready.  Also have a phone list and an org chart ready for them, at least of their own department and their own project team.  This way, they can get in touch with who they need to once they get started.

3.  Have Their Research Ready

Have their network access set up and ready so that they can reach all of the necessary documentation on their initial projects.  They’ll have a lot of catching up to do.

4.  Use the Buddy System

Assign them two mentors- one is for their project and their new job.  This person is probably very busy, as they are often also the person who has to compensate for the new person while they get on their feet.  The second person you assign is the culture mentor.  This person knows what most of the company acronoyms mean, the culture, who to contact when you need this and that.  They’re not an expert on the new person’s job; they’re just an expert to help them understand what’s going on, who to talk to, when, where, and how.

5.  Summarize

The new person obviously needs to understand each project they’re assigned to.  Give them a copy of the project charter for each project and the latest status reports.  More than that though, they need to understand their overall place in things.  Ask their boss, their boss’s boss, and up the chain to write a simple one paragraph to one page summary of their goals and expectations.  You don’t have to do this for every new hire; if your organization makes it a practice that every member of management write this once per quarter or once per year even, it will help a lot.  Your new team members will be able to read these and understand where each member of the chain of command sees their organization going, which in turn tells them where the company is going.

Take the time to build this level of preparedness within your company.  If you can do so, and maintain it, you’ll find that when you do bring someone new on board, they’ll be able to get up to speed and be valuable much more quickly.