Startup CTOs #2: Tear The Contract Up
Leave a CommentWell Done! You’ve been living off credit cards and Ramen for the past 8 months. and now, you’re ready to start delivering. Now, take that contract you just signed, and run it through the shredder. What??? ok, you’re right. That won’t do. Instead, put it in an envelope, seal it, and put it in a file cabinet. Yes, I’m serious. But, you say, it has the specs of the solution we’re going to deliver to our client! No, it doesn’t. Sorry. it simply doesn’t. What it does have is the bare minimum solution you need to deliver if you have a dispute with your client. read that again – if you have a dispute.
Contracts only exist for one reason – what to do if things go wrong. a contract is completely unnecessary if nothing goes wrong. The bank gives you $400,000 to buy a house, you pay it back at $2400 a month for 30 years, everyone’s happy. Why do you need a contract? because sometimes, people don’t pay it back. So the bank needs a way to say what has to happen if you don’t pay it back. makes sense? but wait, your contract is different – yours specifies exactly what you’re going to deliver to your client. But it doesn’t. In fact, without even seeing your contract, I can tell you what you need to do for your client. you need to make them successful. Some people would say happy, but I think happy misses a key factor – a client who drinks a lot of beer and watches a lot of football (on your dime) may be happy, but their job is not better because of what you do. So, as long as you focus on delivering to them what they need, they will be successful, and you will be rewarded.
And no, this does not mean charging less than the value of something. It means you sold them something – some service or product to help them solve a problem. whether that problem was explicitly stated in the contract or not (coincidentally, it almost certainly was not), that’s why they’re buying your product. Give them that solution, and don’t worry about the letter of the contract.
No client ever complained “man, these guys are terrible – they solved our problem, have fantastic customer service and have saved us a ton of money, but they didn’t specifically do item 13.2.3.2.1 on the contract, so let’s sue them.” Why? because you gave them what they needed. Don’t give them any reason to have a dispute with you, and the contract will never come up. Solve the problem they have, keep your client successful, and you will be successful as well.
Startup CTOs #1: Should You Patent It?
Leave a CommentSo you’ve created some cool technology. Maybe it’s some new technology to share documents across the internet, or a way to answer your most pressing questions, or even some new way of matching data. And you’re pretty pleased – you want a patent, because a patent is cool. And a patent is a great way to protect your intellectual property. Or is it?
You’ll hear that you can apply for a patent, and only 2-3 years later, you’ll have the government protecting your technology. Sounds like a great idea. Except it’s not entirely true. A patent is very useful – if you happen to be in the business of defending patents. If you happen to have a hundred or so patents around an idea, and fully intend to sue for them, then by all means, pursue it. But don’t expect it to protect you from someone else trying to do the same thing. A single patent offers very little protection, because there are generally many many ways around it, unless you’ve got most of those covered. More importantly, don’t expect to be able to focus on your core business if you do patent it – you’ll be way too busy suing people over patent infringement.
OK, so what about the cool aspect? Yeah, it’s kind of cool to say “I have a patent”. But does cool make you money? Well, all those late night infomercials say things like “with our patent pending design, not only will you never need to cook again, but you’ll also trim inches off your waist, AND improve your golf swing!” I don’t know, maybe being patent pending helps to sell a $14.95 tool that allows you to fry an egg while it’s still inside its shell. But from my experience, it gains you nothing. Why? TeraMatch was patent pending for six years, before we stopped pursuing the patent for it. By this time, we had changed the implementation and the idea so drastically that the original technology was primitive in comparison. Would we defend it? no way – too much else going on. Did we sell any deals because of the patent? Nope, not one.
My advice for startup technologists? Skip the patent – figure out something cool, make the technology good enough, and sell the hell out of it.
Quit Complaining
Comments (2)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.
Why Agile Development Misses the Boat
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.
The Constitution is Wrong
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.
Your Expectations are Wrong
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.
Time is Money? Wrong
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.
I Was Wrong
It’s ok – you don’t have to get out your recording devices, I’ve written it down, on the internet, so it must be true. I know hearing me say I’m wrong is a rarity – I tend to be a tad less humble than that. But I think it’s important to highlight the fact that while I sit here and criticize things, I’m always learning. So yes, here I am, admitting that there are times in my life when I have made the wrong decision.
Recently, during a deployment that we did for a customer, I was somewhat involved in the requirements. Admittedly not as early as I would have liked, but reasonably early none-the-less. I spent hours meeting with the customer, going over what they wanted, and how we would implement it. We went over requirements, had some heated disagreements, and finally ended up with a set of requirements for our first go around. I brought it back to S3, and communicated everything to the Fight Club members who would be working on it. Three weeks later, I went to visit the client ready to demo a perfect, error free product that we had agreed as the first iteration. I pulled up the first screen. within minutes, I was asked “Where’s the rest of it?” No problem, I’m used to handling such questions. So I continue with “Well, if you recall, we agreed that this would be the first, fast release”. Well, needless to say, I was wrong. I completely missed the boat. We ultimately worked out the solution, and got a new schedule down for the complete roll out, which, I’m pleased to say, was a boring success. I would have preferred our SPS method of rolling out a single feature at a time. Because of this occurrence, I’ve learned better how to approach this in the future. But this time I was wrong.
Another big failure I’ve managed was pissing off a VP of one of our financial services clients. Software is designed to make people’s job’s easier. As you’ll see from the comments on my post about the most valuable half hour of my life, One of the unfortunate side-effects of this fact is that sometimes, it makes their job so much easier that their job is no longer required. Several years ago, I was young, brash, and completely unconcerned about such trivialities as other people’s feelings. On the day in question, I marched into the office of the boss of our primary supporter at this client. As usual, I asked questions, inquired, and found inefficiencies. I proudly stated that with our assistance, he could lay off half of his workforce. I am told that it is just a coincidence that they are the only client of ours who has left who didn’t happen to be implicated in a $50B Ponzi Scheme. But let’s be honest – my arrogance will never let me think that it was just a coincidence. Thank goodness we have such good people working here, because we’re finally managing to get them back as a client.
I have made other mistakes. I have made other bad decisions. Sometimes I address the mistake head on, and try to unravel the mess I’ve made. Sometimes, I just walk away. But no matter what wrong I have done, I learn. And that is a quality I look for at S3. Make mistakes. Please. Because if you don’t make mistakes, you’re not trying anything new. Don’t be afraid to make a bad decision. Big, or little, make a decision, whether it be the decision to quit your job and start a company, or the decision to take the bus. Many mistakes can be fixed – I have seen mistakes fixed many years after I made them. But if you don’t try anything new, don’t make a decision, don’t make mistakes, then you languish, and never grow. Try something new. Make a decision. Make a mistake. And, in the end, you will be a happier person because of it.
Yes-Men Need Not Apply
The most valuable half hour of my life occurred between four cubicles in the Plano, TX headquarters of EDS, one of our clients. Not in a big conference room somewhere, not at some big meeting. Instead, actually sitting with a group of people who actually used our product.
Our client had sent down a request for an enhancement. Specifically, we had been asked to add several columns to a web based report. Seems like a simple enough request. And it was. It probably would have taken all of about an hour to finish. But I didn’t do it. Why? Because I didn’t get it. More columns on an already ridiculously complicated report? Why would you want to do such a thing? So, instead of giving them what they asked for, I asked for a meeting. I asked them to show me what they were going to do with this report. They said that I could come up and talk to them. So I did. And what I heard amazed me…
“I run the search with these parameters [the guy who managed three other people identfied three dropdowns on the screen]. Then I use this button here to export the data to excel. I then sort the results by this column. Then, I copy each of the sections ["sections" were groups of telecom vendors assigned to an individual to manage] to a separate tab on the spreadsheet. Then I email everyone on the team the entire spreadsheet to work their own sections”. Wow, at this point my head was already spinning at how poor a job we had done helping them solve their real problem.
I then went over to one of his staff members. She took me through the rest of it: “I take my section, and copy the first circuit ID [one of the fields in the Excel file]. Then I paste it into the search screen [the search screen of the S3 application]. Then I need to click into that record, get to the detail and look at these five fields [several fields spread around the two hundred or so total fields]. depending on what those fields say, I need to change these six fields. So this is why we need the extra fields on the extract – so we don’t have to click into the detail of each record“. I was shocked. And there was more after that too. Yes, it was more centralized than their previous solution, but it sure as hell wasn’t easier or faster.
So I asked – “how long does all this take you” “oh, about two weeks each month”. “for each of the four of you?” “yes, approximately”. To me, it was obvious what we needed to do.
We created a set of reports and workflows called “CDI Gold”. The manager only had to set up the mappings from vendor to employee once. Everyone else was automatically presented with a list of the records that met the necessary criteria when they logged on, and it only showed them the fields they needed to see. From there, they could select one of three options, which automatically set the six fields (except one field for one of the options, which required a comment). And that handled everything they needed done.
How long did the new process take? By noon on the first business day of the subsequent months, the job was done. by just figuring out exactly what they really needed, I was able to reduce their workload from 160 man-hours to 16. a 10x improvement.
This is why S3’s tagline is Challenge Everything. Our software exists to solve problems. We are not programmers for hire, who simply implement a system that has been requested, without knowing or caring what it’s for. We will push our clients to their real needs, and we expect and welcome push back on us. This is something I am dead serious about. One of my clients was once praising one of my employees, and told me that he was a better “yes man” than I was – that he listend to the requirements better than I did. He said that sometimes the Challenge Everything is frustrating to the client. I subsequently reprimanded that employee. And the client? Well, he challenged me. And I respect that more than anything. He is a still a strong supporter of ours. But S3 is about solving real and valuable problems. Yes men need not apply.
Don’t expect us to do something without asking why. And you can damn well expect a better result because of it.
A Penny Saved? No thanks – Earn a Dollar Instead
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.
