The next step vs. the *real* next step

It seems like there's almost always a gap between what we might think we want to have happen and what actually happens. Ie plans are infrequently realized.

The next step that is usually realized in a work/team environment is either:

1. That which two or more people agree to take or
   
2. That which one person wants to do because he/she wants to do it
   

The former is more collaborative and probably less frequent. It promotes better teams.

The latter is probably quite common because the actors in the company are the doers and there's usually no one standing in the way of the doers. People typically favor action. Another consequence is that those with the ideas and suggestions rarely get to implement their ideas because they're not the doers.

Sometimes the Band-Aid is too big to use

Sometimes the only solution you have is too monolithic to consider. Bail on it and keep thinking.

The Hard Part: Making the Product the First Time

It could be argued that creating a process or prototype / product / model of something for the first time is not the same as producing or selling that product in mass scale. But they're kinda related, right?, because it's all about changing and innovating… I'll try to distinguish between the creation and the birthing.

Doing something for the first time is creating the process or business. It is akin to giving birth.

Selling the product after it has been created and first shown is akin to raising the child. It is a constant selling process.

Let them set the urgency for their problems

Sometimes others' problems really are not your own; but they have to be. When I encounter this type of situation, I like to let the other person drive; make them set the sense of urgency and schedule things. Let the sense of urgency happen on their side. When they approach you with their thing, be nice, have good customer service, and move forward.

Forget about the Non-Current Impediment Now

Don't waste your time thinking about something you could do later. If you're not fighting a fire or doing something urgent and important now, then you're wasting your time. Find the person that's fighting fires and take their direction on how they need help. If they don't need help, then something's wrong; you're not supplying them enough resources.

Be Selling or Be Solving

You've basically got two choices in work and getting things done from a communications perspective: solve it or sell it.

Sometimes the sellers have to be solvers, and sometimes the solvers have to be sellers.

Know your role and what you have to do next. Be flexible.

Learn on the Task Incrementally or About the Framework Overall

There are two primary learning methods in my experience:

1. Learn on the task at hand (either by figuring it yourself or asking someone how to solve/do it)
   
2. Learn the overall framework or system (requires good connections, time, patience, and money)
   

Learning via method #2 is a luxury that we sometimes get. We want more of it but can't always find it because we don't know enough people who are as smart as we are or know as little as we do. I'm currently in a project that requires quite a bit of #1 work and I don't really have too much help on it.

We need to get better at learning in both of these ways.

Many Professional Services Compensation Methods

From what I can tell there are just a few sensible ways to pay a professional services worker:

1. By the hour on billable client work
   
2. By the hour on non-billable work (process improvement)
   
3. As a % of billed project work (sales)
   
4. Fixed fee for bringing on new consultants
   
5. Fixed Salary
   

And metrics at play that would allow you to build a model are:

• Billable hours
  
• Hourly bill rate
  
• Total billed on project
  
• Number projects
  
• Wage Costs
  
• Number billing consultants
  
• Margin on work
  

I want to be able to get paid for all of these methods but the company has to first determine how all of these options work such that the company can continue to grow rapidly and sustain its growth. No small task but I hope to continue to think about and develop a formal, flexible software model for this.

Business Intelligence: The Stuff You Don’t See, Know, or Understand

Business intelligence are the things that happen "behind the scenes" to achieve a business outcome. Business intelligence are the outsourced or "hidden" capabilities that the IT application or service provides for you without you knowing.

More later.

Distinguishing *Kicking* Major Booty from *Kissing* Major Booty

In order to get ahead we sometimes have to "kiss ass". It's not fun but we probably all do it sometimes. It's even a skill I would argue.

But it's not the same as "kicking major ass" and it's really not the goal. Let me explain. We can get ahead in one of two ways: A) climbing the ladder and B) doing good work. Climbing the ladder *may* come as a result of doing good work but can also come from kissing ass and "who you know".

Try to climb by kicking ass (doing good word) rather than kissing ass (building relationships) but recognize that don't matter and you probably can't do one without the other; you attract more bees with honey.

We want to manage our organizations, don’t we?

I blogged earlier (http://kickmajorbooty.blogspot.com/2010/06/why-do-organizations-have-top-theory-of.html) about the Theory of Wringable Necks. We want things to wring, manage, grind. Why? We require visibility and manageability. We don't want unmanageable things, or do we? Do we want chaos or order, variability or knowledge?  Probably both.

Do the Math Because Life is Math

Why is this true? Life is a collection of tests. Tests must be clear, visible, and verifiable to be quality and so must life to be brilliant, resistant, and attainable. Test life with clear goals, visibly today.

Your Organization *is* the Test Suite

How and why is this? Somehow it's true. If you see your organization or life as a collection of tests, you're set to succeed. But you need to make this a visual, visible, and measurable (external) system/process. How? Read on.

You have to know and define the *process* and *way* by which you will achieve your goals; you have to develop a tool and measurement system that throws off data that you can analyze. How? What's the data, what's the system, what's theprocess? What's the context? Read on.

You want to test and achieve your most important goals. Project management can help you get that. Goal statement and testing / verification of goals to achievement is necessary. You need data to *control and manage* your business. This gap *is* the system; the third leg of the define, do, achieve goal. It's how you adjust and get feedback.

A project is collection of tests. An organization is a collection of tests.

Tests arise in a couple of forms but the bottom line is that you have to be able to verify them *in* the computer, not in your head, against the model.

• Acceptance testing: does the product perform against the expected actions? (doing this requires you to document the expected actions or activity system as a model but this is hard to verify because it is subject. Subjective = bad for organizations)
  
• Unit testing: does the software created allow itself to be tested against a collection of tests, the policies and processes of the organization? Are the tests managed and maintained? If yes, this is good. This is visual, this is visible. Verification is good.
  

The activity of running a life or business *is* managing a collection of objectives and tests. This is often not done visually or systematically and is most commonly done randomly and individually. Bad!

As leaders, let's reduce the variability in our lives and organizations by managing things concretely and visibly; data-driven. Start unit testing your development projects today. Build your test suite as you build your business.

I Became a Very Strong Proponent of Adopting Organization-Wide Test-Driven-Development (TDD) Today

For years I've known about software testing but I never had to apply it. This probably means that I wrote crappy software; but the bottom line is that people "accepted" it, one way or another. I used to just "get by". That all changed today.

I used to be a DEVELOPER, plain and simple. I'd write a web site and show it to the customer or users and it they said it was done, it was done. Then I became slightly more advanced in my practice and learned about UML "use cases" or "scenarios"; user stories. I learned how to write a stories and workflows and make software that aligned with those high level structures. But there is an even lower level that I had to go to that I was missing: unit tests. These matter!

My brand new tool/to y in my tool-set/toy-box are unit tests. I love these. These are important. They are critical. They are potentially even THE GLUE that could unify technical and non-technical types. They represent A LANGUAGE that can be understood by technical and non-technical types together that could be a unifying force in the process of designing custom software and business rules.

Acceptance tests, use cases, scenarios, and this kind of stuff are too "high level". In a way they are very "ethereal" (understood by few) and unverifiable. One person might think the test passes, and the other doesn't. In that sense they are very QUALITATIVE and ambiguous. Bad juju in business and softare!! Bad!

On the other hand, writing unit tests and ensuring that the code or business rules you write (policies) adhere with the spirit of the law is a beautiful thing. They are very low-level, understandable, and I would argue are NON-TECHNICAL. Yay, a non-technical thing for describing the business rules and logic that must be written. Awesome! Win win!

Overall, I think our organizations need three, types of people: Those who make rules, those who break rules, and those who watch the system and determine what to change. Each of us may need to be all three types of people sometimes; wear many hats. But having these clear distinctions between responsibilities is, I think, game-changing.

Clearly Separate Your Inputs, Process, and Outputs - Know the Jobs of Everything!

When we write spaghetti code we mix all of these components up. We're not clear on the jobs of things so we make everything do many things. And it gets confusing!

On a data warehouse I'm building I have to be very clear on what are my inputs (the stuff flowing in), what is my process (the things I'm changing and I have to use temp tables during that process) and what I am outputting. Each one of these stages and events needs to be very clearly separated; ie I can't ruin my inputs while creating my outputs.

I have to preserve everything but also be able to create and destroy everything as well. That's a lot of power to harness.

Be Cooperatively Tenacious

Merriam-Webster's defines the word tenacious as, "persistent in maintaining, adhering to, or seeking something valued or desired". The only thing I would add is do this TOGETHER with someone and be tenacious about your ideas WITH others.

Never Burden the Customer with the Backlog – Keep them Focused on the Product Itself and Let them Go About their Business

If you are good at product development, then YOU and not the customer will keep the product backlog. Never burden the customer with the list of open items or anything like that. The goal is work and progress and not the list.

Today I had a meeting with the customer and we agreed on the items that needed to appear in the next iteration. We made the list together and I shared it with him over email before I began. I'm now code complete on all of the changes. But I don't want to burden him with this detail. All he wants is quality, working software, not any administrative work.

So I'm going to demo the product to him tomorrow and tell him that all of the stuff we'd talked about last time was integrated and that we are now on a whole new review cycle. This keeps things fresh and focused.

Don't carry too much process baggage with you. The goal is the product, not the process, supporting artifacts, or other metadata.

Iterations to Demonstrate Mastery of Understanding

Having a meeting with someone where you show them your work and/or art is great. Be thankful for an audience and a customer!! In these reviews there will ALMOST ALWAYS be comments, needs, and next steps (at least you should hope there are or you're likely out of a job!). So be very clear on what these are and commit then with them to the next iteration. Work with them through the process without bothering them too much. And then, when you're ready for a big demo with them (and another iteration), go for it!

There’s Always Another Piece of Art to Modify

Just because you demo your product or project to someone doesn't mean that you're done with it but sometimes you are indeed; that's the definition of "shipping".

As creatives, developers, makers, and artists at some point we have to let go of our art pieces and realize that our demo is indeed our FINAL demo; our MASTERPIECE…and we stop working on it. We ship it. We let it go.

There will always be more comments and more feedback on that thing but at some point we look the other way and move onto the next thing.

Think about De Vinci and the Mona Lisa, for example. At some point he surely said, "I'm done" and walked away. The feedback kept coming on it but he didn't look back and modify THAT piece of art; he modified others.

Why Do Organizations Have a “Top”? (The Theory of Wringable Necks)

Organizations have a top for two reasons: accounting and accountability purposes. In our organizations we need "single wringable necks" and modular, replaceable parts so we can distribute risk and seek remedy as necessary. We need to know the parties we can rely on and those from whom we can seek remedy. In a way we are distributing our risks and interests to many players; outsourcing.

When it comes to organizing things, we like to "pool" our resources amongst many players; but we like each of them to have a very clear role and responsibility (jobs).

Take the case of cloud computing: "Put it in the cloud." (A single, centralized place). The redundancy in the cloud is the thing that *would* make us trust it. We as people rarely trust single entities alone, in isolation. We frequently create backups and distribute our risk; we often "trust but verify".

We need the things in our lives to do specific jobs for us so we can rely upon them for living our purposes. The only way to manage in this outsourced context in my opinion is to make our things' responsibilities very clear; oftentimes contractual. When the things aren't living up to their responsibilities and agreements, then we need to change them, the contracts, or start wringing wringable necks.