I Was Wrong
Comments (7)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.
Software Sucks
Really, it does. when was the last time you said “wow, it’s amazing how well this software works. it does everything I need it to, perfectly, reliably and for a good value”? I remember the first company I really worked for and the code I would write. Like all startups, I hoped it would get bought, but I was always worried – what about the whole due diligence thing? Would they look at the software and think “this is just hacked together – this isn’t any good”. And the funny thing is, I never stopped thinking that, as I went to different companies. You know what I realized later? That all software sucks. It’s all the same hacked together stuff. It’s never the elegant thing that young budding Computer Scientists imagine it will be. They think (well, I certainly thought) that actual, real software was much more impressive than the junk I threw together. But they’re sadly mistaken. The code they write is just as good as anyone else’s.
Uh oh! A Segway must have come by!
And I know some people will say “well, software is cheap – I can buy windows for $200, but a car costs me $20,000″. Nice try. Ever drive on a toll bridge? Exactly. the toll runs you about $2. Why? because the thing didn’t have to be re-engineered for each person. The car doesn’t either, nor does the software. The difference is that the car actually needs to be built for each person. Not true with the Bridge, nor the software. The engineering that goes into every copy is the same. Obviously, with custom software (or software with significant customization), each version needs to be newly engineered and built.
The problem is simply that people expect software to suck, and they stand for it. I want to change that. I want you to expect software to just work. Right. Always. This is the start of a series on Making Software Not Suck, and what S3 is doing (or ideas I have that we’re working on) to combat the acceptance of bad software. I’ll include each link here as I write more posts. Enjoy the series, and as always – I thrive on disagreements, so please – let me know your thoughts – you might spawn a whole new series, or at least a new post that you can refute.
Compensating QA and engineering? Use Conflict – it’s not bad
Perfect Software Really Fast – Conflict is Good
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.
Protection? not at the cost of progress
One of my biggest pet peeves is when people have a good idea, but implement it poorly. I remember many years ago thinking how cool it would be if they just put in self checkout machines at stores. Really, why would you pay someone to pass a bunch of products over a scanner. Any reasonably intelligent (by which I mean someone about as smart as a checkout person) can figure out how to do this. clearly, this is not rocket science. So imagine my excitement the first time I saw one. Great – I can checkout myself. No need to glare at the incompetence as someone tries to figure out what to give me back when I pay for 19.81 worth of groceries with a twenty dollar bill, a nickle and a penny. A machine is good at math – no problem.
So I start scanning my groceries – slowly – you want to see how it works the first time. So I scan my first item. beep – cool – I put it in the bag. beep – in the bag. beep – in the bag. Well, this is perfect! easy, fast, painless. So I get started scanning my groceries a tad faster – one item – good. Second item… “Please place your item in the bag”. Ummm… what? it’s in my right hand – I passed it from my left to my right – just like any cashier does, and tried to pass the second item over. You have got to be kidding me. I need to actually place this thing in the bag before you’ll let me scan something else? that is the dumbest thing I’ve ever heard.
What about my 20 cans of tomatoes? Back in the good old days, even cashiers could just hit 20x(scan). Now they all just swipe one item over 20 times (most of them are reasonably adept at counting to 20 – but not all) and put the case in the bag / cart. I have to scan it, put it in the bag, wait for the (slow) computer to acknowledge that it has been put in there. Ok, fine I think. I’ll just put this case of tomatoes on the (what I now know to be a) scale, and scan the one item. “Please remove the unpaid merchandise from your bag”. Oh for crying out loud.
And then you have two other extremes – home depot offers these self checkout machines. But (and yes, this has happened to me) – how am I supposed to put my 20 ft ladder in the bag? And then I was trying to but a greeting card for my wife. what? your scale is not sensitive enough to register the card? you’re kidding me.
So my question is simple – why, in heaven’s name, do these stupid machines need to weigh my groceries (or ladders)? If you have a better answer, please, tell me. But all I can think of is one of two reasons. Either it’s to prevent theft (by making sure that you don’t put any other items into the bag while it’s on the scale) or it’s to help well intentioned people catch their own mis-scans. The former is so foolish as to be laughable. Surely, surely, you don’t think thieves are going to be thwarted by a simple scale. Brandon told me one story about someone who walked up to the machine and it had weighed everything and was happy and jolly, but the person just didn’t bother to pay. No alarms, nothing – it was just sitting there waiting for the money to be inserted. As the person happily drove home with their delicious free ice cream.
So really the only thing I can possibly accept is that it’s there to protect good citizens from accidentally walking off with merchandise they haven’t paid for. And that’s what my rant is about. Don’t do it. The overhead of trying to protect people from the things they might (rarely) screw up is ridiculous. Remember – cashiers manage to get this right. Cashiers! (Nicola will tell you that I have particularly loathsome look for cashiers – notably those who can’t make change). Let’s be honest – in the worst case scenario, I’m probably about as likely as a cashier to make an error. Chances are, I’m more likely to be diligent, because I know that if I get caught “stealing”, there’s a whole lot more to lose than my job.
My advice to you? Don’t over-protect your clients. the cost overhead (I guarantee you that the weighing subsystem of those stupid machines adds a huge cost – hardware, software, maintenance, not to mention the fact that you need to pay someone to watch and reset the stupid thing every time it misses a greeting card) is not offset by happier customers, but rather, it alienates customers (I flat out refuse to use those machines). Technology should just work. Sure, at first there might be issues – bugs and the like (although S3 is working on an approach to make sure those don’t get to the customer – ask me about it), but after a few pilots, those should be found and addressed. minor bugs continue in many things. But this isn’t minor – this makes the machine unusable. fix it. Don’t make bad decisions – put in only as much protection as you need to and no more. Don’t protect your customers from themselves – they’ll figure that out on their own.
Knowledge – Get Some
Knowledge is power, as the old saying goes. Around midnight last night, I was working with the phone agents at American Airlines to get my mother back to Toronto after she missed her connection due to weather in Chicago. I had successfully got her onto a 6:3 0am flight, and started packing for my own flight to Cincinnati this morning. At 1:37 am, I received an email from AA confirming her flight at 8:45 am. Wait, that was all wrong, she’s on the 6:35 am flight. So, being a good son, I called to fix it, having several times myself experienced the non-notification changes that the airlines tend to make. I asked the agent what had happened – why was she put on this flight. She said that it looked like someone had changed it – maybe the passenger.
Ok, stop – what? Let me get this straight – you don’t know who made the change? You have got to be kidding me. How can you possibly run a business like this? There’s already plenty of ambiguity in the world (and airlines are no exception), why on earth would you not keep the knowledge you do have? You have to deal with tens, maybe hundreds of thousands of irate customers every day because of things out of your control (notably, in this case, weather), and you allow something as trivial as who made a change to a reservation go unknown. Never mind all the union complaints, the reduced passenger load or the price of oil. If you’re not taking advantage of the small bit of stable knowledge you really do have access to, how can you possibly expect to glean any useful information from the stuff you don’t actually know – or make even vaguely reasonable predictions?
A mandate I put in place at S3 several years ago was that every single interaction that happens with our software is automatically logged. Obviously, the above scenario requires a human to put in the information of who requested the change – a good business process. In other words, our software is good – it stores everything it can possibly know, but even the best software in the world can’t override established bad decisions. So don’t make bad decisions – keep the knowledge you have, and use it to your benefit.
On a scale of 1-5, you’re a 3
…And so am I. Everyone should strive to be a 3. Why? Maybe your company does it a bit differently, but the way we do reviews, everyone is rated on a scale of 1-5, with 1 being “does not meet expectations”, 3 being “meets expectations” and 5 being “exceeds expectations”. When I’m giving someone a review, and they’re across the board 3s, a lot of people get a down look on their face – “I worked so hard, why do I only get 3s?”. Well, simple – because my expectations are correctly set. You have successfully set my expectations of your capabilities. My attitude is simple – if I give you a 5, my expectations were set too low. Don’t get me wrong, I do sometimes give 5s, but the next time we meet, that 5 will be a 3, because you’ve reset my expectations.
I like to use a different method for motivating people – it’s called “money”. If you’re exceeding my expectations, then my expectations were set too low. If my expectations were set too low, chances are, so is your salary. It seems that all of my employees end up agreeing that they’d like to be a 3 – funnily enough, when I offer – “Would you like me to give you 5s, but take away 20% of your income? I can do that if you want.” everyone (thus far) has said that they’d rather be a 3. And let’s be honest, if you didn’t, I’d probably fire you, because you clearly don’t have the kind of aggressive drive for success that we look for in employees.
so, the next time someone says you’re meeting expectations, hold your head high. And the next time someone says your exceeding expectations, let them know that you’re ready to meet expectations, and are looking forward to your raise.
Oh… and if you’re not meeting expectations, I’d suggest looking for a new job.
Metrics are worthless
Ok, so maybe not ALL metrics are worthless, merely most.
Metrics – everyone uses them – chances are you either need to collect them, report on them or analyze them. plenty of people’s full time jobs are doing something with metrics. So why do all these people spend so much time on metrics? Simple – because they identify something. usually a problem, sometimes an opportunity. the only purpose of metrics is to allow you to make a decision on something. But the majority of the time – indeed the vast majority of the time, those decisions don’t take a lot of thought. Some of them need some thinking. But not most.
How long did it take for something to get from status A to status B? You don’t really care. You care about one thing – you’re probably going to guess “yeah – is my project on time”. But that’s not even true. All you really care about is if your project is NOT on time. You don’t care if your airplane is going to be on time – you only care if your airplane is going to be late. You don’t care if your project is on budget. you only care if your project is OVER budget. So, here’s my thinking – let’s get rid of metrics – replace them with simple notifications. No, not the HBS dashboards of green, yellow and red. Even simpler – call it a Mark Davies dashboard – two colors – yellow and red. green is irrelevant – hide it. The last thing I need to see if how many things are working well.
Recently, we had a “post mortem” meeting. We discussed “what worked and what didn’t”. You can already see what my response was – I don’t care what worked – it worked, we did it right – let’s focus on what didn’t work to fix it. One thing I’ve always hated is a bunch of people sitting around agreeing about things. Patting themselves on the back – “Hey, we did a good job there, we got it 98% finished in only 102% of the time” – all they see is a big sea of green. You know what I see? an incomplete project that’s already 2% overdue.
So – let’s get rid of all the metrics – sure the data needs to be there to support them, but don’t spend all your time analyzing data – “but the software might get it wrong” – yeah, so might you, and the software doesn’t get tired when it’s looking at piles and piles of spreadsheets at 2 am because it has a report the next day to it’s boss. Design the software right (obviously S3 would be my recommendation on this front) and sit back, fix the problems and enjoy a drink, because your time is no longer wasted analyzing data that doesn’t matter.
you only have one top priority. One. 1. one.
How many top priorities do you think you have? I suspect you read the title of this post and figured out that unless you said one, you’re wrong. This seems to be an incredibly hard concept for people to get. Actually, come to think of it, maybe you can help me. How do I communicate better about this fact? I get really frustrated when people don’t understand this. Please, comment – tell me how I get this concept communicated.
Let’s try some examples: You’re batman, and your girlfriend is about to be blown up. But the joker cleverly is about to blow up the mayor at the same time. So, you have a choice to make. They’re both equally important is not a valid answer. you must pick one. If you fail to pick one, you lose both of them. I don’t care who you pick, but whoever you pick, you are stating that that is your number one priority. Period. They are not equally important.
You’re in charge of a big client. You have a month long project with major financial implications. Another client calls and says they need a quick report. You now have a decision to make. Which is more important? I don’t care if you have enough resources to handle them both. If everyone but you gets hit by the lottery bus*, you now have to pick which one to work on.
And don’t give me “well, the month long project is my number one priority, but I can do this quickly, so I’ll just do it”. No, that’s wrong. That just became your number one priority.
I’ll tell you the solution to this difficulty, but I’m serious – I want help communicating it. The solution to how to address it is quite simply to break everything down into very small tasks, and prioritize those. Pick an atomic unit of work – say, 2 hour estimate tasks, and break everything into chunks of that size. Don’t tell me you can’t do that for the big project. You do it all the time, just implicitly, not explicitly. Then, at any given time, you can decide exactly what your top priority is. Don’t compare the month long project to the ad hoc request. Compare “write this query” to “respond to this client’s request”. That’s a much easier comparison to make.
Now your turn – since I’m a jerk and communicate rather aggressively (which puts people on the defensive), how do I succeed in actually getting this message across? Obviously I’m writing a blog post as one attempt – we’ll see how successful that is. What do you suggest?
* you can thank Andi for the lottery bus – she thinks we should be nice when we describe why people might not show up for work. everyone else in the world uses “he might get hit by a bus”, but Andi thinks being hit by a bus is not nice, so Andi thinks we should say “he might win the lottery”. Except, if I won the lottery, I’d still show up to work. So, to help Andi feel better about people getting hit by buses, I make it the lottery bus.
