Posted on

Fortune Favors the Brave

Something in Bill Gate’s interview has been hanging with me (see quote below).  I suppose he always says this, whether they are making risky bets or not.  And I suppose Microsoft can make risky bets all the time.  They can afford to.

We’re making sure we take some risky bets.

 

What’s hanging with me is the effect that ricky moves have on small companies.  The first thing to understand is that risk produces reward, just like the Roman poet Virgil said in 19 BC.  “Fortune favors the brave.”  That’s nice to know.  Its a special promise, just for the brave.  Not for the weak and fearful.

But that fortune can take years to realize.  What do you do in the meantime?  After all, you don’t just get brave on isolated occasions, and magically watch the fortunes roll in.  You must stay brave all the time.  So that’s the second thing you should know.  Staying brave is harder than it looks – a lot less glamorous than one might imagine.  And it’s boring.

Yes, boring.  You slog along through thick and thin, excersing your braveness along the way.  Nobody is watching.  Nobody applauding.  You just fight for your vision, and hope you were right.  Only time will tell.

But how do you inject bravado into your project team?  How do you energize them to fight when everyone else says give up?  The answer is simple: be a bright light in a dark world.  People will naturally follow.  No coersion is necessary, just a strong, clear vision.

 

–ray

Posted on

Telecommuting: Got Motivation?

Over half (51%) of CIOs and top leaders dislike telecommuting.  See the CIO Insight article below.  If I were asked, I’d favor it… but only under certain circumstances.

http://blogs.cioinsight.com/parallax_view/content/workplace/most_employers_resist_telecommuting_1.html

 

I’ve telecommuted for the past 15 years, and it has worked great for me.  My next-door neighbor, Dean, is an IT manager, and he works from home three days a week.  With a 100-mile RT commute, that’s no surprise.  Personally, I wouldn’t work fifty miles from my work unless they paid me a lot of money!

But telecommuting doesn’t work for everybody.  Unfortunately, a lot of people suffer from a lack of self-motivation.  I personally don’t, except at about 4 PM on Friday afternoons.  Working from home can be a lonely proposition, especially if your family is away, or if you have no family.  What keeps the motor running?  Why work?  You have to be personally vested in your project team’s success.  You have to love it so much you’ll split rails to get your work done.  In our affluent society, that’s not normally the case.

Another problem: project teams can’t easily meet.  Yes, there’s telephone, email, and GotoMeeting, but are you using those tools?  Does your team meet regularly?  And if so, are you just a laptop screen on a conference room table?  Where’s the group dynamic?

I favor telecommuting when there are solid, measureable heads-down project goals, or when employees are financially vested in the project.

 

–ray

Posted on

Build vs. Buy

Every company needs specialty tools to make their company run – little things to help make things easier.  For example, a cabinet shop might need custom-built jigs.  An auto mechanic may build a few of his own tools for jobs he performs frequently.  High-tech companies certainly build plenty of in-house programs to manage information technology – databases, data entry, customer records, etc.

The question I’m posing is this: when is it right to build those custom tools in-house, or when should you go out and buy a suitable tool instead?  For instance, should an auto mechanic build his own 500 piece wrench set, or go down to Sears and buy them?  Should a tech company build a time tracking product from scratch, or license something like Standard Time®?

Since I’ve personally worked in consulting for a number of years (in another life), I’ve seen it all.  I’ve seen companies build products that were available off-the-shelf for 1/100th of the cost.  And, I’ve seen people shoehorn freeware code and products into commercial use.  Both were mistakes.

I tend to say that companies should only build products that are much more expensive to buy.  In other words, don’t try to write your own compiler – Microsoft does that just fine.  Another reason to build is when you have exotic business needs.  One last reason might be if you have time on your hands.  If you’re not making money serving customers, maybe you’ll have time to write and maintain a few necessary tools.  But that’s a dangerous position to be in.

In IT, we ignore such advice because we know we can build everything.  But I suppose the mechanic with a little metal-working and welding experience does the same thing.  🙂

What tools have you built, and regretted it?  Post a comment and let me know!

 

–ray

Posted on

Fear or Fearless?

We’ve all heard the adage, “Afraid of change”.  It’s preached throughought the business world and even in our personal lives.  We are constantly told to step outside of our comfort zones, embrace change…don’t be afraid!  It is great advice that everyone has faced at some point. 

So why is it that as soon as the media starts telling us how terrible the economy is, we freeze up with fear?  Even in uncertain times we must press forward and get past our fear.  Yet it seems totally acceptable to use the economy as a reason to remain static.  This is bogus.  I agree that we must scrutinize our expenditures and evaluate new ideas, but we should do that in good and bad times.  What frustrates and kills businesses is doing nothing!

If you have an idea to save your company money and improve revenue, why let fear stand in the way?  During good and bad times we must always be prepared to step out and embrace change.  I can honestly say that I’ve had my wins and losses with fear.  However, it always comes down to a simple choice that we make…be controlled by fear or choose to be fearless.  I’d like to hear what you think? Are you driven by fear, or are you fearless?

–Warren

Posted on

Our Customers Do Our QA

This is not as bad as it sounds.  A lot of companies are in this boat.  They don’t have the revenue to hire full time QA engineers and testers.  So, they do what they can and rely on customers to report bugs, oversights, and possible enhancements.

Let’s briefly discuss how a ‘real’ QA department operates, and then contrast that to the poor-man’s solution.  Normally, a QA manager and team of testers ensure that products delivered straight from the engineer’s drawing boards ship with minimal bugs.  Each tester is assigned one or more areas of the product.  They follow a QA plan and checklist.  Every feature is scrutinized, often put through the paces as real customers would use it.  Bugs are sent up the chain, through the QA manager, and back to the original engineers for fixing.  Once resolved, QA engineers verify the fixes.

A QA department is nice to have.  They find hundreds of issues, and save the company a lot of money and embarrassment.  Product defects are resolved before they hit the shelves.  In the end, the QA department is usually worth their pay.  After all, that’s why the department exists in the first place – to save the company money.

But if you can’t afford the salaries, and you have a small number of customers, the development and manufacturing engineers will need to perform the dreaded duty.  (It is monotonous work.)  Problem is, engineers bristle at repetitive tasks like product testing.  They won’t do a thorough job, and you still end up getting bug reports from customers.  Plus, you’ll have to pay the engineers for their extra testing work – and they aren’t cheap.  Bugs that reach the outside still cost you money in customer dissatisfaction and lost sales, but perhaps not as much as the salaries for a full testing crew.  That’s the real gamble.  And, there are so many intangibles that a true cost analysis of each method is difficult.  But, you’ll know when you need a QA team – when customer complaints begin to kill your product momentum.  When that happens, put together a team quick!

 

–newshirt

Posted on

Bill Gates’ Exit Interview

Have you seen the Channel 9 interview with Bill Gates?  The link is below.  The interview is about a half-hour long, and focuses on Gate’s plans for the future as he transitions out of Microsoft and into his philanthropist foundation to help the poor.

http://www.microsoft-watch.com/content/corporate/a_month_of_gates_7.html

 

Here are some quotes I found interesting.  These are the kinds of lines that drive my own thinking.  They drive me to fight for our brand position in the marketplace.

You’ve got to have product plans for every product you expect to release in the next few years.  And those plans have to be very realistic.

 Making sure we take some risky bets.

We are a very self-critical culture.

Software seems to be so complicated…  Software has some composability today…  But we have to make it easier to write big software.  We’ll have a lot more progress in the next decade.

 It’s always surpring to me there’s little attention paid to what we are doing for business users.

We care about the information worker.

We’re always sharing about where were going so people can make plans.

 

Best of luck, Bill.  Care to comment on the Channel 9 interview or this humble post?  🙂

–newshirt

Posted on

Define: Actual Work

Actual Work: Hours collected in a timesheet or with a timer indicating the total project hours an employee has actually worked.

 

Collecting actual work in a product like Standard Time® in important.  It allows you to compare your original forecasts with the actual hours worked by employees.  This can lead to some valuable metrics, including percent complete and estimation variance.

Assuming your original estimates are close, percent complete will tell you how far along the project is.  This is obviously more valuable to project managers and executives who are slightly distanced from the day to day tasks.  In some cases this can be their only indicator of the project status.

Refining your estimations can also be valuable, especially if your company performs the same projects over and over again.  Only actual work can give you exact numbers, and that can lead to more profits.

–ray

Posted on

The Long Product Pipeline

Ever wonder why there are so few product-based companies, and so many service-based ones?  It’s all about cash flow.  The images below illustrate this, but they need some explanation.

Product-based companies
If you’ve got bright ideas of building a product and making lots of money, think again…  There’s a long pipeline from product development to big piles of sweaty cash.  First, you have to build the product.  Nobody’s paying you to do that.  It’s your nickel, pal.  And you can spend as much time as you like.  But then comes marketing and promotion.  Get it out there for the world to see – but still more time without pay.  And then, when they find your product, you’ve got to sell it and collect your reward.  It can take months or years.  And it can be exhausting.  See the stages below.

 

 

Service-based companies
Want cash quick?  That’s why there are many more service-based companies in the world.  In that model, you can find a client and begin invoicing them after the first thirty days.  The path to that stack of sweaty cash is much shorter.  But, the stacks are smaller.  And, you tend to live on them so they never accumulate.  Lose a client, and you’ll have to start over.  Even this model has it’s risks.

 

 

 

So which model suits you?  Got the time of invest and wait for the “big” payoff?  Or, do you prefer earning as you go along?  There are plenty of advantages to both, and only you can decide what’s right for you.  Hopefully, this short post will help in your decision-making process.

 

–newshirt

Posted on

Battles in the Conference Room

Having varying points of view is healthy for company growth.  However, sometimes the varying opinions have underlying meanings that aren’t always what they seem.

For instance, how often do IT teams resist implementing new programs out of fear, laziness or just the extra work it creates?  I mean they are tasked with everything from support desk tickets, computer set-ups for new employees and even firewall security.  So it’s easy to get bogged down with the extra work a new program rollout will cost instead of focusing on the big picture and long term benefits.  Other times people resist out of simple personality conflicts.

When this happens you will hear legitimate-sounding excuses of how the installation may conflict with another program or of how it may take up too many resources.  This happens because one manager doesn’t want to help another manager or due to many other normal and very human reasons.

So the next time you have someone objecting to what most everyone else is pushing for, ask yourself, “Why?” It could be a very real objection worthy of consideration.  Or, as I found out last week, it could be a person impeding progress because they simply do not want to put more work on their plate.  The tough part is determining which is true. After all, we are all human!

 

–Warren

Posted on

Define: Technical Debt

Technical debt: Engineering changes you owe a project before it can be signed off as completed.  E.g. software, electrical, mechanical, ergonomic, and other engineering issues to be resolved.   If you’re tracking bugs, enhancements, defects, and other project issues, then you no doubt have some technical debt.  In other words, your team owes the project something before it can be said to be complete.  Every one of those issues should be documented, fixed, and verified by an objective party before project completion. Engineers, and in fact everyone, tend to sweep little things under the rug.  Especially when they don’t know how to resolve them.  Can’t fix that annoying little bug?  Easy answer: don’t tell anyone.  That’s just human nature.  Hide your deficiencies.  Make yourself look good.  Ignore the hard things. A good project team culture faces up to difficult little deficiencies.  A simple line item in a bug tracking tool like Standard Issue® makes them public, and that resolves most of the “facing up to them” issues.  Now everyone knows they exist, and must eventually be dealt with.   –ray