A man walks into a Hotel conference room and asks to have fresh squeezed orange juice for all of his audience. It has to be squeezed within two hours of being served.  Nothing bottled! In truth, he doesn’t want this service because he knows it would be expensive and out of their normal mode of operation.  But depending on the answer he gets back, he will make a decision about reserving the room or not.  What would you say as the room manager? I will explain.

Some real time wasters have embittered my reading lately.  Let me tell you, a 4.5 rating on Amazon guarantees nothing!  Reading The Secrets of Consulting was not a time waster.  I would rate it as 4 stars.

One principle that came out of it can work for some business types.  The man with the orange juice request was looking for one answer: “Yes, we can do it, here’s the price”.  If the manager would have said they can’t do it, or he can do it at no extra charge, that wouldn’t have worked.  Services should be available at an expense.  

Weindberg explains tradeoffs this way.   If your client wants it faster or larger, give it to them, but the tradeoff will be a higher price.  Many times clients want everything and they want it now at the best quality.  This principle helps me remember what is possible, and negotiations to make it worthwhile.

There were plenty of good principles in this readable book.  Weinberg is a technical consultant with a strong taste for principles and illustrations. However, if I were to rethink the title to help my colleagues understand it’s usefulness in the workplace, it might be: Wisdom and Influence in the Workplace.

Getting Things Done (GTD) is great. It has some really sound principles behind it, and I think it’s nearly complete and a fabulous starting point.  I am most uncomfortable with the divide between the calendar and the task list, and the lack of visibility of what’s left to do.

You will find these issues in nearly every productivity software or calendar system.  They just haven’t been completely addressed in software yet, or if so, that software won’t sync with anything.

It was stressful running the company. Even though I had all the tasks outlined and documented, I didn’t know for sure when they were going to start or end, or if they would get left behind.  That’s a way to grow grey.

I (with help of Nick Wortley, one or my programmers) have created a few procedures and methods that have patched the holes.  It starts with the principles.

You should only have one task list to work from

Having a calendar AND a task list can lead to missing a task.  Anytime you have more than one central list of tasks, you could run into trouble.  We need these to combine somehow.

Knowing what you need to do today and this week kills stress

Seeing everything you need to do without a date limitation causes stress

Put these principles together and we are left with a list that:

• Is in sync with our calendar
• In sync with repeatable tasks
• Limits my view to today (or any date range)
• Is complete for today

We now know what the list needs to look like. How do we get there?

I am a ardent productivity software explorer as you can see by this post, or this one.  The software that I highlight in this post is perfectly replaceable. I have chosen them because of how well they work for me, and also price.  Let’s go through what we use at Bixly.

EdgeWall Trac – The reference

Trac is a place where we store all tasks that are more than an hour to perform, or need documentation/collaboration.  It’s over the brim full of tasks for multiple projects.  Everything we as managers need to do is in there.

Trac needs to be put in it’s right place.  It’s not a software to look into and find peace.  It should be used as a reference.  I am using it as a project management tool for a single project though, and that seems to be ok.

This is a great tool for collaboration also. It’s easy to add tasks to any project quickly.  Everyone can then pull these into their daily log.

Calendar – Another reference

I happen to use Google calendar so my wife can tell me when we are doing something.  Good for collaboration.

Wiki – Repeatable tasks

We keep our repeatable tasks and processes on the wiki.  In fact if we simply follow the repeatable tasks we have logged, we will get through our day nicely.  Things like “Zero unread emails” and “Input today’s tasks from wiki” are on the daily repeatable.  They are constantly being refined, that’s why they are on a wiki.

This is a much better alternative than filling up your calendar with dozens of repeatable tasks.  If you do that, soon you won’t look at your calendar anymore.

Freemind – The stress buster

This is where the tricks happen and where stress melts.  After you have created a mindmap you need some branches:

• today
• this week

The “today” branch is your only actionable task list. “Weekly” and any other branches you make simple filter down into today.

Your tasks are already sorted in priority in Trac or are in your calendar or wiki. The process of filling in the mindmap branches goes like this:

1. Pick tasks from the Calendar, wiki, and trac, and any other buckets you use
2. Whatever you can or need to accomplish today, put in “today” branch
3. Repeat the task for “this week” branch every week.
4. Anything you didn’t get to today just delete from mindmap, and pull it back from task list tomorrow. Same thing on a weekly scale.
5. “today” branch is cleared at the end of the day, “this week” at the end of the week.

Now what you have is a burndown of what you need to get done for the day and the week.  Once you finish a task, delete if from the mindmap, and mark it complete in Trac, with any notes you have. You can quickly loot at “today” and see how many tasks are left.  It will keep you on track and on time.

You might see fit to have some over arching goals put in large tags: “this quarter”, “this year”, etc. .

Scratch Pad -  Your daily brain

A few different things go on this scratch pad.  You might use Notepad or anything you like.  I prefer Vim.

• A break down of how you want to do the task at hand
• Anything that needs to be inputted ( new tasks, dates, etc)
• notes in general

It’s a tool of freedom.  Everything can be put there because it will be cleared or inputted at the end of the day.  If there is anything valuable, then input it to Trac, the Calendar, or the Wiki. Do it, delegate it, delay it in other words.

Conclusion

This system is what you get when you cross Scrum with GTD.  The burndown concept is a clear way to see what’s left, something which GTD doesn’t do yet.  Internally we call this method of productivity “Task Piles”.  I consider it to be at an early alpha stage, but extremely useful for us nonetheless.

I think this firing thing is getting to my head.  It’s so useful to rid the chaff and spend your time on what is worthy, even when it comes to customers.

The customer was a nice fellow.  He just didn’t see eye to eye when I would charge him for Bixly’s services.  Here are personality traits of a bad customer:

• Didn’t think we should charge him for solving his problems
• Started to force us around unreasonably
• Makes us worried to take any calls from his area code
• Pulls the “this was in the original contract” with anything he wants, even though it never was in a contract.

On top of that I wasn’t making much money with him.  Not fun, no money: life is just too short.

Recently I had to replace a programmer.  It was an easy decision, but that doesn’t make it fun.

It seemed that his actions were saying  “please, can you fire me?”.  After I let him go, I gave him some notes on where I thought he could improve.  All of which were communicated multiple times during his employment of course.  I have put the list below, with a few modifications.

• version control reports have no detail
• disruptive comments during meetings
• need to be convinced of what the client/Bixly wants too often
• quick to put down very well educated programmers
• missed sprint review meeting
• delayed large project because couldn’t fulfill time commitment
• OOP skills lacking
• sporadic daily logs
• will not head coaching

Before I learned to fire fast and hire slow, I would have kept this programmer around for far too long.  The situation could have ebbed the speedy growth of Bixly.

I am just infatuated with the ideas of continuous improvement and collective intelligence.  That lead me to study the Scrum method of software development.  It centers around self organized, self managed teams, and bite-size tasks.

The term “Scrum” comes from Rugby.

Here are my notes from Agile Project Management With Scrum. Now, I am not convinced scrum is the end all, but the self organization is lovely.  I am interested in taking the best practices from Scrum, Kanbam,  RUP, and many others to form a comprehensive, scalable solution.  See, scrum isn’t suited for very small projects, but the concepts are strong.  Here are my notes on the book.  Beware, some of the notes are my thoughts on the book.

• most process improvement systems are some for of Deming cycle.
• scrum is used in work that is impossible to predict.
• Think of building a house:  the scrum/agile way you would build a complete room with pluming , electricity, etc.  they could move in quicker and decide how they want to proceed next. Rather than one category/layer at a time - framing, plumbing, electrical etc.
• defined process control - when everything is predictable
• empirical process control - when you have to figure it out as you go along
• Empirical is much more expense at first, but is more precise.  It’s also cheaper than using dpc and reworking the product.
• visibility - process must be visible and truth based. No deception.
• inspection - for bad deviations from the process
• adaption - able to adapt when a process is producing low quality.  must be done quick;y.
• tasks are 4-16 hours .  anything over is considered not broken down yet.
• scrum master more like sheepdog.  they manage the processes. Process manager would be a good title.
• the 30 day sprint balances the war between sales and development.  developers get to focus for 30 days, while the sales dep gets to add their input every 30 days.  a balance of focus and responsiveness.
• the first sprints don’t output a lot of business functionality because of architectural needs.
• give the team authority to do anything they need to get the sprint done, within basic rules.
• the true productivity from scrum comes from team self organization.  once they puzzle their way through the problems, they have buy in and high productivity.
• thoughts -  provide the goal, resources and education, let the team self organize.
• iteration planning is about the art of possible, rather than the pursuit of perfection.  Time box the meeting.  It’s not about figuring it all out.  Those conversations will never end.
• seems like that could be applied to everything.
• epc and how it morphs.
  as the degree of complexity rises, the amount of inspection increases. Because inspection increases, so does adaption
• Inter disciplinary teams are a must when there is a lot of complexity.  team members that have authority in other parts of the application meet the requirement.  that way when one module is stuck waiting for some other, the member can go to the problem module and improve it.
• maybe the term should be cross authority teams. And teams should be built with members which have unique emphasis - usability, security, fault tolerance, etc.
• Scrummaster teaches everyone to speak the same language.
• People that use defined control process, and fail, blame themselves for not being strict enough.  Creating software is just not definable exactly. Unlike producing cars, software that is written is only written because it hasn’t existed yet.  Duplication is the most the work of car making.  Software, all the work is in a unique design.
• scrum managers measure and track requirements, not tasks.
• scrum expects changes, and it’s reports reflect how those changes have effected the project.
• A scrum meeting shouldn’t follow a personality, it should follow rules.
• the scrum master is there to ensure rules are upheld, and any impedances are removed.
• self managed is hard to grasp.  they really are just let go to figure it out.
• Everyday, the code must be checked in, and tested.  Inspect and adapt is the scrum mantra.
• scrum doesn’t seem to address nesting of requirements: sub requirements.
• Inspect and adapt is what to do during retrospectives. Teams probably will have to self organize anew every couple of sprints.  don’t worry about permanent solutions.
• perfections in planning will never happen.  if the teams need to reorganize during the sprint, it’s up to them.
• The first sprint is always under estimated.  they aren’t used to a true definition of ‘done’.
• Sub optimal measurements: measuring the output of programming from the wrong perspective.  forcing them to stay within 20% of their estimate, they will sacrifice quality, and will meet the deadline.
• as the manager - scrummaster or product owner? - you mange what you want out of the team.  they manage the ‘how’.
  - product owner - what
  - scrum master - what process/guides/laws
  - team - How
• also, make sure the programmers are in the same location, if possible.  they will need face time.

Rig yourself a standup desk and never look back!  After breaking my chronic addiction to sitting down a couple years ago, I have since been glad I did.  

There’s even a bit of science behind the notion of standing up at your desk job. For example, standing up an extra two hours a day looks like it can burn 350 calories.  In addition, you will be more productive and energetic.

I LOVED standing up.  The soreness in the calves go away after a couple of weeks, and it’s smooth sailing from there.  I never experience any soreness, just being tired in the feet on occasion.

The focus is great.  Your mind won’t drift when you are standing up.  I was able to hit those annoying tasks quicker, and procrastinate less. 

After seeing this post it hit me suddenly: After I left my last company, I had been sitting down….and I HATED it.  I was so occupied with growing Bixly, ScreenBird, and my other projects, my sore bum hadn’t overcome my focus.  My last standup desk was left at the previous company, and since things are still in bootstrap mode, I ventured off to find something I could hack. 

I found a decent end table cabinet at the thrift store, and talked them down do $15.  Here it is upside-down and taken a part a bit.

All I had to do was take of the foot stubs, and replace them with long legs.  My dear little boy was having a hoot with the project.  If my "helper" wasn’t helping me, the work would have been under two hours.  We just had to cut the legs, stain them, and secure them to the bottom of the cabinet.

All said and done, my new standup desk came in under $25.  Not bad considering they can sell for thousands.  In fact a good standup desk (mine MIGHT qualify) is hard to find for under $1,000.

Your business will suffer proportionate to the amount of it you DON’T have.  Something will be missing in a big way should you be low on it.  Have you read the letter put out by Bill Gates concerning the lack of usability in Vista?  It was that missing perspective that put a deep set stain in their historic fabric.  In the same way, the more perspectives we have, the broader scope of excellence we will cover with the same resources.  That must be why they are so difficult to come by.

When you read a book, talk with a disgruntled or ecstatic customer, travel to an impoverished country, and so on, you gain a new perspective.  It’s a new way of looking at yourself or your organization that reveals strengths, weaknesses, and which then lead to opportunities and optimization.  Do you remember moving out from your parents house, growing up a bit, and realizing they were not 100% idiots like you knew they were?  You realized they had some humility - something you were just being introduced to. They were compassionate, and helpful, and you only saw it as over-lording. All the sudden you are friends with your parents because you have so much in common. That is a new perspective.

Sometimes perspective can only be gained through experience, though I think you can gain perspectives faster by being humble and teachable.
In order to use perspective effectively, it must be implemented in a wide range of categories.  Different perspectives should be applied to things like leadership, management, products, marketing, branding and so on. Branding is an example of a perspective it it’s own right, and has nested perspectives.

Let’s say you use the Balanced Scorecard method .  What perspective do you take on enterprise learning?  Will it be to meet the four major types of learning personalities with different methods, or a hot new way to reach all of them in one swoop?  Will the teachers be professionals, or career teachers?

A list of perspectives won’t do. A deeper appreciation of the issue is necessary.  A story or experience might do.  I can think of a book that drilled one very clear perspective: Leadership Self Deception .  It was a story of a fellow that had all the chops, but didn’t have a deep understanding of human interaction, and selflessness.  More than 100 pages of drilling in the truism “treat others as you want to be treated”.   You can’t read that truism and gain the same appreciation as reading the book. Gaining a new perspective is time consuming, and sometimes very costly.  Perspective is the most difficult, and most rewarding to learn.

This is the first part of a three part series on Taking Over The World.

Good ideas come from many places. Perfecting those into great works require a special kind of collaboration.  It’s a permission granted to your audit partner that none else share in that category.  
Creating systems, software, forming ideas or planning requires certain things.  Random and selective input, critique/advice, experimenting, and mores  Even if you were quite talented in the area, having a partner with whom ideas must qualify is key.  The goal is to find a certain level of harmony. It’s not time to embrace an extreme opposition, or please everyone.  Do they like the simple route, or the common bulky one? Large generalizing questions such as that are the criteria for coalescence with a creating partner.

There are simple ground rules that you might verbalize with your audit partner.

1. Intelligent contrast in key areas is your job
2. Your opinion is just as important as mine, mostly
3. I don’t consider my ideas to be good unless you do also
4. When we disagree, we try to test both ideas in real life
5. Every once in a while, I just need to try something a little crazy

Your auditing partner takes your ideas and kneads them in the uniqueness of his/her intellect. None other like it.  The result is a slightly refined and matured idea that you can mull over, and hand back.  After a few iterations, the precious idea which your organization depends on is optimal. That’s synergy!

Additional advisory input is welcome, but only for spotting red flags and wrong direction.  The true creative growth has to happen with no more than two individuals. Creative input during the incubator stage from too many sources drains the excitement and ebbs the pace.  After a certain point, ideas don’t even get better, but different.

I personally give this role to whom I most see fit and willing.  Each area has a different audit partner.  They see it for the privilege it is, and are happy to tell you their mind. 

The following is my positive review of The Innovation Paradox, by Farson and Keyes. The book actually didn’t become interesting until 40 pages in.  I nearly gave up on it.  Plotting through, giving the benefit of the doubt, paid off by revealing some cunning management insight concerning innovation.  I also enjoyed their take on winning and success: that you can’t achieve it by focusing on it.  There is room for debate on the issue, but they defend their point well.

Let’s have the meat!  Littered throughout the book were small tokens of management insight.  It makes me want to read their management book actually. Nevertheless, Farson and Keyes don’t have a full grasp of innovation.  According to them, all that’s needed is a risk friendly, mistake absorbing management philosophy. They don’t address the issues of upward and downward mobility. Without that understanding, taking the risk and enter a new market could seem foolish, and most likely be done in a way that would lead to disaster.

So what tokens of management insight could be had?  Let me quote from page 88.  The following text deals with allowing mistakes in hope of fostering innovation. Not the best way to learn, I know. They are criteria for determining if mistakes are excusable, or not.

• Did the employee design this project contentiously or was it carelessly organized?
• Could the failure have been prevented if necessary research or consultation had been accomplishes properly?
• Was the project conducted in a spirit of collaboration, or did the employee ignore the input from the others who could have helped , or fail to check with colleagues who should have been informed?
• Did the project fail because it was burdened by requirements that weren’t germane to the actual goal, but served only to meet personal needs of the employee?
• We there clear instances of deception with respect to projections of risk, cost, time, and son, or were variations from projections the results of honest mistakes?
• Was the mistake in question committed repeatedly?

Another section of seldom expressed reading describes how early success ( high school ) doesn’t dictate success later in life.  In fact the opposite is sometimes true.  Having difficulty at this age either defeats you, or sows a seed of determination.  It’s the early success stories, the Heisman trophy winners and such, that feel a sense of entitlement, and therefore simply try less. They pointed to a study of young people performing a task: The group that was complimented more didn’t perform as well as the group that wasn’t. The simple managerial deduction was to be genuinely interested in an employees laudable actions rather than throwing out complements.

It was neat to hear their take on public education.  It’s purpose is to reward the non-risk takers, and weed out the risky.  That helps explain why C’s were hard to come by for me, but running a business is a hoot.

This 100 page read was worth my time, easily.

We all have done it.  Fail, and learn from it.  I hope I can learn from my expensive failures.  I would like to think of those as a very costly quality education.  Could have paid a Wharton tuition.

That’s the stupid way to learn.  Any expensive failure I have had could have been prevented by reading.  Sometimes quite easily prevented. Reading a book costs $0-$30, time and that’s it. Having read many books on the subject of business, it’s clear that I have gained a tactical and strategic wisdom that will save millions.

I think of a recent personal result of my reading.  Right before spending hundreds of thousands of dollars on a house, I picked up Peter Schiff’s book on the economy. What a wake up call to the reality of America’s financial position!  It’s bleak, sad, and completely mismanaged, but that’s for another blog altogether. I learned from Peter that house prices were overvalued and doomed to experience and ebb. No one could refute Peter’s facts, thus, I didn’t purchase.

Since then, house prices in Fresno have droped more than 40% in some areas.  I easily saved $100,000.  Not bad for a $25 book. Additionally, I was able to invest soundly seeing an overall portfolio gain of 25%.  I got out after I shorted the DOW to 11k.

The day I stop reading, well, I can’t imagine that.