Archive for the 'Critical Perspective' Category

Fire Someone today

Thursday, October 23rd, 2008

I know! I love the title too.

One evening I reviewed an email from Bob Pritchet, founder of Logos Research Systems.   After picking my jaw up from the desk, I started to form my response.  In the short time of research I put into his name, I realized he was an author, and the book looked quit compelling.  Fire Someone Today is a book I will read every two years from now on.  It’s so insightful, and easily worth my cash.

fst

Such clarity.  I certainly appreciate the fact that he is a successful business man, since many times authors are only able to tell you what should work.  He’s clearly not trying to use fancy lingo and impress the M.B.A. audience.  There wasn’t a single term that I wasn’t familiar with.

The concepts….beautiful!  My favorite is the quality,price,service triad.  What a wake up call.  A young punk like myself thinks he can prioritize all of these at the same time, but Bob’s point was clear:  draw a triangle with each of those at a point.  You can only go one direction.  Maybe that direction is smack dab between two (quality and price for Bixly), but it certainly can’t be for all three.  You would be spinning in circles.

What’s more, it validates a lot of other reading I have done.  I love objectivity.

Thanks so much Bob for an excellent read.

When to, and when not to form a class

Friday, October 17th, 2008

Just recently I was reminded how “personal” software engineering education has been for the unschooled.  Sadly, the basics are sweapt aside and in their place are “how to get it done” techniques that make everybody look bad in the long run.

On my quest for a good engineering education, I have stumbled upon this great explanation of when to form a class, and when you are NOT supposed to form a class. For example, the rule of one property states:

IF a noun has only one property to remember

THEN it is an attribute of another class

ELSE it is a class

Example: If we need to remember only city name, city will be an attribute ofanother class. If we need to remember city name, the type of city, the state itbelongs to, then city should be modeled as a class.

See the page here.

Why your software will get worse

Friday, September 19th, 2008

I keep tabs on the FOSS offerings in a casual way.  It’s always interesting to see new projects, new intentions and money being put into software.   Take a wider angle with me for a moment.  Do we really need it all?  Allow me to argue that these intentions are misplaced, and that most software gets worse for a very specific reason.

Axiom: Complexity for the user invites simple competitors

That’s the part that is important.  However, the second part could read “those competitors will soon make their user experience complex”.   There is more than one thing becoming complex in older software: the user experience and the code. The main reason we train in software engineering is to keep complexity controlled. Complexity, if not controlled, is confusion.  So if a user, or an engineer is working with software, and they don’t feel in control of the core functionality of it, they might move on, or companies might re-do the effort to compete with it.

Starting is sexy.  Building on a legacy, not.

that's messy! By Mallix http://www.flickr.com/photos/mallix/2816685909/sizes/l/

The company, or individual says to themselves “Why not create this software better”, rather than purchasing/using existing code, and going on from there.  Starting, that’s sexy.  Remember when you first fell in love? Nothing like it! Until you do it again, right?  Taking an old piece of software that does everything you want, just not the way you want, that’ not sexy.

Want proof?  Take a look at SourceForge, and the available content management systems written in PHP.   See, the user experience of every one on there is really bad, OR, it is quite easy to use, but doesn’t have any power.   Think of the reason for this:  A single author gets inspired to create a new CMS (because, that’s just sexy and fun), because they think they can do it better.  In fact, their thoughts on how to do it better are most likely an improvement over the system in question. So they create it, know it in an out, and it turns out, most likely, alright to lame.  We haven’t touched on the problem yet!

Collaborative will and enthusiasm is killed by confusing software

When the next fellow comes along to help with the system, that might work, if they can grasp it quickly.  If the system is overly complex, they might create their own system from scratch, just to avoid a confusing experience.

The other part of the problem:

Without a nagging champion for simplicity on your team, software will evolve into a confusing experience

We know that creating software is by nature complex.  Also, creating simple, and powerful user experience requires very complex software.  Now we have two things going against us: The inherent complexity of software engineering, and, the complexity of engineering it to be simple for the user.  Wait, let’s add a third!  The complexity of creating a intuitive, and understandable experience for the programmer.  That will keep the program moving forward into the future.  Build opposite, and all your programmers will treat you like a mean dictator until you allow them to rewrite it.

The answer to the problems above, well, those are tricky I think, and I couldn’t fully answer them.  However, if we are looking out for the problems, that’s a good start.  We seldom see companies that are willing to invest properly into achieving simplicity.  I hope to be one of those.

The Halo Effect: what a read

Wednesday, September 3rd, 2008

Forcing myself to find SOMETHING to read in the generic selection my local library offers, I picked up the most insightful looking book I could find: The Halo Effect

The Halo Effect: ... and the Eight Other Business Delusions That Deceive Managers

It’s funny, how simple an idea it exposes. Simple and wonderful. The other “Business Delusions” really just support the Halo Effect.  The Halo effect is simple: Generalizing a company based on their profits. It also impedes our learning, which is the real purpose behind the book.  Once you understand the Halo Effect ( you will in a moment ), you begin to see that it is proliferated in most business writing and research.

I will give you an example of the Halo effect.  Which internet company is best known for:

  • great technological advances
  • being the best place to work
  • new strategies/processes that are different but great
  • a true focus on what customers what

Google! Your right.  In fact, you would have to live in a box not to have ready an articles praising how Larry and Sergey tie their shoes in the morning.  Here is the problem: Research and journalism at large will not call ANYTHING Google Inc. is doing wrong.  They are making a generalizing, based on how much money they net.  So now, we are left with a distorted model on how to run our companies.

The halo effect infects most every level of journalism and research.  So if we take an employee survey, and ask Googlians if they are treated well, or if their company has an unusually strong focus on customers, the results are predictably positive.  Phil systematically shows how companies that are making a lot money have these generalizations made about every part of the company, and the same thing happens in the negative when the company does poorly.  One Forbes reporter was questioned why he was negative about the very same company he once praised, while really nothing had changed besides their cash flow.  The tactics of that specific company didn’t change, and when Google stops preforming as well ( thousands of years of market history say it will have a downturn ) , the very same tactics/focus/work environment will be castigated as “too loose”, “lazy”, “over the top” etc..

Nowhere does a halo currently shine as brightly as upon Google. Reporters marvel at Google’s wonderful “anything-goes spirit” where the absence of supervision is said to stimulate creativity and where no one needs to worry about whether projects will be profitable. Co-founder Larry Page is said to praise managers who made million-dollar errors, thanking them for their willingness to take risks. In fact, what’s said about Google is eerily similar to what was said about another New Economy wonder, Cisco Systems, a decade ago. That company, too, was admired for its wild ways—until a sharp downturn led critics to castigate it for those same qualities. From Halo to Hell

I have know acknowledged the existence of Halos, which will aid me from this point on evaluate research with much more discernment.  In fact, just the other day I heard a author interviewed on PBS state that Starbucks is loosing profit because they have lost their once great focus on the customer.  Really?  My usual iced green tea tastes great, and is delivered by smiling, competent employees.  I would like to hear the proof that they have lost their “customer focus”.

Four Reasons Why Not to Use Chandler 1.0

Monday, August 11th, 2008

As a dedicated software adventurer, Chandler has been on my radar for a very long time.  Since 1.0 came out today, I thought I might give it a go.

chandler

What Chandler is: a project that hopes to sync with great services (gmail, outlook, etc) and is therefore quite welcome.

What Chandler is not: functional or useful

Ouch!  I am quite sorry to give such a review of this project.  I know what it takes to pull something like this off, and how much Mitch Kapor’s heart has been poured into it.  Let’s hope this isn’t a pattern for later releases of Chandler.

Four Reasons why Chandler 1.0 is found wanting

1. It doesn’t do anything that I need

Sure, it syncs my to-do’s and calendar with other stuff, but does that matter when the to-do’s aren’t useful, and calendar has nothing new to offer?  In other words, who wants to sync something they don’t really don’t need? Sync a mess at home, and it will appear at work also!

2. Tasks are a mess

chandler_tasksChandler is supposed to follow the GTD paradigm.  The problem is it just uses the most minimal implementation possible.  So if you want to mark something beyond just now/later/done, you have to schedule it on the calendar.  This poses a few problems. Mainly, there is no abstraction, which is really the heart of GTD, i.e. “don’t stress over that now, you can only do one thing at a time”.

Thankfully, they do have “note”(the universal item in Chandler) categories. You can’t even drag/arrange tasks.  Their idea of abstraction is a star. Your note can have it, or not.  Well, after you mark a dozen of those, they start to loose their meaning.

With so much competition in the tasking arena, Chandler is certainly nothing to get excited about.

3. No contacts

Really, this program wants to be a PIM (personal information manager).  It’s my opinion that nothing is really going to take over this market until they take a truly SMART comprehensive view of PIM. There have been many brave attempts, but since there is a large gap between great ideas and solid implementation, we probably have to wait for a couple more years before something killer comes along.

So how are you supposed to link a to-do to a contact to a calendar entry?  You can’t right now.  I bet you a nickel it’s in their plans, but that doesn’t help us today.

4.  Memory Muncher

chandler_ram

The Python runtime jumped to 140 mb after some very average usage in Chandler. Python has its own memory management, but how well will it do under heavy usage?  Remember Python on the desktop isn’t a terribly popular scenario, and Chandler could find themselves with low level programming they aren’t ready to handle.  But, that is a risk I bet they have wagered well.  You have to take risks to move ahead in the tech world.

Really, I do hate to be so down on fellow entrepreneurs and developers.  Truly, I wish them the best.  Please, own this category! Until then, I am sticking with ToDoList and a medley of other apps.  My prediction is that Google will be the first to confront the ugly monster that is PIM with poise.

+ update : I found Thinking Rock, and so far, I really love it. It will probably take the place of ToDoList.

Book Report: Exceptional Selling

Tuesday, August 5th, 2008

Having experience playing important roles in a couple business, I found myself quite familiar with many ares of business. One area I hadn’t researched was sales. How does one become a respectable salesman? After spending an hour in Barnes and Noble’s business section, I picked up Exception Selling. Certainly, I am not proposing I lead this area in my company, but until the resources justify a sales team, here we go.

The following are some of my notes on the adventure. I recommend this book, but I don’t know what that’s worth to you, being my first book on sales.

Exceptional selling, notes

Pages 1-50

  • when you are feeling pressure, you are doing something wrong
  • never answer unasked questions
  • just making a value proposition makes customers see your service as a commodity. Then they make a decision based just on price.
  • don’t be a lecturer, It’s a ineffective way for them to learn.
  • stop persuading and start collaborating
  • don’t come in thinking you are a salesman, but a trusted advisory
  • value proposition is not enough, everyone offers that.
  • value gap, the gap between what you think it’s worth, and what customers do. crossing this gap is done by offer the customer value as they see it in their world

Sales life cycle

value proposition – tell them what you do

value assumption/premise – something you both agree could be a value to them, and MIGHT be confirmed after further investigation.

value absent – investigate the consequences of absent value, quantify, and show

value required – the customer acknowledges value is required

value expected – where you confirm exactly what can be done, for how much

value achieved

Pages 50 – 100

  • diagnosis mindset is opposite from presentation mindset.
  • you diagnose WITH the customer. selling is something you do TO them(bad)
  • go for the ‘no’ early and often. make sure they are ready for what you offer, and if they aren’t, move on quickly to qualified sales leads
  • diagnose the problems without insinuating they are incompetent

Mindset

– change guidance
– mutual self respect
– don’t let them run over you
– emotional maturity
– you must remain emotionally detached, but professional in tune
  • the process,
    discuss, diagnose, design, deliver,
    the following is the application of those.
  • be prepared , and research the company/person you are calling.
  • people won’t reject you if you aren’t being a salesman.
  • the first call should be one of discovering the problems, from the people closest to the action. – Questions like: do you see this happen? What are the results? – Ask for facts and consequences, – don’t talk about yourself for more than a few seconds
  • discovery conversations are not sales calls
  • cold call script, pg 92
  • towards discovery stage script, pg 97
  • don’t answer with questions
  • When getting customer is digging to deep before you have appropriate information, keep answers to 20 seconds, and continue where you left off.
  • The questions will be; how much and how long, etc. Answer, and get back to learning about them.
  • give the customer a small assignment, it keeps them engaged and conjures a sense of collaboration
  • high probability to close sale when they learn they have great need

Pages 100 – 220

  • once you have permission to move on, start the diagnosis.
  • this phase is about thinking of their situation, not your solution
  • never let the customer self diagnose, you have the domain expertise

Diagnostic conversation model

– what is happening
– why is it, how bad
– is it bad enough to act on?
  • don’t use insulting questions when exploring what they said. neutral ones like ‘can you help me understand ‘not fast enough’’ ?
  • questions should start with asking observations, not accusations.
  • never insult competition, acknowledge them.
  • ask what methods they have used already to fix the problem. don’t assume they haven’t tried.
  • let the customers co-create the solution with you, this way, you get a better solution for them, and they gain more trust with customer.
  • ask questions from customer point of view; ‘when would you like to see this solution up and running?’, not ‘when can you make a decision?’.
  • actually, that’s wrong wording by Thull, again. more like, ask questions from a customer value position, not a sales value one.

Proposals – a confirmation on what has already been decided

1. No surprises
2. Us their wording/phrases wherever you can

  • don’t skip diagnosis even if they think they have a problem. they don’t know the value of fixing it until you lay it out for them.
  • if you can’t put a cost to the problem, you don’t have a problem

Financial conversation

– how much does our absence cost them?
– What return can they expect from solution?
– How much is that worth to them?
  • it’s critical that company execs take part on the sales team when talking to other execs. they have the experience and depth of knowledge regarding their value

Software That Shouldn’t be Ignored

Wednesday, July 23rd, 2008

Productivity, organization, and collaboration software excite me.  Just recently I decided to upgrade my task tracking system, and that is just so fun!  The following is a review of some desktop task management suites.  After many hours in review of online project/task management, I wasn’t prepared to go that route.  We already use Trac internally for dev teams, and each of them has their own way of tracking tasks.  There is just no killer project management suite as of today, sorry.

Certainly there is a fine selection of personally task management software, or so I thought.  After all, mastering ourselves is the key to mastering our dreams.   Let me explain what tools I tried, and my opinion of them.



TaskJuggler


This project is attractive because of its robustness.  You can do nearly everything.  It might very well be a pain to do it, but you can.  See, this program manages tasks via its own markup.  I would be able to pull out reports with any level of abstraction and specificity I wish. That’s HUGE. But a new markup to learn? Well, darn.  But I figured it was worth learning because the task management landscape is terribly malnourished.

I make my way to the download page and………surprise…Linux only!  You can get it running under Cygwin, virtualization, or just run it remotely on your Linux server.  Gees.  No thanks.  Looks like a great project, but until its ported, or I move to Linux full time, I shall look elsewhere.



Nomad Pim


My hopes are once again high.  This PIM is programed on the Eclipse platform.  That means programmers can focus on functionality over platform robustness, and the ensuing app has great potential.  The app has a short learning curve, and the interface for contacts and tasks is the same.  That’s a new take, but it seems to work.  You can search through your contacts quickly, and schedule tasks.  Its usefulness ends there for me.  When I flick on the PC, and open my task lists, I can’t have 100 tasks staring me in the face.  I need abstraction! In other words, give me the top priorities.  That’s the essence of GTD, except they are called next actions.  Note: “GTD” suites suffer all the same problems in my opinion.

A neat start for Nomad, but that’s all.  It really would leave me stressed at the end of the day from not knowing exactly what I need to be doing. I am starting to think my requirements are impossible, but they seem simple to me.



Abstract Spoon’s ToDoList


Deciding I have to disperse PIM functions into different apps, I look solely for a task management application. So many! I am not going to list everything I have tried or researched.

Do you know that I fell in love with ToDoList? It is open source, a few minutes to learn, only has minor bugs, and you can truly arrange and filter tasks. If you are looking for an app that is great for collaboration, keep looking or hire Bixly to build one that considers such usability topics as abstraction. ToDoList is magically simple and smart. Sure, it can be a bit awkward to use at times, but it just leaves these other programs in the dust when it comes to getting things done without stress. Good work!



WikidPad


For a neat desktop wiki that tries to employ a task system, try Wikidpad. It’s the best desktop wiki I have seen. Its attempt to tackle “globals” such as tasks, is darn interesting. I think my dream PIM app lay somewhere in WikidPad, just not yet. It’s rather cumbersome right now as a task or contact manager. But the idea that you can create tasks or contacts from anywhere on any wiki page is fantastic. Also, having the navigation tree decided completely by the wiki script is cumbersome. I just haven’t given thought to exactly how it should work, because the alternative is quite robust. I am truly rooting for this project.


Another program that really disappointing me was TaskCoach . It just…..doesn’t get it. Nothing is intuitive or easy, and it certainly doesn’t help me manage tasks very well. Now I am thankful to all these programmers for giving us free software, so don’t misunderstand my purpose here. I hope to save you time in your search for great software.

Also you might find collaborative mindmaping useful for knowledge management and simple tasking within the enterprise. The earliest program to do it right was Comapping .

170 Employees, One Manager

Friday, July 18th, 2008

The following entry is a summary of this amazing article, Engines of Democracy . This is exciting info, and a good follow up on the previous entry on Simplexity. You can read my drab summary of the article, or read the 12 pages yourself, which I highly recommend. I understand the ideas presented here aren’t turn-key solutions for every organization. It sure is interesting to think HOW these principles can be applied to my current and future companies.

  • Just one floor manager for 170 employees
  • Teams, averaging 16 people, create jet engines
  • Three levels of techs, with clear pay grades
  • Level 3’s can do any jet job
  • Each task has clear directions, with photos of each step
  • Interview process takes 8 hours:
    > They are given tasks, work with the team, and build a presentation
    > Team rates interviewee on 11 criteria, many involve teamwork
  • They give each other feedback when needed. They don’t have resentment, or hide feelings
  • Employees get creativity with the exact process of building engines
  • They are trained on how to reach consensus, or live without getting their way:
    > they know if it doesn’t work out, the have a chance to change it later on
  • Sharing skill is important, it allows the team to operate without you when you need time off
  • Teams are really tribes: accountability, culture, training, loyalty
  • Members periodically join councils to decide hr/discipline/rewards for other teams
  • A team is responsible for themselves with things like cleanup and tool tracking
  • Basic principles, from managers mouth:
    > Layerless organization
    > People paid according to skill
    > Everyone certified/trained by FAA
    > Tribal mentality
  • Three types of decisions for the company
    > A decisions – The plant manager decides (She only makes 10-12 of those a year)
    > B decision – The plant manger decides with input from teams
    > C decision – Decision is made by employee consensus (most common type)
  • Though they technically have only one boss for 170 employees, they see it as having 15 bosses. Their peers.
  • Employees don’t think their job is making jet engines, but making them better

Simplexity

Monday, July 14th, 2008

Simplexity is the prefect marriage of simple and complex.  It’s accomplished by creating many simple parts, that create a larger complex system. Miguel Cunha is gold, if you haven’t read him before. He has a fascinating, although rough draft, article on Simplexity. There are many parallels for business, software, and life in the idea of simplexity, but he focuses on Business. It’s worth a read if you can find the time, otherwise, here are my notes from his article

Ashby’s Law:
only complex organizing – rather than complicated organizations – provides enough complexity to cope with environmental turbulence.
basically means only complexity can cope with complexity

Unintentional Complexity

Complexity is the cumulative by-product of organizational changes, big and small, that over the years weave complications (often invisibly) into the way work is done. pg 7

It is fought with intentional simplicity. Jack Welch turned around GE with his simplification process.

Unintentional simplicity is a problem also. it encourages exploitation over exploration. pg 8

Loosely coupled organizations can better handle the unexpected. pg 17

Only the complex organizing provided by simple structures – rather than complicated organizations – is flexible enough to cope with environmental complexity. pg 18

Complexity, top-down hierarchy, overdeveloped systems and processes seem to turn workers into machines. A hive-mind mentality should foster creativity.

organizations need to create designs that favor alertness and capacity of response, triggered wherever the information is. pg 19
Although the behavior that emerges is complex, the rules that guide it are necessarily simple. In fact it is their simplicity that creates the freedom to behave in complicated adaptive, and surprising ways. pg 20
One of the potential results of deliberately simple organizing is the creation of a developed collective mind, or what Weick and Roberts (1993) described as heedful interrelating. The concept refers to a developed attentiveness and caring about the actions of the other organizational members, in such a way that individual know-how is made subservient to group processes. pg 22

Simple infrastructures may result in complex behaviors because they support and facilitate a number of processes that encourage rich and mindful interactions. pg 22
in his Mann Gulch study, which showed that training and specialization may actually hamper the variety of behavioral repertoire. Again: complexity may block learning and adaptation. pg 25

This read was particularly reassuring for me. It’s the collective intelligence of the company that can really make a great company, not just mine. That’s great! Now the leader’s role is to facilitate such an atmosphere.

Resources

http://www.fastcompany.com/magazine/28/ge.html
http://www.complexityandeducation.ualberta.ca/COMPLICITY1/pdfs/Complicity11b_Intro.pdf

Ambiguity Aversion

Friday, July 4th, 2008

Research has shown that we certainly possess risk aversion. Ambiguity aversion should be considered its hidden twin in the proliferate duo that is worth understanding for your business. An awareness of this principle is certainly important enough to add to Paradigms I Follow .

It is simply this: Being psychologically prohibited to expanding decision options because of ambiguity. See, you can have a two or more choices in front of you with greater/lesser/equal worth in the end. You will most likely choose the one which requires the smallest amount of thinking. Please check out the Thirteen.org video that inspired this post. What a neat show! Further:

Frisch and Baron (1988) emphasized that the subjective experience of missing information relevant to a prediction may lead to ambiguity aversion.
Keller

This has so many implications for business and brands. A great example of popular usage and profit from Ambiguity Aversion is the show Deal Or No Deal . Forward to the middle of a show and the decision usually looks like this: Take $300,000 right now, or possibly get $800,000. It’s silly really to choose the $800,000 because the chances are still 1 in 5 or 1 in 10. Since we are averse to ambiguity, it’s easier to calculate “hmmm, I want more money, and this could work”.

This opens up a whole new field of Neuroeconomics to us, which is definitively worth further brain breaching.

Interestingly, ambiguity aversion in pairs of users actually gets worse!

The majority of the dyads exhibited a cautious shift in the face of ambiguity, stating a smaller willingness-to-pay than the two individuals’ average. Our study thus confirms the persistence of ambiguity aversion in a group setting and demonstrates the predominance of cautious shifts for dyads.
Keller

Additional resources:
Four types of Ambiguity Aversion link