Let me get this straight…

Facebook is an incredible tool. It lets you connect with people you haven’t seen for decades, and see how your lives have diverged. But it also helps you find new business contacts, or new friends, or even new love. Facebook, as a company, has succeeded. I read a quote recently (sadly, I cannot remember the source – if you know the source, please let me know so I can give proper credit) that said (approximately) “not being on facebook today is like not having a cell phone – by doing so, you are making a statement, whether you intend to or not”.

They are estimated to have roughly $300 million in revenue. The company is worth somewhere around $6.5 Billion. They have 900+ employees. So why the hell do they keep changing things that people get comfortable with? The front page of facebook has changed significantly at least three times in the past year. Unlike cell phones, where people have an option to select a new one, Facebook has a single primary interface.

Facebook appears to be following the disastrous trend of allowing developers to create their software. No, I don’t mean actually write the software, of course they do that – but create the experience that a customer will see. There are a couple of reasons for this, but none of them relate to the kind of things a $300 million (not to mention $6.5 billion market cap) company should have. Developers are amongst the most necessary people at the inception of a software (or web) company. you can make a product with a developer – it may look like crap, but it’ll work. You can’t do that with anyone else. It’s the same reason QA is always an afterthought – no one ever started a company with a QA person and no developer (ok, ok – outsourced testing companies might – but if you learn about S3’s Production System, you’ll realize that outsourcing QA is a terrible decision, but that’s for another post).

So when you start a company, you hire some developers. And they do a good job. But over time, your product matures. And your developers become less critical. So you have several choices – put them on things that matter to you, but aren’t very technically interesting, fire them, or keep them designing the critical stuff, ignoring all the input you get from your clients (and probably many people within the company) telling you that they’re making bad decisions. Each of these has its downfalls – the first makes the developers bored, and disenfranchised. That sentiment will probably spread through your organization. And then they’ll probably quit anyway. as for the second, firing them feels wrong. These are the people who helped you get off the ground – these people are the reason your company exists. The third makes your clients disenfranchised, and frustrated.

So, if you want to continue to grow, and keep a strong culture, and keep your clients content, this is when you have to fire your developers. It’ll feel bad. And there are days you’ll regret doing it. But if you don’t, you can watch your company erode, and instead of losing some people, you may well lose them all.

Sure, if you happen to be the sort of monopolistic company that Facebook has managed to become, the last option is survivable, but probably only in the short term – some day, someone will figure out a way to overthrow you over time – maybe with just 140 characters.

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.

Recently, I attended the MIT Sloan CIO / CTO symposium. Naturally, a lot of CIOs were on panels, talking of their great accomplishments, and providing their thoughts on how everything should work. Every time some great accomplishment was mentioned, it was that they had saved some grand amount of money somewhere. It also came out that CIOs spend is roughly 5% of the company budget. Almost all of the sessions brought up the fact that CIOs everywhere need to move to a focus that is more in line with the company’s overall strategy. In other words, focus on making something that actually makes the company money.

So why were all these CIOs patting themselves on the back for saving money? Seriously – one guy was super excited that he’d saved 50% of his budget. I actually do agree that that is a good thing, a very impressive achievement – you probably removed a great deal of inefficiency. However, you didn’t become a CIO by being dumb. Taking a great amount of brain power and only focusing it on 5% of the budget is akin to buying a Ferrari with a 5 MPH governor. Yeah, it’ll manage to get you up to 5 MPH faster than other modes of transport, but you’re missing a whole lot of power.

So here’s the question. Why are all these CIOs so focused on cost? If I had to guess (and I do, since I don’t have a CIO here to answer the question) – because of how they’re compensated. I bet just about every CIO’s bonus depends on how much IT he managed to do with the least cost. The company is promoting the wrong thing. Nobody became successfully by spending less. Everyone became successful by making more.

Seems like the answer is obvious, doesn’t it? Change the compensation structure. CIO – you saved cost… good – you get a small % of that savings. You actually made money – fantastic, you get a huge percentage of that increased revenue. But, you say, you still need to save money. Sure you do – but don’t waste your top executives on such a goal. That’s just short sighted.

I’ve figured it out. But people are worried it will create tension. Who cares? a little tension never hurt anyone. Like with everything else, the solution is money. just throw money at it? no, of course not. That’s too obvious. Here’s the solution – compensate your QA people on Quality and your developers on speed. That’s all there is to it. the details are easy, I challenge you to find a flaw in my logic here:

Developers need to develop stuff. For S3, they need to do it fast. Really fast. IT says it’ll take 18 months? We’ll have you up and running within a week. Not necessarily all the bells and whistles, but something that is valuable to you, the client. and that’s to production in that speed, not just coded, but coded, verified, and released all within a week. So how do we make them develop stuff fast? Simple – tie their compensation to how long it takes them to get something out. Not the end solution completely solved. Not just the development part. so, if their compensation is (x) and is tied to revenue, and, if something is in production and being used by the customer takes more than a week, their compensation is (x) – (the number of days early)*(some constant). simple – if it goes live late, you lose money for each day. (you can have a positive side too, but to be fair to QA, we’re going to leave it as negative only for now)

Did I mention it has to be bug free? Yep, bug free. QA also makes (x), which is tied to revenue. QA needs to make sure software doesn’t have bugs. So, for every bug that is found after something goes to production, QA loses (y) amount of money. That’s it: more bugs = less pay. hell, ANY bugs = less pay.

but wait, I hear you say – Dev should want quality too! But they do! why? because if they don’t, QA will block. nothing goes live till QA says go. but what incentive does QA have to do things quickly? they don’t. And this is key. In my ideal world, QA is bored. bored out of their skulls – all they do is test bug free software all day, every day. No one says QA has to be done fast. QA has to be done right. what stops them from halting everything? simple – their compensation is tied to revenue. No revenue, no money period.

But just think of the animosity it would cause! The developers get mad at QA for sending their stuff back with bugs. QA getting mad at development for making so many bugs. oh, what a horrible working environment! Come on… really? all of a sudden, development has a huge incentive to write bug free software. the vast majority of the time in development is really re-work from bad software. get rid of that, and the speed and quality skyrocket.

Get people to write software that doesn’t suck (look for a new blog post on this topic later), and you can finally delivery perfect quality fast. Just don’t be scared of a little conflict.