Let me get this straight…

Oh yeah? You do? Let me guess – you donated money to the earthquake relief effort. Or you even decided to go to Haiti to help “rebuild”. See, here’s the thing – there’s nothing to rebuild.

The country is the poorest country in the western hemisphere. The annual GDP per person is probably less than you make in a week (unless you’re making minimum wage, in which case less than you make in three weeks). And that’s an average. The vast majority of them make less than that.

In the late 90’s, my wife (fiancee at the time) and I went to The Dominican Republic. It was a good, cheap, Caribbean destination. We enjoyed an all inclusive resort, with excess of food and drink. On the drive from the airport to the resort, we were amazed at how poor the people were. We had both traveled a good deal, but never before to anywhere poorer than the G8 nations. The houses were tiny concrete huts. Large families crammed into these small houses. we were shocked. We were told that the average worker was making $200 a month. And that we would be perfectly safe in the resort – the waiting list for a job there was two years – people would not do something that might get them fired.

While we were there, we went on a tour. The owner of the tour company (a German) joined us on the tour – he was testing a new stop on the tour – a sugar cane plantation. What we saw shocked us. The sugar cane was tended by Haitians. The Haitians moved to the Dominican because the standard of living was so much higher. They lived in mud huts. No doors (just holes), no windows. There was no infrastructure at all – they were surrounded by miles of sugar cane fields. The children were naked, the adults clothed in scraps. As we left, we gave them a bottle of water. the children all surged for it, hoping for a sip of the pure spring water we all take for granted. And these were the migrant workers. The ones who were fortunate enough to escape from the poverty of Haiti.

Where were you on Monday, January 11? Were you praying for the Haitians? Sending them money? Taking a week off work to go help them grow their economy, or to give them the medicine they need? No. You were sipping fine wine at your favorite restaurant. You were driving around in a vehicle that cost more than most Haitians will see in a lifetime.

You say you care about Haiti? Well, prove it. Quit talking about texting for $5. Or taking time off work to help them. They don’t need that kind of help. If you really care, and aren’t just doing this to show the world how good you are, wait till all this earthquake hullabaloo dies down. Start buying Fair Trade Haitian products. Or invest in companies that invest in Haiti. At S3, if any employee donates money to Haiti, we’re matching, but not with cash – we’re matching donations by investing in Haitian entrepreneurs on Kiva. If you really care, teach the Haitians how to fish.

One of the dumbest phrases I’ve ever heard is “is there anything we can do to make you stay?” It’s pathetic. begging people to stay is completely unproductive. They don’t want to be there. Let them go.

But, you say, maybe we could do something to make them happy. Nope. It’s too late. you may well have had a chance a while ago, back when they were starting to get disenfranchised. And I suspect you did have that chance. You heard rumors. they seemed less interested. You could have talked to them. But you didn’t. What’s different now? they’ve made the decision to leave. Let them go.

I know, it’s not your fault – they didn’t come talk to you. That’s a good point. Why didn’t they? Well, did you invite them to? Did you say “Tell me how I’m failing you”? and not just to the people who seem unhappy, but to everyone? sounds like it was your fault.

So get out there, talk to your employees – if they have a problem, they’ll talk to you before they quit. So you never have to beg pathetcally again.

One of our former employees would often say to me “Mark… you know what your problem is? YOU HAVE NO CHARISMA!!!”. Why? Well, you’ve read my blog. I’m not exactly Dale Carnegie. In fact, Jim Moore has been known to say “Mark, you’re the only person Dale Carnegie would punch”.

One of the founders of Southwest Airlines, Herb Kelleher has long been touted as an incredibly charismatic leader. He managed not only to convince governments to allow his struggling airline to get off the ground, but (far more importantly), he managed to convince an entire team of people working for him to do everything they could to get that airline off the ground, despite the fact that they were literally grounded.

So what’s my point? Yes, you saw it coming, I’m going to compare myself to Herb. One of the often touted examples of Herb’s character is his willingness to listen to his employees. But in reading The Southwest Airlines Way, I read an interesting quote from one of the pilots: ‘…You don’t just call and say there’s a problem. He’ll say “think about it and tell me the solution that you think will work”…’ And this is exactly what I do… only I say “Quit your damn complaining. Come to me with a solution!” And that is my advice today. Quit complaining. And don’t let people complain to you.

Complaints are downers – no one likes complaints. And no one likes complainers. But it seems people like to complain. Don’t stand for it. If you have a complaint, make sure you have a solution to it. And if someone comes to you with a complaint, challenge them to find the solution.

One other thing – If someone comes to you with a problem, and a solution – figure out how to address the problem. And at least some of the time, use their solution. Far worse than complaining would be to listen to someone’s problem, listen to their solution, and ignore it (and even worse would be to ignore the problem as well). If you do that, not only will they revert to complaining, but they’ll also add a new complaint – that you don’t ever listen.

If you’re in the software industry, you’ve probably heard a lot of buzzwords about making software fast, good and error free. for a long time, people have been solving problems using some pretty standard techniques. One of these has manifested itself in Software as “Waterfall” development. Waterfall is basically the same idea that everything else in the world is developed by – first, you figure out what the problem is, then you figure out how to solve it, then you write the program that solves it, then you test it, then you deploy it. Seems like a pretty sensible approach – for every dollar you spend in each step, you can expect to spend 10x that on the next step. so if you spend ten dollars to make a design decision, making that same decision after deployment could cost many thousands of dollars. It’s really just like in construction – moving a line on a blue print is a lot cheaper than moving a wall in a building.

But software isn’t really like everything else. Partially completed software can actually be used. A bridge with a few feet missing is entirely useless. But a program with a few features missing tends to be pretty useful. Because of this, people figured out that they could do other development methodologies with software. And so was born the agile development methnodologies. Lean, Scrum, XP – all sorts of different names were given to them. They compressed the time from analysis to production down from what could sometimes be years to months. Were they a good thing? Sure, to an extent. They’ve been criticized for various things by the Waterfallers – missing requirements, not able to address all concerns, etc. But that’s not my approach.

Agile Software methodologies fail not because they are too lean, but because they are not lean enough. That is to say, they absolutely not lean at all. They’re just a name given to short waterfall cycle. “Lean” manufacturing was invented by Toyota. The idea of lean is to eliminate waste. Waste from everywhere, but notably in inventory. But software doesn’t have inventory, you say. Of course it does – inventory is any piece of functionality that is not delivered to the customer.

Reread that – that’s the crux of S3’s Production System. Inventory is any requirement functionality that is not delivered to the customer. If you have a requirement that is sitting in a queue anywhere, that’s inventory. Have software designed but not coded? Inventory. Have software coded but not tested? Inventory. Software tested but not deployed? Inventory.

Agile (like waterfall) groups features together. Sometimes related, sometimes not. But it groups features into releases. Why? because that’s how it’s always been done. Nobody deploys a single feature. It’s always grouped. Which means there’s always inventory. If a software methodology is going to claim to be lean, truly lean, it has to get rid of the inventory. Why do you have three developers working on three different features, then that whole package goes to a QA department (possibly overseas)? S3 does true one piece flow. One piece of functionality – from inception to production with no wait points. No inventory. Design, Development, QA, production in the same room – a piece of functionality never has a chance to be wrong. Quality suffers? No way – just like Toyota, by having everything there together, quality skyrockets. Reworks disappear. Bugs are caught before they are even written.

There is a lot more to come on how S3 truly adapted lean manufacturing to software – this is just something to get you started thinking. Challenge me, please. We’re always looking for better ways. But if it’s something that exists today, we’ve already determined that it’s too slow.

Ok, so that’s not entirely true. Part of it isn’t wrong.

What the hell am I talking about? Simple – the US constitution is, primarily, a specification. It is a specification that describes how to perform a certain set of requirements (which, coincidentally, is the part that isn’t wrong). So why is that wrong? It’s not actually wrong – it simply doesn’t take into account all available information. It takes into account merely the information available to the creators of the specification. There are numerous examples of how these specifications may have applied to a world eleven score and two years ago, but not today. As illustration, I’ll use a non-controversial example in the seventh amendment: “In suits at common law, where the value in controversy shall exceed twenty dollars, the right of trial by jury shall be preserved….” Obviously, if you’re suing someone over $20 today, you have too much time and/or money on your hands, and are doing it for sport. From my research, that $20 most likely represented somewhere around $8,000 today. Presumably, the reason for putting a price on it was to limit the invocation of a civil trial by jury, but that limit is effectively meaningless today. We have no idea why they worded the specs the way they did – we probably understand their world a little better than they do ours (history is easier to understand than future). But we do have something valuable to use.

The US constitution includes a very clear requirements section – i.e. the justification for the specs. What are these requirements? “…in order to form a more perfect union, establish justice, insure domestic tranquility, provide for the common defense, promote the general welfare, and secure the blessings of liberty to ourselves and our posterity…”. Everyone hears a lot of bickering of what the intent of the founding fathers was. But there is no need to bicker. It’s right there, very clear. Their intent was not to make it so people could have guns, or to have state run health care. Their intent was not to make it so people could have abortions, or pray in school. Their intent was to form a more perfect union. To establish justice. to insure domestic tranquility. To provide for the common defense. To promote the general welfare, and finally, to secure the blessings of liberty themselves and their posterity.

So why am I writing about the constitution? Because it’s exactly the kind of thing we do at S3. Do you have a problem? I bet you have an idea for a solution. Many companies would love to talk to you about that solution, and give you what you’re asking for. But S3 doesn’t. We’re not in the business of implementing someone else’s solution. We don’t have complete knowledge of the problem you are facing. You probably don’t have full knowledge of what the system is capable of, even if you’ve used it in the past. Just like we today have knowledge that the founding fathers never did (like the fact that $20 is an inconsequential amount of money compared to legal fees), and they knew clearly what they were trying to do, you and S3 have complementary knowledge.

With constitutional arguments, don’t try to convince me that your assault rifles are legal because the constitution says they are. Convince me that it will help provide for the common defense, or insure domestic tranquility. Don’t tell me that the government should disallow prayer in schools because the constitution guarantees freedom of religion. Tell me why that will promote the general welfare or secure the blessings of liberty. With software – tell me your problem. I’d love to hear your solution. But be assured I’m going to challenge it. Because I’m going to make sure your requirements are met. My goal is not to implement your specs. The more we understand your problem, the better we can implement a solution that solves it. My goal is to give you a more perfect solution to your problem.

And hopefully, we will all continue to strive for that more perfect union.

When I walk into a client’s office, my intentions are pretty clear. I am going to sit down with the client, figure out what their root problem is (which, more often than not is a superset of the problem they initially asked us to solve) then explain to them how S3 will solve that problem. Since I am able to articulate the problem and our solution so well, I expect that they will agree with me about their root problem, and, in a short time, we’ll have an agreement to perform the actions I described. I am going to completely change their expectations of software delivery.

Except, once again, it turns out I’m sometimes wrong. I’m right about the me part – I do exactly what I say I will. But the problem comes in the “them” part. They don’t always agree with me that our solution solves their problem better than another option. Or worse, they do agree with me, but do not want to use S3 to do the work.

Both of these occurrences have happened to me over the past couple of weeks. In one of them, we were sitting at a client site, listening to what their problem was, and what they were asking us to do. And, as we usually do, we listened, heard what their real problem was, and walked them through a solution where they could not only get what they were looking for, but we could help reduce a lot of the work they were currently doing manually. It sounded like a great solution on all fronts – they liked the idea, it would save them time and money, and help optimize a money making opportunity, and it would be a good deal for us – more valuable than solving the initial request they had shown us. We left the meeting thinking it was a great success. it had gone exactly as I expected. But you know what’s coming… they said no (which, admittedly is a good start). But why? Well, because it turns out the solution included information they didn’t want a third party to manage. As it happens, this system included information of a proprietary nature. So, rather than upselling the deal, we lost ground by having this conversation. Even though they agreed that our solution would be helpful.

In the second one, we similarly listened to their current work, and, while there wasn’t a single clear cut problem, there were several areas where we could assist. We walked them through these areas. We actually had a very good meeting, and there were definite opportunities where we could help. But in the end, it was clear that they didn’t really agree that our solutions to these problems were the best ones. They had come into the meeting with a totally different set of expectations.

The boy scouts tell you to “Be Prepared” for the worst case. Mel Brooks told us to “hope for the best, expect the worst”. So what did I do wrong here? Simple, I expected a certain outcome. I had a set of expectations of the meeting, ironically, one of those expectations was to challenge their expectations. But I foolishly did not challenge my own expectations.

So – here’s my advice to you, and indeed to myself: erase your expectations. Don’t expect anything. Plan for failure and the worst case, hope for best case, but don’t expect anything – because that expectation slows you down, no matter what your expectation is – you can’t adapt quickly when you’re planning for and expecting one thing, but another thing happens.

Everyone has heard that old adage. But it’s just plain wrong. I know, you’re thinking I’m wrong. But I’m not. Why? Because it’s backwards. Time may be a lot of things. Money? Simply deferred time. Why does the distinction matter?

I remember when I first became a consultant – billed out hourly. I would value everything by time. I would say “oh.. that car will cost me 3 months work”, or “I can pay for this book in 15 minutes” This was a good way to compare the real value of something. Would I really get the enjoyment out of this book that working 15 minutes would cost me? or would I rather allocate that 15 minutes to pay for the 3 month car? That method doesn’t work particularly well for me anymore, because I’m rarely billable these days. If I’m at a client site, I’m probably there on my own nickel.

I know what you’re thinking – no, there are other things that are worth money. Natural resources for example. Nope. Sorry, they aren’t. the only value of resources is time. If all resources were in unlimited supply everywhere, then the only value of the resource would be the amount of time taken to do something useful. As it stands, natural resources have value precisely because they take time to acquire. Rarity only makes something valuable because it takes time to acquire.

But still, why does it matter? Simple, because time and again, people value time at a lower rate than money. Many people compare things by price, and some compare things by time as I did when I was a consultant. But precious few people recognize just how valuable that time is, and fail to really value the overall time, rather than just the immediate time. One of the phrases I hear way to much is “I can do it faster if I just do it myself”. Yep, you probably can. and next time? and the time after that? what about if there’s a variation? it’s the whole “give a man a fish and you feed him for a day, teach a man to fish and you feed him for life” thing. Your time is valuable. And almost certainly, you are underestimating that.

Many of us have heard that the best way to get ahead at work is to work yourself out of a job. In other words, your time is worth much more than simply the salary you’re making. The faster you can automate something, the faster you’ll be making more money.

So quit thinking in terms of how much something costs, and instead, think of how much time it can save. quit thinking time is money, and start realizing that money is just temporarily stored time, and that time is what really matters.