The city has had ample opportunities, even back in September of 2013, to address 2-3 easy “issues” regarding Uber and similar services. Instead it decided to stonewall and delay while protecting status quo. Using lawyers instead of proactively managing the update of policy and regulations to those in line with the opportunities of this century is perhaps one way to govern. Congratulations to how the mayor and Transportation Board decided to prioritize and spend taxpayer dollars on something that should have never reached this point (I’m being flip). Now it seems like they are simply digging their heals in because “they can” vs. asking “what is the right answer for our citizens and travelers who visit our great city?”
I have no horse in this race other than that of being a business traveler who has been repeatedly delighted as a customer while using Uber when traveling to other cities across this nation. As a prior board member of the Technology Association of Oregon and former Chief Technology Officer of Regence Blue Cross Blue Shield I’m frankly embarrassed that Portland has sided with the Luddites as opposed to embracing what great technology can enable.
As a business traveler I will continue to vote with my wallet (and my Uber phone app) until I am no longer delighted by the service they and their drivers provide to me as a consumer compared to other available options. I suspect other consumers will decide to do the same.
Last month if you had found a time machine and turned the dial back 20 years you would have seen the first set of banner ads. HotWired.com partnered with fourteen companies to try something new and innovative. If you want to go back in time and see what AT&T did as one of these collaborators and early adopters, look at the top of this posting or go to www.thefirstbannerad.com (don’t worry about feeling nostalgic and setting your video settings to 640×480 first). Go ahead and click on the banner ad and check out the static text landing page that had 3 hyperlinks, which then buried a couple of pages that were pretty dramatic and jaw dropping for the day).
One of the coolest aspects of their first banner ad was that they tied it in to a video advertising promotion that they had been running both on CD-ROM (as magazine inserts) and on TV. The campaign was called “You Will” and it featured some of their predictions for what people would be able to do in the future due to technology. You can see a compilation of these videos here. It’s worth going through them all. Video didn’t stream on the internet back then, but the “You Will” tagline tied their messaging and unique content delivery across multiple mediums together for them.
What is ironic about these predictions is that they pretty much nailed all of them, but one. We may still be waiting for personal medical records, but the prediction they missed was one that was in their own space at the time. How is it they were able to predict all the others, but not their own? Quite simply they suffered from a phenomenon known as Innovator’s Dilemma. Simply put they were too close the problem, could only see the solution in terms of how they would solve it based on their domain knowledge of the day, and they failed to ask the question “How would others do this?”
I’m a big fan of a methodology called “The 6 Qs” when trying to take on an initiative or problem (I’ll explain it in a future post). Question 5 is “How have others solved this problem?” All too often many of us think that when it comes time to solve a problem that we have to leverage our own creative juices to find the answer. Most of us leverage our own experiences within our space, try to leverage how our products work today, and then try to leap to the next logical change or enhancement that would get us to the solution. Our starting point is often based on where we are standing today vs. from where others are standing.
The truth is that many notable innovations come from what has already been invented. The reality is that these stem from leveraging a solution in an adjacent space and reapplying it in your own domain in a way that delights your customers. History is full of examples of people and companies credited with inventing or innovating something really transformative to an industry. The dirty secret is that if you peel away the layers of the onion you often find they were the ones who saw a solution in an adjacent space and were the first to make the leap as to how to apply it within their own domain.
How will somebody else from an adjacent space out innovate you as you work from where you stand today?
I have loved contributing to this blog. Somebody took notice and offered me an opportunity to publish. My first magazine article, “The Two C’s of Agile,” appears in this latest issue of Pragmatic Marketing: http://t.co/gGmcPNgYdq
In some ways it feels like forever yet in other ways it feels like just yesterday. Ten years ago on July 10, 2004, my first wife, Susan Louise (DeSilva) Lawler, died from complications related to metastasized breast cancer. She was only 42 and had fought what amounted to an 8 year battle when she died in recovery from what would have been her last possible surgery to try delay the inevitable. She was only 34 when she discovered her tumor in a hotel room during a trip to visit her family in Los Angles. We were newlyweds and had been married for just two years.
I’m a firm believer that waiting until you are 40 to begin self-examinations or to get your first mammogram is a myth. The Young Survival Coalition posts these statistics on their web site:
- Each year, approximately 70 thousand men and women age 15 to 39 are diagnosed in case in the US; breast cancer is the most common cancer for women in this age group.
- Every year, nearly 1,200 women under age 40 die from breast cancer.
- Compared to older women, young women generally face more aggressive cancers and lower survival rates.
- More evidence tells us that breast cancer before age 40 differs biologically from the cancer faced by older women.
- African American women under the age of 35 have rates of breast cancer two times higher than Caucasian women of the same age.
- African American women under age 35 die from breast cancer three times as often as Caucasian women of the same age.
They also have some great online resources.
Put simply, the problem is that in young women breast cancer seems to be much more aggressive and fast moving. Those in the know don’t know why, but it is.
Looking back I remember a tall, slender, stunningly attractive woman who worked for the Ice Capades, selling time on the ice to schools and children’s groups. I remember my friends kidding me that I must have lied to her to have ended up with somebody who was “…so out of my league.” I remember meeting a woman who would frequent Los Angeles area karaoke clubs each week to sing in their competitions, using her winnings to help pay her monthly bills; I sometimes wonder what would happen if NBC’s “The Voice” had been on the air back when she was alive. I remember a woman who was very headstrong and angry one moment and then as happy as a five year old with a new favorite doll to play with the next. I remember a woman who had to deal with the great physical and emotional trauma of having her life stolen and ripped out from underneath her just as she was beginning to enjoy life for the first time after a very difficult childhood and young adult life. I remember her enduring numerous surgeries and cancer treatments, including an analogous stem cell transplant. I remember Dr. Brian Druker being her favorite doctor (before he focused exclusively on his Leukemia and Gleevec research) and her telling me “…he’s going to win a Nobel Prize in Medicine someday, just you wait and see.” It looks like she might end up being right on that one…
My father found a small photo album just after her death that she had prepared and left in her final days in our home, placed in my home office, the last page having the simple inscription “p.s. I was here!” Because of her karaoke competitions I had hours of audio cassette tapes of her singing stored in boxes. I sorted through them and burned ten tracks on to a CD for her service, to hand to others, and to keep for myself. I used one of the songs to make an online video comprised of her last photo album, set to her singing “The Wind Beneath Our Wings.” I hosted it on my personal website at the time.
That was ten years ago. Since that time I was lucky to have met and remarried to a wonderful woman, Kim, who is very different from Susan. She’s special in many ways, but one of them is that she doesn’t mind or feel jealous of the ghost in my heart, which can peek out at times. I keep it in a small, contained box and I only open it when I want to. It’s been awhile, but today seemed like a good day to open that box and to share.
If you or any of your family members are women under 40, please don’t wait to get checked. Waiting until you are 40 to worry about breast cancer is a myth. Trust me… Trust Susan’s story…
I sometimes hear from teams who haven’t embraced Agile that it “doesn’t fit the type of work we do.” They insist on continuing to manage their workflow and efforts over e-mail and spreadsheets. Take a look at this board and how can you not envision running any effort this way quite easily? Don’t like the columns? Rename them. Add / remove columns to fit your needs. It doesn’t get simpler than that…
Originally posted on Sockets and Lightbulbs:
Four years ago, I needed to design a Scrum board to use with my teams. Teams moved around a lot, so I wanted something I could enlarge and laminate so we could easily roll up the scrum boards and move them. We also didn’t have to depend on having white boards or cork boards in the area, we could just attach the Scrum board to any vertical surface – a door or a window, if necessary. Of course, that meant the board should be useful in both a horizontal or vertical configuration. Laminating the boards meant we could customize it to suit each team. A simple package of washable markers would take care of that.
View original 746 more words
Note: I originally posted this on WordPress on April 2, 2012 and have updated with some modifications in this refresh…
How many times have you downloaded an update to your latest app or gone to a vendor’s web site and nearly entered a fugue rage state because something that use to work is now broken? How many times have you cursed slower performance that isn’t a simple glitch, but seems tied to the latest release? I know I’ve experienced both; it is very frustrating and every occurrence undermines my confidence in those products and erodes any good will I might feel toward the solution or the vendor. I have to admit that as a software professional I have unfortunately been the cause of this in my own career as a developer. All of my teams have also done so at one point or another.
This is why I adopted a simple golden rule many years ago: Do No Harm.
To me one of the worst sins in software development is to introduce what I like to call a “self-inflicted gunshot wound” in to your product. It hits home once the release is deployed in to production and you start hearing about escalations regarding functionality that use to work. These issues can be both in terms of “you broke it” and “performance now sucks”.
It ruins everything: All that hard work you put in to adding some great new feature is now lost as the customer can only focus on what you broke.
I believe that before any code is pushed in to production the team should be able to answer these questions:
• Will you cause harm in this release?
• Have you broken something that use to work?
• Is performance at least as good as it was in the previous release?
At some point in my career I started asking these standard “Do No Harm” questions at every “Release to Manufacturing” checkpoint meeting. The purpose of these questions were to be very clear in terms of what was important to me–in addition to delighting our customers with “Gee I’d Buy It Just For That!” new features and capabilities I also expect a customer’s confidence in the release not to be undermined by discovering regressions.
When I first started asking these questions I’d get blank stares in return. Over time I started to be assured that everything was okay, but when I asked “How do you know?” I’d get folklore as to why folks believed their answers. Nobody really liked my follow up statement to this “wish it and it will come true” positioning: “Prove it…” Eyes would roll and folks would complain that I was changing the rules to the test; this expectation had never been set by previous leadership and it wasn’t fair for me to ask only at the final checkpoint meeting before a product was released.
They were right–it wasn’t fair that it was being asked only at the very end… At the same time the issue wasn’t with me nor my questions… The real issue was that the teams were not asking themselves these questions throughout the entire software development cycle. I didn’t let this sway me and I kept asking and asking and asking.
Progress! Within just a few months all of my teams began showing me their test coverage over existing functionality (some even with dependency charts that showed where changes were made, the risk those changes posed to other areas of the code, and how those areas had been focused on for regression testing/scripts). They would also come to me with their performance test results such that they had sufficient proof. Did that get rid of these issues in production? Not entirely, but it did greatly reduce them.
The miracle came within about twelve months as the teams began to appreciate how bad regressions really were… With every build many teams now knew the answers well before these final hardening sprints and checkpoint meetings. Some had even decided that as part of their continuous build processes that the appropriate unit test harnesses would execute both regression and performance checks; failing the build where appropriate and becoming a core component of their “Quality Up Front” initiatives.
In the end the teams’ solutions became more reliable and customers were not being negatively surprised. The teams were spending more time adding new features vs. working on emergency patches or spending time catching up with what they had broken in the previous release. All was well in Whoville.
Does your team suffer from self-inflicted gunshot wounds in production? If so, does your team have a “do no harm culture”? If not, is it worth it to start asking these three questions with each and every release? With each sprint? With each code checkin? Try it…it worked for my previous teams; I hope it will work for yours.
Update: I’ve adding a link to a whitepaper called “Girls in IT” at the bottom that not only highlights the issue, but what can be done to help solve it.
After reading a lot of nonsense on this topic, I came across this great article by Hadi Partovi, who is a co-founder of Code.org. As opposed to diving in to stereotypes, like other posts and articles have done over the last couple of weeks, Hadi cuts to the real reasons. The first reason he cites as being the primary cause: Computer Science is not taught in US schools! Duh… He’s so spot on I don’t know where to begin! I’ve worked with lots of young women as part of TechStart Education Foundation’s Oregon Game Project Challenge and girls are interested in learning to program in K-12. One key problem is that by 7th and 8th grade there are just not that many opportunities to get plugged in.
Please give this a read and then learn more about how to support #STEM programs and code.org in your local K-12 classrooms.
Here is a whitepaper called “Girls in IT”. It talks about the shortage of women in technology and trying to narrow the gap. http://www.bespokesoftware.com/wp-content/uploads/2013/12/GirlsinIT_white_paper.pdf (via @ShimCode).