/ software

Bad software can kill you, and at this rate it probably will.

When I started out in my career I worked on video games. Everyone worked very hard to make sure that the game we were building was the best it could be, quality mattered and was a big part of that. That said, I remember hearing and making the joke that we weren’t making heart/lung machines as a way of drawing the line on a particular bug or feature; the line between valuable quality for a video game and something that doesn’t matter that much because we in fact were making something that had pretty low stakes in the big scheme of things. A pixelated death not having quite the same impact as a real one. We tested to make sure the game worked fine on leap day, but we might not have fixed a minor bug that only happened once every 4 years.

We expect our technology to work well in a wide range of very complex scenarios. Good software components work together to support this, but good software is remarkably difficult to build, support, maintain and pay for. Good software requires substantial investment from top to bottom, and the bigger your product gets the deeper you need to make that high quality foundation. It is unfortunately not just as simple as going slow and spending money, good software in complex use cases requires actually solving the problems of that complexity step by step, chunk by chunk. Most of the time spent doing this looks ineffective to an outside observer.

You might be surprised to find that not everyone actually wants to make good software. Large numbers of problems have been solved already. Many of these solutions can be reused, and the good software already made can give you a substantial head start. You can deliver substantial, successful and profitable products quite quickly by connecting these pieces together into a new solution. If your customer demand isn’t that complex, it will probably work well. Unfortunately most of the time the results of efforts like this are quite complicated. Complicated software solutions are usually cheaper and faster to build that ones that solve complex problems, but the complication prevents you from evolving them quickly, responding to problems, or eventually, building on top of them to become something more than you are. A complicated software product will almost always be more expensive in the long run.

For many teams it’s better to build quickly, avoiding the complex problems, and then deal with them later when you have money coming in. Letting your customers pay for the difficult expensive work is a tried and true business plan. There are many companies that should know better, if you plan to be in the business for the long haul, or want to expand your product quickly, the investment in high quality software will pay off 10x. Politically this can be difficult sometimes. If you can’t explain this distinction to management, management will always make the wrong choice.

I remember one notable example. A team was making great progress on a high quality product something that would set the company up for a long term solution, but it wasn’t understandable for a non-technical management team. They ended up spending several multiples of what it would have cost to finish the internal product, and ended up with a rigid solution they couldn’t control instead of the solution they needed. In the end the people who made that “safer” decision all ended up losing their jobs, and autonomy, but it’s doubtful if any real lessons were learned.

The company culture has a big influence on this. The expectations on a company making video games should be different than that of companies making elevator control software, autonomous vehicles, or say aircraft control systems. Gregory Travis writing in Spectrum about the 737 MAX nails it:

It is astounding that no one who wrote the MCAS software for the 737 Max seems even to have raised the possibility of using multiple inputs, including the opposite angle-of-attack sensor, in the computer’s determination of an impending stall. As a lifetime member of the software development fraternity, I don’t know what toxic combination of inexperience, hubris, or lack of cultural understanding led to this mistake.
But I do know that it’s indicative of a much deeper problem. The people who wrote the code for the original MCAS system were obviously terribly far out of their league and did not know it. How can they can implement a software fix, much less give us any comfort that the rest of the flight management software is reliable?

I completely recognize this behavior and it’s actually incredibly common. Someone lost sight of the fact that they were working on software that needed to be good al the way through. They were working on that the proverbial heart/lung machine. They built a solution that worked along the simple every day path, but because the real, more complex problem of using everything we know about the aircraft state make the right decision was unsolved it fails in a tragic and catastrophic way exactly when needed most.

In the 737 Max, only one of the flight management computers is active at a time—either the pilot’s computer or the copilot’s computer. And the active computer takes inputs only from the sensors on its own side of the aircraft.

This is completely indicative an unsolved problem, an opportunity to write good software that was skipped. The flight management computer software was not built to reconcile conflicting or inconsistent inputs. Two machines that generate differing results without a system to reconcile them isn’t redundancy, a confusion generator. Trust the machine that isn’t trying to kill you isn’t a solution.

Was the 737 Max software project started with the mission statement of: Update the latest 737 software to perform in the new aircraft? I’ll bet it was something like that, something that frames the problem as narrow in scope and commercial cost. Good software demands that engineers dig through complex problems, and solve them, which is an activity usually incompatible with just a quick update projects.

Software teams that have our lives in their hands need to be constantly aware of where they are and aren’t solving these problems versus working around them. There is room for both in a commercial setting, and sometimes a quick hack is exactly what’s called for; but if you look at your software product and you see more avoidance than solutions you are probably not working on the kind of good software you would want your life to depend on.  It has to work every day, even on leap day. It has to work when it’s loud, when it’s dirty, when there is a spider nearby. This kind of reliability in complex scenarios is not a solved problem, you can’t get it from a box or an open source repo. You can only build it, one step at a time, as fundamentally good software. Companies will need to make the investment, teams will need to find better ways to explain complexity and dig deep. If software is going to eat the world, we better make sure it is good software, the alternative is not the kind of robot apocalypse we see in the movies; but it will still kill us just the same.

Learning is going to be sticky.

When the first iPhone launched in 2007 the features and capabilities of the phone were revolutionary, but it’s often forgotten that the app store as we know it today wasn’t avaible. There was a tremendous hunger among developers who saw the future land rush, but couldn’t build native applications yet.

A year later when the app store launched, the phone took off, and we really entered a new era.

From the moment that people were able to add applications to their devices, effectively customizing their phone to their life, the dynamic changed. Competition wasn’t really possible in the way it had been before.

Prior to the app store, we all looked at phones as a collection of features. This one could do email really well, over here we had a cool music player. One persons favorite form factor was anothers annoyance. You would buy the set of devices that matched your life, the phone was just a part of it.

After the app store, we simply made our phone the collection of features we wanted and needed. Instead of competing with a single iPhone feature set, all would be competitors needed to compete with a great solution for each and every unique combination of hardware and software. By making a personal device that was actually personal, the landscape and customer expectations shifted rapidly, the value an individual saw in their device wasn’t what came in the box, but rather the personalized solution it provided.

This is just beginning to happen again in a new way. It has the potential to vastly alter how people think about the technology they use, how long they keep things, and what is expected of hardware and software in the coming years.

Software, using the capacity of machine learning and hardware accelerated neural networks is going to begin learning a lot more about us. Our preferences, habits, desired routes, processes and routines are all a few years at most away from being captured by the tools we use.

I suspect that the majority of these insights into our behavior will be welcome, though of course there is an opportunity for the companies applying this technology to take it too far, or combine it in ways that could invade privacy. We should be vigilent for that, while also welcoming some of the life improvments that will come along with it.

Some simple examples to help illuminate this:

  • There are two exits from the highway you can take to get to your house. You have a preference for the second one because there are less traffic lights, even though the miles driven is slightly further. The navigation in your car insists that the first is better. Soon, your navigation system should be able to recognize that for some reason you always take the second exit. It doesn’t need to know why, just that it can stop yelling at you and ‘recalculating route’.
  • When you get home from work every day, it’s usually around the same time. In the summer months, it’s still light out, but in the winter, it’s dark. The first thing you do when you get home is turn on the light, but only in the winter. Systems in your home should see and learn this, automatically turning the light on for you, after sunset, in the winter.
  • You get paid every other Thursday, and once a month, after the second paycheck you transfer some money into your savings account. It’s a manual process, you could set it up to happen on a particular date each month, but your paycheck date moves around a little and you want to make sure it happens after that second one, so you do it manually. This behavior isn’t that complex, and should be automatable.

Each of these behaviors is a small difference from a default, the kind of thing that we all handle every day. The ability to capture that small variation, personally for you, and apply it correctly is at the heart of the upcoming personalization trend, and it’s going to change how people think about products.

Take a voice assistant like Alexa. So far a lot of the value in Alexa has been enablement focused. I bought Alexa and now I can turn my lights on and off with my voice. These enablement features however are usually handled through platform APIs that can be used by a wide range of products. Telling Alexa to do it is the same as pushing a button in an app, it’s just a different kind of keyboard.

There is limited stickyness to these products because it’s still very possible to switch out Alexa for Google Home, and get the same kind of results.

Products and systems that learn about you will alter this dramatically and as fundementally as iPhone + App Store altered the phone market. The connection to the API is completely replaceable, and invisible to the customer. What is unique is the learning that system has developed about me, my habits and preferences. I’ve trained it, and in doing so I’ve created set of differences that are unlikely to be replicable by another product out of the box. Even with equal capacity to learn, I’m still faced with the daunting task of re-training.

Products that learn will become increasingly valuable in our lives, but they will also become increasingly sticky and leaving them behind will be more and more difficult as the value that comes from that learning will be unique to me and irreplacable.

Why people have the wrong expectations for smartphone growth and innovation.

Around midnight last week, we turned on the Seattle local New Year’s Eve broadcast, sponsored by T-Mobile, and happened to turn it on just a the moment the T-Mobile executive was using their sponsorship time to talk about how 5G was going to change the everything for everyone. He gave examples of how 4G had made Uber possible, and a variety of other examples of why the future was going to be wonderful here in Seattle with T-Mobile.

A few days later Apple issued its earnings warning with iPhone in China as the cause behind the miss in earnings. This caused a variety of people to talk about how boring iPhone is and that no one is buying smart phones anymore. Ignoring the macro-economic factors in China, and whatever is going on with our spray-tanned trade warrior in chief. I think there is a lot of confusion about what actually makes iPhone special within the larger smartphone ecosystem, and what innovation will mean in that business.

First, it’s important to remember that we are basically only 10 years into the seiesmic shift of smartphones and mobile devices as primary computers. Technology evolution moves much faster than how we as human beings change, so when a device that’s so personal and personalized to us and our behaviors emerges it’s easy to see those initial versions of a new product and the significant change between them as major innovation. In reality, when building a complex new product, especially one with both hardware and software complexity, you are always making major compromises. Compromises driven by power, form factor, time, cost and more. It’s one of the most difficult parts of product development, but dealing with those constraints in a way that still leaves you with something interesting to sell is the magic.

iPhones are an innovation that is borne of a significant number of pre-existing technologies, being managed together into something that’s significantly different than what came before. Innovation in materials, software, design, and more abounds; but at the core the first iPhone was a computing paradigm shift for consumers. Moving your phone from an appliance to a general purpose computer. Every other smartphone since has copied or improved on that core innovation.

Since the first iPhone, a ton of improvements have been added. Screens and cameras have gotten bigger and better, finger print readers, depth sensors, processors, materials, batteries, wireless tech, you name it. The worlds most valuable real estate (whatever’s in your hand) became economically viable for development, and many people have invested hours and billions in making things that take advantage of the still new fact that basically everyone who can afford to participate in the developed world economy can buy a device that puts a computer, communications, the worlds information, and endless wonder in the palms of their hand.

These new technologies have improved the usability and usefulness of the smartphone in amazing ways. The device I hold in my hand today is substantially different and better than the device Apple launched in 2007. However, in the big factors it’s hard to see any single change Apple made as anything other than an improvement and refinement of their initial innovation. One of the most powerful parts of the core innovation with iPhone was just how immediately obvious it was that we were looking at the future. A million apps were born in the minds of creators in those first few years. You can still pick up an iPhone of 10 years ago and see the hints of the future, and the family resemblence today.

A lot of that has to do with a simple fact. We have hands, we use those hands to hold and tap our portable computers. Our hands have a range of sizes but it’s not that big, these factors aren’t changing, so as long as we are talking about a handheld device with a particular interaction, it’s going to trend toward a fairly narrow range.

People talk about changing the notch to be a pinhole sized front facing camera or similar minor changes as innovation when the come from handset makers that aren’t Apple. It isn’t innovative, we all know that the eventual destiny of the phone is a full uninterupted front screen of some type. Improvement yes, valuable yes, innovative not that much.

The next big innovation in hand held computing is likely to come from when one of the core factors of the smartphone has the opportunity to change. For people to recognize that change as real innovation, it’s almost certain to be related in some way to physical form factor changes. Which are closely connected to human factors which aren’t changing. This kind of innovation is far slower, and requires that big leap that only comes along once every decade or two. Maybe something like foldable screens, or some sort of micro projector.  Something that breaks the intrinsic association between smartphone and human hand.

Until this major shift comes along, the kind of evolutionary changes and improvments we see year to year in iPhone and other manufacturers products are actually what we should expect and be excited about. I remember when I switch to iphone from a Blackberry and I went from having to charge my phone once every other day to twice a day. Sure I was doing more, but man… battery life sucked. Ten years later, and I use my phone more than ever but most days I plug in before I go to bed and still have 15-20% charge remaining. In the first few years of iPhone I felt compelled to buy a new one as soon as I was able. Sometimes the screen broke, or some other problem hit, but because the early iPhones were brilliant products full of compromise we all bought them as soon as we could.

Now we are all able to keep our phones longer. That’s a good thing. A two or three year upgrade cycle is healthy in a mature product, and even with the higher ASPs we see the per day price of a much better product dropping down pretty substantially. That’s great news for consumers. It’s what lets the total market for smartphones become much more accessible without becoming a commodity. A device that costs $750 and needs replacing every year is accessible to a much smaller slice of the world market. A “boring” device that costs a thousand dollars and lasts for 5 years, is something that can achieve ubiquity and we should all be looking forward to.

There are still billions of people out there who don’t have smartphones. They have been adopted incredibly rapidly, and yet billions don’t have them. There are just about as many TV owning households in the world as there are households. About 1.8-1.9B, there are slightly more smartphones out there with somewhere between 2-2.5B depending on who you ask. The TV took almost 90 years to reach this kind of ubiquity, and thats for a device where many households only need one. We don’t know how long it will be before a major innovation that makes your iPhone as obsolete as your (awesome) Motorola Star-tac is today, but if we want to see the five billion non smartphone owners buy in, it will absolutely be to a low total cost of ownership, high value, long lived, robust device. Unlocking that market will take years, but there is a lot of money there for the kinds of devices that aren’t “exciting” every year.

/ software

Enterprise Software and Organizational Fear

I read this article today which is a very good look at some of the things that happen in IT organizations. I've worked in a couple of teams that operate this way, and it's absolutely a shock to the system.

One key element for the author Ian Miell is that his experience and observations are driven by highly regulated financial institutions. Places where audits and regulatory compliance are baked in for good reason. I'm sure it's all true, and that even the horror stories in his story are gentle in comparison to some of the things he has seen.

I've asked myself some of the same questions in the past and tried to reframe some of these big company problems around ownership and individual empowerment for the teams I've led. What's different is that unlike the author I've never worked in a company that was subject to the kinds of regulations he describes. Some of the systems I've managed have been subject to Sarbanes-Oxley level auditability and compliance, but very small parts. I've worked at places that had government contracts that required certain hiring practices and similar, but compliance with these things wasn't onerous, nor did it substantially intrude on the day to day technical work by statute.

So why does this article ring so true? In the non-regulated organizations where I have seen these same behaviors I think it comes from the same root. Fear.

It's unquestionably a powerful motive, you can be afraid of regulators and audits. You can be afraid that people will find out you don't know what you are doing as an executive. You can be afraid that someone will make a mistake and it will cost you something you can't afford to lose. This fear isn't unreasonable. In fact I'd suggest that most leaders in larger companies should be more afraid of the technology that runs their company than they are.

So many of the systems we use are riddled with holes, unpatched, out of date, things that are effectively not understood by any current employee, or not even known about by a current employee. More than once I would start the day with an alert email and find a new service that no one had ever heard of before, but don't worry it's still getting production traffic. The complexity of the typical enterprise enviornment is far beyond the manageability of the typical team.

Senior leaders are, and should be terrified of this monster in the basement they don't understand. Many public companies conflate a problem that can't be solved right now, or in a quarter with an unsolvable problem. This is not true. If it took you a decade to build your way into this mess, you need to expect it's going to take some substantial time to work your way out. I've seen what happens when leadership lets their fear trickle out into the organization. It looks exactly like the regulation driven enviornments. A world of "Cumulative Constraints" all focused on making sure that people are safe. Slow is safe, inaction is safe, corporate responsibility is safe. The longer we hold the collective agreement that everything is fine, the longer we can avoid really addressing the problems that exist.

To turn this around a lot of organizations need to change both their practices and what they are afraid of. The fear of the trouble we are already in needs to be greater than the fear of changing something or a mistake being made so that it's no longer safer to go slow, and do nothing. Things go wrong in new work, but those things can be fixed, predicted and managed. Active work is massively easier to turn and align than the large legacy systems that exist untouched for years. Existing software isn't an asset it's a liability. Odds are that the line of code that brings you down was already written. Change, managed by thoughtful technologists is your only escape from it.

/ software

Dogfood the Crap Out of It.

A lot of companies these days are worshiping at the altar of "Product" and while that is probably one of the better altars one could worship at, it does set up a new kind of problem.

If you have a product in the market already that you are tweaking and enhancing this can work, but in cases where you are trying to do something new, or different it's easy to focus on your current customers, and before you know it, your road map is full of customer requested features and customer data from focus groups set up by product managers trying to answer difficult questions.

Most of us spend most of our time working on something that is just this kind of incremental advance. Your customers here are often deeply immersed in the product; they are in it with you and it's pretty straightforward to have a conversation with them where you are imagining the future together.

On rare occasions we get to build something new, something where we have the potential to redefine an entire market. Here you are solving an unsolved problem, or radically changing something from the normal way. This is where your customers can't help you as much. You imagine a change to the world, but it's almost impossible to bring along a potential user without putting something that makes that new experience real for them. Until you see and touch different, your advice is often locked to your current frame of reference.

In 2006 the second smartest group of cell phone people on the planet still thought this was amazing:


They weren't wrong, they just didn't have the radically different world view that was about to become normal. Internally you need to be able to hold that vision for the future across as much of your team as possible, and you are going to want to do that until your product is really good enough to show off that vision to a potential customer. Dogfooding, even in short term rounds is one of the best ways to do that. If you can't get your own team to use it, how could you expect someone else to spend money on it?

I've seen a lot of examples where people got disconnected from what matters because they had a customer approved feature list, and focus group data showing that the features were usable. When customers actually started using it, there was nothing special or better about it than other products. In fact what stood out was the number of places where there wasn't a competitive feature rather than the features delivered.

Ultimately the reason for this was that in serving what customers had asked for, the team lost track of what made the product special and worth building in the first place. Most customers are change adverse, they want the same thing cheaper, or a little faster. Right up until the moment someone shows them a better way; if you are lucky enough to be working on something new, a product that has a chance to stand out, don't miss the opportunity to make it special instead of just retreading another product already in the market.

Starting a New React Application in August 2018

The React ecosystem has become a fantastic tool set for developers on the front end. It has come a long way in the last five years, and for the most part it's a lot of fun to work with.

I still remember my first experience with it and how enjoyable it was to build a web application. I never built anything super complicated but it mostly just worked.

I've kept mostly up with the ecosystem since, but this week I started working on something in earnest. The most visible change over the last 18 months is the degree to which Redux, and the associated tools for Immutability, Sagas, Selectors, etc. have all found their way into the boilerplate. create-react-app remains a good basic starting point, but most boilerplates include a lot more. It's very easy to get caught up in the heavier structures from day one, because of course my application needs to scale, and be out at the bleeding edge (it doesn't).

Each of these things however requires time, and a contextual framework to learn how they connect together. Each a layer of abstraction on top of another. It's probably worth revisiting Dan Abramov's advice on this, basically don't use this until you need it, because you might not.

Setting up your project however is one of those things that everyone seems to spend a lot of time on, it's kind of like finding a place for everything in your kitchen. Just remember that it's actually not the most efficient use of your time. You are going to pay maintenance and upkeep costs on your code base no matter what. it's unlikely that you are going to save much by having everything perfect from day 1, so why not take advantage of the speed of a "sketch" to prove out some ideas. Sure you will have to go back and add whatever the latest tool in the ecosystem is at some point anyway, but let's be honest, in an ecosystem changing this fast you were going to need to do that anyway.

These Articles are too Long

It has been a while since I wrote, but I've been busy writing on a couple of topics, including how teams can balance customer voice with their own vision.

I probably need a way to figure out a shorter article style, something that can be written in a lot less time. I tend to write and work in complete thoughts, or complete thoughts for me. So I'll try a short piece here.

Getting to Done is the Easy Part

I've worked on a fair number of projects in my days, and I regret to inform you that we have found our way into a bit of a pickle.

Photo by rawpixel / Unsplash

In the old days of video games, you would work for months and years, crafting your best product and then send it off to manufacturing. It was out of your hands. Every decision, good or bad would show up on that disc. If you cared about what you were doing, and most people did, you worked way too hard to make sure that you put the very best product on that disc you could. Then you moved on. It was rare to get a chance to revisit those decisions, because even if you could fix it, you had no way to get it to someone. It had to work the first time.

Hardware to some extent still operates this way today. Though even the amount of opportunities to fix in software are greater than the past.

The combination of the flexibility of software with ubiquitous network delivery has allowed for a great many things, but one of them is making for some very difficult decisions.

Today, software projects take on two major forms. The hot new startup with an exciting solution to one of life's challenges. Or more typically inside existing companies a project to provide an existing service digitally. Despite sharing a lot of of similarities, these two types of projects get shunted into two very different approaches. Both approaches lead inexorably to this same point, a moment where you have a fantastic opportunity to fail your customers because done doesn't mean what it used to mean.

Let's begin with the hot new startup and see how they might get to launch:

Photo by Brandon Morgan / Unsplash

You have an idea, it's a great one. One of those visions that strikes like a bolt of lightning, and for a moment you can see it in perfect clarity. You even know how to build it. From the moment you tell another person about this idea, you will be questioned. How, why, when? These are all good questions. You will need to answer them well enough to get someone to give you money, and from the moment you take that money the clock is ticking. Even though the world has validated your idea enough to give you money, structurally they are still predicting you will fail. Almost everyone fails, especially when you define success at multiples like five or ten in short time periods. The successes are few and far between, but they are so big they can afford to pay for your failure and the failure of ten others like you.

What they can't afford to pay for is the time and energy it takes to do it right, all the way. That ticking clock is covering your costs (if you are lucky) to prove a gate, show traction, get something off the ground. Your runway is short, and most of the time you are going to get one shot. You build the smallest, leanest thing that has meaning. That minimal product. You calibrate with potential customers so closely that you might as well just move in with them. Everything you see pushes you there, and you are told it's the safest path to success. That's sort of true. It's just not you they are talking about. It's the safest path for the money. It helps you to become one of those successes or failures as quickly as possible so you spend the smallest possible amount of their money to find out which you are. You do all these things to get to a launch, and you are lucky to have it.

For the company looking to improve an existing business with a new digital product, in many cases everything that happens is almost the exact opposite. People believe on day one they know the size, shape and rules of the business. The team is in place, the launch date is pre-ordained. The company is confident they know what the customers want because after all, we have been doing this for years. The project budget is the salary of the team, or the bid of the winning consultancy. There is a methodology in place and that Agility will allow the company to figure out those minor details along the way.

Fast forward a quarter or two and all that unsolved complexity has turned your small digital effort into a many tendriled thing that is clearly going to be much more difficult than anyone can have predicted. The solution starts to get chopped, and narrowed in a very painful way requiring the technical team to build less software and still hit a broad feature set. You haven't lived until you have spent a week discussing how cutting these ten unimportant features didn't actually help reduce scope. Teams persevere and keep their epics in priority order, quietly watching the cut line creep closer to the top of the original list than the bottom. Some businesses are just seasonal, we aren't date driven, except when we are. All your hopes and dreams for making this new product great are deferred, now you just hope to survive it. You do all these things to get to a launch, and you are lucky to have it.

Shipping something is it's own reward, letting something you worked hard on out into the hands of others comes with a special kind of hope and anticipation. It's great. As long as you were actually done. Back in the days of the disc, you may have been date driven, Christmas being notoriously resistant it's July relocation, but you were done when you were done. Unfortunately neither of our products are done at launch. They aren't done, but the team almost certainly is. Perhaps they are out of money or need to reach some immediate revenue goal to stay ahead of bills. Maybe they are just exhausted from a crunch to deliver. In most cases the team has put everything they had into their product, a product that is smaller, less interesting and more fragile than when it was conceived.

Those first users show up, and two problems emerge. First, something probably doesn't work the way it's supposed to; it happens. Second, you now have an order of magnitude more voices asking for things. Your idea is out there in the world, if you are lucky people like it, but you have stripped it down to the bones so of course they want more. This moment is often the pivot point, a moment when it could go either way. Your window for learning and responding to even a slight gap can be days or even hours, and at the time you need to be your best, you have nothing left.

I worked on a product once, it had a very market driven date, and a short timeline. The full set of corporate leaders bought into the idea that it would be thin, do one thing, and grow slowly. We could live with that thin thing for a year and spend that time to fill in the gaps everyone was painfully aware of. Instead six weeks after launch, all of those gaps needed to be closed, minimum viable wasn't. People hadn't imagined just how minimal it had needed to be in that tight timeline. It went poorly. The most heartbreaking part was that all the things people said we needed were all part of the plan, all goals on the list. Just lower priority than launch with features 1-5 on this date. The team had no energy left, and lost faith in their prioritization process. There was no time, and the buy in from leadership on the plan provided no cover.

Ironically it's the corporate world that could fix this problem more easily than the startup world. The startup money ecosystem being what it is, means that those teams won't get the time and money to do it right unless they find some form of patient money that doesn't seem to be all that common.

In the corporate world however, this is a self inflicted wound. Too often projects are planned with fixed dates, scope and budget. It’s usually not described this way, because that wouldn’t hold up to scrutiny, instead these constraints exist independently in the minds of stakeholders uncommunicated when they can be addressed without it being a crisis.

Photo by Robert Metz / Unsplash

Often these interlocking constraints are not handed over to the team to optimize for, but held with ownership and decision making also diffuse. This makes it impossible for the team to make the kinds of trade offs required to get to any definition of success. A team can typically optimize for a very small number of things at a time, and only when they have a high degree of control over their key project variables.

Another common kick-off behavior is underestimating the amount of time and investigation a team needs to put in to start something new. Often a schedule might seem reasonable if the team has 12 months of solid development, but when the first three months of that development are spent on the team getting up to speed, building up context and figuring out all the details of what they are expected to build, that schedule just became unrealistic. The exhaustion and inevitable disappointment are baked in. Leaders repeat this mistake because they think that if they understand the project that everyone else does too.

In most cases the depth of understanding is limited to that leaders domain, and needs a lot of refinement before it can be built. Starting with a small fraction of the projected team size is a great way to avoid this early stalling and burning up your financial resources before you are ready. It won’t help with your schedule unless you get that small group started before the official clock is running.

Perhaps the most important opportunity for corporate projects is to build a mechanism for elasticity of expectations into the project from day one. Expand the definitions of success all the way to the top. Build into your process a mechanism to adjust in the clear light of day. Everyone should have the expectation that some trade offs between time, cost, and scope will be exposed at regular intervals. The team will be looking for support as they narrow in on the actual path.

If you have some immovable constraints like a maximum budget or ship date, carve out space within those to make some other elements less aggressive. Talk about what it means to do less with less to keep your risk envelope smaller. If you can’t get buy in on that, make sure you get those leaders to express their constraints all in the same room. Often they will create that space for you through their disagreement. If your CFO is limiting the budget, and that’s the constraint in scope, she can convey the seriousness of that to the head of product better than you can. They are senior leadership for a reason, I’ve seen cases where the politics were intense enough that a team just needs to present the constraints and ask do you all agree to set off a complete reset of those constraints. Failure to set up this flexibility almost always results in those stretches to reach some unsatisfying outcome.

Ultimately when you see this coming, the worst thing you can do is nothing. The longer you go without addressing it the more people will start to layer their definitions of success on the product, and the thinner your project will feel to them when they judge it. Your customers are going to feel that thinness too, and are going to expect you to fix it, or give up on your product quickly. Success requires not just delivering something that’s done, but also making sure you have the capability to meet the evolving expectations of today. If the business is strong enough to justify an investment, it’s worth the time to think through the long term investment and make sure your project supports that long term.

Maker tasks for PMs no matter what your 'P' Stands For.

Program managers, product managers, delivery leads, Scrum Masters, and other roles are everywhere these days, and there is constant tension between these roles and the developer roles at a lot of companies. In my observation there are two key reasons for this tension.

One of these reasons is at the organizational control level, the other is in the hands of the individual PM. If you want to be successful in a company building great technology products in a role like this, having the support of the technical team is a must, and it's easier than it might seem.

Let's start with the organizational challenge. In many companies, the PM role is seem as the part of the team that is connected to the "normal" part of the company. Your business, finance, operational and executive teams all feel like they can speak a bit more of that language, and Power Point is usually faster than code. It's very easy to make PM responsiveness to change a proxy for product development response to change. This is all well and good to start, but many software products don't go as well as people would like. When this happens, it's a natural reaction among management to increase the investment in things like product, project and program management. The visible, understandable part. After all, in most cases it's the development team that didn't get it done.

Over a few product cycles of add one more, you end up with a product/dev ratio that starts to mean that the second problem gets worse and worse. This ratio really matters, because while the part of the PM that is focused outside the team can certainly be increased, there is a limited amount of inside the team work that can easily be done by a set number of developers. If you have more pm than developers everyone will get frustrated and angry because all those great ideas can't be executed on.

The part of this that can be controlled by the individual is how tightly connected you are to the team you work with, and how aggressively you look for work within the team that supports the mission. Some PMs look at their role as define the idea and then let the team do the work. Far better is to figure out what work you can do within the team to make that idea real and better than it was when you first had it. This work is harder, but leads to much better products and happier teams.

By thinking about the problem at the same time as the full team, you will be able to bring more of the team's combined voice into the product, this will result in better alignment and shared vision in a way that a document or wire frame can't always deliver. Each and every day as part of a team the PM should be looking for ways to make something of value to the team and product. Instead of summarizing the status or work of the team, what can you make that allows the team to go faster. What tasks can you take on that your broad organizational skill set will make you ideally suited for? Make sure that your tasks and the things you create are part of the team work flow using the same tools and systems that the rest of the product is managed through. Keep it visible, talk about it at standup, ask for help and share progress and accomplishment with the team the same way a developer might.

You are solving problems every bit as complicated as a developer, just perhaps in a different language. If you can translate that language into the language of the team, you become a maker and contributor rather than a drain or outsider. It's easy to spot the PMs who are working this way in an organization, their connection to their teams feels almost physical, and they always know what's going on with their products. Their ability to estimate and alter course is enhanced, as is their ability to speak for the team; ultimately it's because they are an integrated part of making something rather than a bolt on observer.

Android and Ad Ware

Like many people I provide a variety of technical support services for less technical family members. Over the last few years I've been encouraging people over to the Apple ecosystem, largely because it's what I use, and it's getting harder and harder to support windows machines when I haven't used a version of windows as a daily computer for a decade. It's not that I don't think that Android, Windows, etc aren't fine solutions for many people; it's just not what I use myself. When I'm explaining how to resolve or debug some issue, over the phone, with only a photo of a screen and a vague description, it's a lot easier to be able to see the exact names of the menu items, etc. So I've been telling people, these are the products covered by phone tech support, otherwise I'll poke at it if we happen to be in the same room, but I can't do it over the phone.

My father in law in recently brought me a problem however that I'm honestly shocked by. He started off the smartphone life with an Android phone, switched to iPhone, and then went back to Android at some point. We were together for dinner on the 4th and at prompting from his iPhone using wife he brought out his Android phone to show me a problem he was having with ads. I've apparently been living in the iPhone world for too long, because I've never seen anything like this.

First off this was a fairly recent model from Samsung, less than 2 years old. He was clear that he had recently updated the system software to the latest.

Even with that, every 2-3 minutes, even when not using an application, he would get a full screen take over ad. The ad could be closed, but very quickly after that another would pop up. This was not on a web page, or in some game, just sitting at the home screen, these ads would pop up. In the bottom corner there was a link to customercare-optout.com but beyond that there was no indication of what was triggering these ads. Was this Android itself, an app, something from Samsung or Verizon. Some quick Googling (probably how we got into this mess) got me here and here and here and a combination of deleting a game, resetting the device, turning off some targeted ad settings, and reinstalling Chrome(!!) seemed to make them go away.

Those message boards indicate that this has been going on for a long time. The domain is registered to a nice looking house in the Dallas suburbs, so I'm sure whoever is running this ad network is doing fine. What I'm shocked by is how on earth Google and hardware manufacturers allow this to continue. I can't think of any justification for a full screen take over of your home screen short of some sort of emergency alert broadcast. That Android even allows this without some sort of very aggressive messaging and confirmation on install of the application indicates something very disturbing.

Installing an application on Android is potentially enough to allow that application to silently inject constant advertisement on the most personal device most people own.

Living in NYC there is a lot of advertising. It's most visible however as subway ads, which are typically more like movie posters and similar. We mostly switched from watching regular TV to streaming services without ads, and that has left us perhaps more insulated from advertising than most. My phone feels like a very personal and private device. When we do watch some sort of live TV, I'm always shocked by the number of ads, especially on something like cable news.

My father in law however, still preferred his Android device, even with these ads to an iPhone, or more accurately he didn't see the iPhone as something he liked. During the time I worked on it, all of the ads I saw were very benign. He was also not as upset about the constant ads as I would have been. It occurs to me that it wasn't that far outside his normal experience. The idea that a full screen ad would take over my home screen and require a tap to get through before I could use my phone would be shocking. To him, just sort of how it is.

There is plenty of evidence (though older than I'd like) that Android and iPhone sell to different groups, and in fact it doesn't look dissimilar from the 2016 election map. We have spent a lot of press talking about the impact of targeted Facebook ads on the last election. It looks to me that for large portions of the US, it would be possible to produce a set of applications connected to an ad network, and with almost no protections send a near constant bombardment of ads all in the gray area. The area where people just think it's normal. An area where it's not monitored for compliance with political advertising laws.

Jellybean Decisions

Photo by Patrick Fore / Unsplash

These kinds of decisions go by many names, but I usually call them Jellybean decisions. It's the kind of decision that teams often spend a lot of time working through, but in the long run don't have a major long term impact, or switching cost is low later.

Once you have decided to eat a handful of jellybeans, how much time do you spend picking out the colors? Sure you might have a favorite, or least favorite, but those colors don't have a major impact in the long run. There is no ANSI standard for jellybean flavor/color correlation (I checked) so your results are probably going to vary anyway. In the end you are going to eat all of them anyway right?

Many software decisions, especially early on in your development process are similar. You might spend a lot of time thinking through the pros and cons of a particular database or language decision. Maybe there are competing UI frameworks or SAAS providers. Spotting and cutting these off is a key element of getting something off the ground quickly.

The risk involved in this kind of thing is that you will spend more time and energy making the decision, than the difference between the choices is really going to make. There is the inevitable meeting, and then a decision matrix. Let's take two or three to PoC someone will say, and before you know it you have spent a couple of weeks. During this time, you not only haven't completed the work blocked by this decision, but you have this sort of pending thing that in the back of their minds, everyone on the team is waiting for. That's a cost even if you don't see it.

Worse, many of these decisions have similar impact to your jellybean flavor. The kinds of things in your decision matrix have some impact for sure, but it's not uncommon to see very small impacts from choices like this, or things that boil down to opinion.

There are some areas where you do need this kind of deep introspection; where a decision will have a large impact in time or cost, and you should make sure you work through this in a way that's appropriate and aware of that cost. It is however seldom needed at the beginning of a new project, speed is almost always more valuable there, and central to execution speed is decision making speed. Exercise the muscle of allowing individuals to make lots of small decisions quickly. If you could switch between two libraries in half a day, why would you spend five days making the decision of which one to use?

Decision making is often difficult, but you can control how difficult you make it. Remember the time you spend choosing between things needs to be offset later in the project for that time to be valuable.

/ tech

Apple Announces Keyboard Service

I've been using a Macbook Pro 15" from 2016 for about two years now. I am pretty sure that all my keys work. I've certainly read about a lot of people who have had problems with the keyboard on these models, and today Apple announced a service program Here's the thing about this keyboard. Even with one that I'm pretty sure works correctly, the key feel and typing isn't what people are used to. I won't say it's bad, but it is different. Personally there are some elements I like about it but keyboards for people who type for a living are all about predictability and function.

I have absolutely noticed an uptick in typos in my own work. Missing letters, out of order letters. Places where I think I've struck a key, but in fact have just touched it and not triggered the character press. It's never a stuck key; if I went back to the same key and pressed it again it always triggers. I think something about this keyboard makes it feel inconsistent, like the key pressure to type is just a tiny bit harder than I'm used to, coupled with the short travel distance, I often feel like I'm touching a key but not pressing it. Maybe it's just me, but I suspect a lot of people's complaints about this keyboard are the computer equivalent of unintended acceleration due to pedal misapplication.

That doesn't mean user error, in most cases we are talking about effectively a design error, or weakness. The more unpredictable it feels, the more people start to notice those typos and the degradation of their typing. I think this could also explain Apple's uncharacteristic silence and ignoring of this issue despite all the press.

I've worked in hardware, and it's actually very clear when defect rates from the field are out of line with expectations. At this scale, very small percentages are quite large volumes of users. If there was a physical defect in the keyboard that was taking failure rates up to say 5%, Apple would almost certainly have caught that very quickly following the launch of the design as people returned devices. Instead I bet that what they are seeing is large volumes of people bringing their devices to stores complaining that the keyboard is fussy. When they take it in the back room they find that there is nothing wrong with the keyboard, physically at least. All keys work, diagnostics pass. There is obviously some percentage that is actually broken, e.g. you press a key firmly and singly and it doesn't register. I'm betting that defect number is higher that previous generations. Occasionally they find some crumbs or dust in the works, and this design is less resiliant than in the past. I also think that a lot of people, like me, just find that the keyboard is not as reliable to type on; but your friendly genius can't fix it because it's working, it just doesn't work well.

/ Why

Time Spent Making vs. Time Spent on Process

I've spent a lot of time observing teams. At first glance almost every team I see is working hard, and trying to do the right thing the best they can. Sure they may not be super effective or efficient, but it's not for lack of trying, and often not their fault.

One of the key things I look for is how a team works, and more specifically how they allocate their time. If you really think about it there are really only two things teams do:

  1. Productive work, making, building, etc.
  2. Communicating, estimating, justifying, and explaining the work, and status of that work.

These two types of things are really pretty different, and it is probably valuable to think of them as different modes. If you are explaining what you are doing and why to a manager, you probably aren't making something. In many large company teams, especially ones where software isn't the core competency when I observe an "inefficient" team, I find that they are spending big blocks of time, sometimes more than 50% on mode 2 tasks.

Certainly no one would be surprised that a team spending 50% of their time on non-making tasks would not be as effective as they could be, but what I've actually observed is that the cost to productivity for supporting any significant amount of mode 2 work.

This dissonance in process and switching between the two modes is often where teams, divisions, and even companies breakdown. Initial instinct might suggest that spending say 20% of your time on mode 2 tasks would have a 20% cost to productivity. In reality, it ends up being much larger than that.

First there is the cost associated with context switching. Stopping productive work for a meeting obviously doesn't just take the thirty minutes of the meeting, but more likely the thirty minutes on either side of the meeting as well.

Next there is the cognitive cost people pay when they are asked to spend time converting the work you have done into something consumable by a non-team member. People work most effectively when they understand what they are doing, believe it's the right thing, and are trusted to execute. If you can't allow teams to have these things, they are forced to pay for that gap in mode 2 behaviors.

Confidence and certainty in what you are doing has an out-sized impact on a lot of people. How should you expect an individual engineer or designer to respond when asked to stop what they are doing and make a list of their latest accomplishments? Or a task list for the future? The underlying message from management is that we don't understand what's happening. This is reasonable when there are big strategic changes, or new leadership, but for many teams this becomes their every day.

This sort of mode 2 focus creeps up on you over time. One more report, a slight shift in the ratio of staff, another ritual to satisfy an external requirement.

There is a quick check you can run on a team to figure out where they fall between mode 1 and mode 2 tasks.

Take a typical week and follow a couple of people on the team or have them self record using a time tracker. Keep track of what people actually spend time on during a day, over the course of the week. People will sometimes feel self conscious about this but you can also do it just observationally. Add up the time at the end of the week. Categorize it into one of 3 categories:

  • Working on the project, which can include team communication to solve "how" questions.
  • Process driven by the team need, e.g. standup
  • Process driven by an external need, e.g. status report

The first order check is on the overall ratio. There is always some process overhead and tax on almost any group endeavor, so you aren't looking for some magical land where the talking and process part is zero.

Next look at the split between process the team drives and needs and process for an external to the team need. I've seen cases where the team process was reasonable, maybe 10% of time, but to take that process and plug it into a the larger company process was another 10% of the time.

Finally, and this is the reason that even low time percentages have that out-sized impact. Count for the monitored people, how many times during the week do they get to two hours of solid mode 1 work not interrupted by any process tasks. There are basically two times during the day when you could get to a full two hour block, before lunch and after. How many of these process needs claim just a short window in those key productive times? If the numbers are low on uninterrupted work you will see people self selecting to not start challenging and importing jobs, and you are almost certain to see lots of business but limited meaningful output.

For leaders, if you discover that this split is going the wrong way in your teams, the onus is on you to change behaviors, in most cases these mode 2 behaviors are systemic, and driven by management asking for things. You can't just stop asking, you have to explicitly stop the pre-existing ask, and change the expectation. This will require you to figure out ways to satisfy the need for that original ask through a proactive engagement on your part, learning to understand the artifacts driven by the process the team is using rather than forcing productive work to stop to support these other tasks.

When you first start this you will feel suddenly blinded. Like things are out of control. Pay attention however to the way the team is working, key decisions, and the flow of work through to delivery and really understand it. You are simply removing the creation of an abstraction layer, all the information you need is there. If you can create an environment where each individual gets one or two more uninterrupted productive blocks a week you will likely see massive increases in value delivered, enough to more than offset any uncertainty about team efficiency.

/ Why

Organizational Methodology Adoption

How did your team end up using your current methodology? It's kind of a trick question, because if you are using a branded Agile methodology you have probably already made choices that are highly limiting to your teams empowerment, and the trust of the organization that's needed for long term success. Capital A Agile software development has fully infected many teams.

There are so many lessons to be learned from software development history. We stand on the shoulders of giants; but the leadership at many companies are not part of that on-going conversation. This means that you must assume that most of the time, we aren't presented with a thoughtful analysis of how a methodology might improve the work of the organization, but rather a much more simplistic cut and paste. It worked for me at [insert company boss used to work for]!

I think that when Ron Jeffries says "Developers Should Abandon Agile" this is what he is talking about in some ways. Methodologies applied from outside the team is effectively a wholesale abandonment of the individuals and interactions over processes and tools concept.

Good software development is about letting talented individuals and teams find their way to solutions. The productivity gains come when each member of the team can fully contribute. Each process constraint or rule takes options out of the hands of the team and replaces it with something pre-defined. Every team and individual is different, the right methodology for you is not one size fits all, just as the right technical choice is seldom exactly what someone else has done.

/ software

Problem Solving vs. Passing Through

It's a fine line for a lot of people, you get to be a manager and it sort of pushes you further away from the work, a few years go by and the time you had previously invested in staying up to date with the latest changes in languages, tools, etc., is now spent working with your team, or on manager problems. You can't contribute in the same way you used to.

One of the most difficult challenges a manager faces is to figure out how to maintain the contribution that got you to this new management role. Where do you solve problems, where to you make it easier for others to solve problems, and how do you avoid just being a bottleneck or a pass through.

First let's start with some assumptions. Any problem complex and interesting enough to not just be solved by the first individual who picks up the task is likely to provide an opportunity for multiple people to contribute. The best cultures tend to be ones where there is room for multiple types of contributions to find their way into solutions. But as a manager you need to ask yourself, what contribution can I provide that is valuable.

Where this goes wrong for a lot of people is thinking that the contribution you need to make as a manager is the same as it was before as the individual contributor, or that you can't make a contribution at all. The truth is almost always something in between.

Two types of managers you don't want to be:

  1. A new challenge emerges, and only you can solve it. Your team watches with baited breath, bursting into applause when you slay the dragon.
  2. A new challenge comes up, and you look at it, and you forward it to Kim with a note that says "can you do this today?"

In both these scenarios you really aren't doing what your team needs. In the first scenario you are trying to do too much, taking opportunity away from your team, and in the second you are doing too little, not really contributing much beyond a pass through.

Instead, look to your team, what do they need, where can you help. A good manager could help solve this problem in several ways, tailored to the needs of the team. If you first acknowledge that you are not going to be the one doing it, a whole series of contributions become possible. Perhaps you can connect the two people on the team that have worked on similar problems, or get a product manager to add a little more context.

Too often however, managers get the message that they shouldn't be doing any more, so they simply become routers and pass work through. This kind of behavior isn't actually supportive, because your value isn't assigning things to people, it's helping create valuable things. A good manager can add valuable momentum to every effort, with every touch. Those contributions can be small, but over time and large volumes they will add up. When you simply pass through you are actually taking momentum at each touch. Understand your contribution, and how it supports your team; making their lives easier without taking anything from them.

/ Why

Software Complexity and Leadership

I am of the school of thought that says software products are complex. Even, or perhaps especially, when you try and make them simple to your users. The technology is a part of it, but most of the complexity comes from the fact that you are designing and building something new. The work to understand the problem space, customer need, and how that intersects with the technology you need to build is all part of that. The most efficient process to implement something is usually not the most effective process to design that same thing.

Properly done, teams are constantly moving towards their goal, think a little, build a little, measure and repeat. From the outside however, that often appears uncertain, messy, and unpredictable. That perception doesn't fit with most pre-existing management conditions, so a facade of sorts is often placed between the team and leadership. This facade is easier to maintain than getting leadership to understand the complexity.

The truth is however, that the facade costs something, and the less complexity the leadership team understands, the more the facade costs even to the point that entire teams exist to maintain the facade.

Every time you create an abstraction between the complexity of your software and what you leadership understands you have a new opportunity for the everyday changes you make inside the team to drift further and further from what the rest of the company is expecting.

Here is where good leaders separate themselves from the weaker leaders. You need to find a way that works for you to understand enough of what's going on in the software effort to trust that it's going the right direction.

There are two viable paths for a leader to take.

First, listen to the team, trust them. Let them tell you what's important, and what they are going to do about it. You don't need to get into the weeds of the complexity, but you also don't get to make any tactical decisions. You tell the team what's important, and let them respond. You can ask questions and challenge assumptions, but you are ultimately trusting the team to both define success and make it happen.

Second, dig deep, put yourself close enough to understand large swaths of the complexity your teams face. Spend the time to immerse yourself in their culture, process, setbacks and successes. Help them from where they are, not where you wish them to be. It's usually not possible for an actual human to maintain all this complexity at large company scale, but the more work the leader does to understand it, the less the team needs to do to explain. They will come to trust leadership.

In the end this trust can and should be bi-directional and these two paths which seem to diverge rejoin in a high trust/low blame culture. The leap of faith to put your facades aside and focus on the actual challenges is difficult, but if you mandate the facade, you will get it, and once you are only seeing the facade, the job of leadership becomes luck and guessing.

/ Why

Why Companies Fail at Software.

Companies big and small, especially ones that don't have software deep in their founding DNA tend to fail more than they succeed in their software projects. The fabled digital transformations are very expensive, but don't always end up the way people hope. I've seen a few of these, and there are some common factors and trends. Watch this space for more on how to spot things going wrong, and some of the things you could do to avoid the pitfalls.

/ tech

Senate Review for Net Neutrality

The US Senate today approved the nullification of the FCC net neutrality rollback. This is a positive step, but to actually matter the house would need to vote the same way.

It's nice however to see Democrats and a few Republicans continuing to make an issue of this. It's a very good example of a complex technical topic getting various interpretations based on politics. There are a ton of different constituencies in the commercial space including tech companies, telcos, and media companies. The venn diagram of conflicting interests is surprisingly complex, and that's before you get the money and politics questions involved. People you think would be very in favor of net neutrality like independent media companies actually turn out to be significantly less in favor than it might appear. Détente is in many cases safer and more stable for these entrenched interests. Plus they figure if it ends up costing them something more the better in a case where they have the money and a smaller player might not.

Most arguments against net neutrality are just various facades on rent seeking behaviors. In reality network connectivity isn't that different from electricity. Utilities and municipalities needed to make large investments to build out their distribution network. The way you use the electricity you pay for isn't anyone's business but yours, and the utility companies seem to be doing pretty well. There are lots of people willing to tell you that the network is different, and it is, the difference is that we haven't yet established that it can and should serve the public good first and corporate profits second. You can find all the evidence you need for this in the tremendous opposition by corporations and politicians to prevent municipal broadband from gathering steam.


A quick look at Comcast revenue will tell you why they care so much about internet access. It's growing. They now have more internet customers than cable customers, and so now they, and other companies like them are focused on getting every last viable dollar out of that. Capital expenditures actually decreased by 5% to $2B in this same time frame, so they don't worry, they aren't taking all this money and plowing it into making your service better. What they are doing is $2.2B in dividends and stock buybacks.

So don't be fooled, there are two sides to this issue, corporate profits and control vs. ubiquitous internet. If you think you should be able to go to any web site, use any app, and not pay extra you want the internet to be like electricity; Net Neutrality is probably for you.

/ Roadmaps

Roadmaps Complete: Final Artifacts

But how do I turn this into something I can send my executive team?

Honestly you shouldn't have to. Your executive team should be smart enough to be involved in the motive creation, and be observing the approach definition process. Depending on the company they may be highly involved in that part of the process. The key to turning this material into something your less connected executives might recognize is in the early alignment stages.

If you are actually executing against a model like this, you are producing at least one Rally Point per iteration to show your work. More importantly you are marching clearly, step by step, toward an approach that people felt good about prioritizing highly. That approach represents one way of solving a problem important enough that you have written it into a company level motive, something no one can argue with.

The easiest way to do this is start putting your motives out on a time line. At this stage, all you can do is show a start date, not an end. You don't know how long it will take to you to finish but you should be able to identify when you can start. Start can be as soon as you have a team available to begin defining approaches and executing.

If you only have the capacity to work on a single motive at a time, that's ok, just reflect that, and have an area where you store your motives for later. Also remember, because you are working on things in the teams that are directly aligned with a motive, and are designed to be a single step, not longer than an interaction, you can plan for a sort of motive time slicing, and move toward several. If you do this kind of splitting, it's not "done" at the motive level, just directional. We are making progress on this problem, and will prioritize it until a specific date, or when we hit our goal, whichever comes first.

Layering approaches in below the motives should give you a second layer of granularity. Approaches are likely to be big enough that your customers will notice them, but small enough that you should see real, tangible progress week over week.

Our motives are big enough that you could easily put on a roadmap document something like:

This year we will vastly improve and simplify checkout experience by:

  • Combining multiple screens into a much smaller number
  • Introduce new account system so we save your checkout information.

Even if you need back away from some portion of the account system, you can later on make the choice to either cut scope or delay it. There isn't a ton of false expectation created by this, just that we decided that simplifying our checkout experience is important, and that we are going to work on that in a substantial way.

No specific number is given on screens, just the qualitative statement. If you go from eighteen steps to ten, you have still done something valuable. You can choose later if you want to keep investing, or move on to something else.

Instead of pre-committing to these, identify your motives and approaches. Then fill in your back trail with lots and lots of progress. Trajectory towards your motive is actually a more important predictor of the future than what you think on a particular roadmap day. Your customers don't care about what you wish you could do, they care about how you have made their life better, or solved their problem. Results. If you can show that you are attacking the biggest and the right problems, and making progress toward them every day, you will find everyone wants to hear your story.

We are making this better, and we are going to keep making X better until it's great.

Is much better story than trust us, in Q4 you won't complain about this any more, all the good stuff is in v3.4

If leadership can't see and work with these kinds of structures, it's not you, it's them.

/ Roadmaps

Roadmaps Continued: Work

There is no fancy name for this. Your team may call them tasks, or stories, or really anything. But no need to get too abstract. It's just work. The difficult little things we all do every day to make something.

Break down your Rally Points into individual work items for human people, use some sort of system to track them. Could be post-its, could be jira (if you really really have to). Try and come up with something that is optimized for makers, with a low overhead. In an ideal world you would extract these from the actual work of the team, but systems today don't do this well. Avoid any rude to build these out before the iteration starts, these are the answer to the question, "what are you doing right now?" And probably at the granularity of about 1 person for half a day. These are the kinds of things you might have one to two days ahead visibility on. A team member is likely to identify these tasks as needed every day. If you are doing standups daily and talking through what you are working on, and how it's going, every team member should have a working model of where the progress is. This intuitive understanding of "what's next?" Is important to develop within the team and keeping track of who is doing what task is how you get there. When you finish your work for the day, before you start on your next item you want to make sure that you aren't duplicating someone else's work, so creating that next work item is locally important to the team or group working on a particular rally point, but it's below the level of granularity needed outside the team.

To keep our example going, a few possible work items:

  • Bill — Provision database in dev, name it something and tell people.
  • Jane — Build a PoC login screen (unstyled)
  • Jim — Add styling to login screen when Jane has locked down the class names
  • Lisa — Mock up user serialization/deserialization on login

Final part: Artifacts and Acceptance

/ Roadmaps

Roadmaps Continued: Rally Points

Complex software requires a lot of work to scale and stay aligned. Many companies who don't have software in their DNA think that software like many industries will go faster with more teams, more individuals working on those teams, and more people over all.

Software development does not have economies of scale. Development has diseconomies of scale — Allan Kelly

Communication might be the opposite of software development. It's hugely difficult and time consuming. People literally speak different languages. Rally Points are all about translating your now well understood approaches into work that can be done by small groups. Small groups that you are confident are already aligned because they are working off an approach.

Iterative software development is optimized to move you forward in small steps toward a goal. A Rally Point is a single increment of that iteration. It's the definition of a single step, and the outcome you expect it to achieve.

There is a lot of scalability in this definition. An entire team can define a Rally Point, or it can be just one member of the team. What should remain consistent is that a Rally Point can be achieved within a single iteration with a high degree of confidence. This is all about splitting your work up into something that is valuable, achievable and sized in such a way that your prediction is a high confidence prediction.

Estimates are one of those things that everyone thinks they want, but we all know are almost universally wrong. You should only estimate to the extent it helps you make a specific decision, so instead of estimating our approaches, we will simply break them down into a series of Rally Points as we go. Let's do that with the earlier approach:

APPROACH: Most of our checkout process is the same information for every order, we should build an account system allowing shoppers to save their information and skip the checkout process entirely.

There is a lot to this when you start to peel it apart. Just off the top of my head I can see:

  • Need some sort of user storage
  • Login/Authentication
  • New UI for authenticated users, might spill out across the entire store system
  • Data privacy
  • Connect the stored user data to our fulfillment system
  • Need to make sure the old non-account system keeps working
  • How do we expose this new account to customers and get them to sign up?

Your goal in building Rally Points is to define the specific step forward, and where you will meet up with the whole. By linking the scope to a single iteration, you can make sure that people are thinking about these things a single steps rather than larger constructs. The larger your construct for work where you are defining actual work, the more likely your teams are to get lost along the way.

If for example your company had for another product already implemented a user account on another product, and was pretty happy with how it turned out. The team might want to build on that knowledge and experience, even if they can't re-use the code/systems. They might sign up for a Rally Point like:

This iteration we will setup a basic login flow in UI and back end service in our internal development environment. This will include the UI to login, the authentication service, and a simple new account creation UI. We will put a temporary user store in place, but not create the full schema for the user profile. This will let us create users and make sure people are authenticated to their account in a secure way while we experiment with UI in the future.

You can think of it as a sort of theme for the iteration. This statement should include things you will do, things you won't do, and it should have areas called out where you plan to do less than production ready work. Hold to, or improve on whatever standards you have in place for definition of done, and production ready. For some teams this may mean a release, for others who are covering very new ground it may mean something short of that. Bias towards release, but don't be so pedantic that you don't recognize that some highly valuable work may need several Rally Points completed before it sees the light of day. All of them should at minimum get a release to a development environment, sufficient to let other people see and touch it internally.

You could theoretically have multiple Rally Points per team in the same iteration. Either set up in parallel with small sub teams tackling each one all at the same time, or in series with the whole team working to get to each step along the way.

This is another one where you don't want to bite off more than you can chew. Most teams should have a fairly good good idea of what they can accomplish in a single iteration, and if they are wrong it's likely to have a low margin of error.

Rally Points can only be set by the team of people who are going to do the work. That commitment is at the heart of any kind of predictability or consistency. Teams should be expected to post/share their Rally Points wherever things are highly visible for your company. You should find time to read every team's Rally Points, it's how you will make sure your work is aligned, and that yo know what's going on across the product/organization. Keep them short and sweet, but pay attention to them, and talk about them.

Next up: Get things done, do the work

/ Roadmaps

Roadmaps Continued: Approach

We actually don't know enough yet to start fixing this problem, what we need is for the smart, creative, passionate people to start building out an approach, or better yet, multiple approaches. This is a thinking heavy exercise.

A well crafted approach might be several pages, it has evidence, and it has context. To do this right you are going to need to:

  1. Research the problem, and identify things that might be causing it
  2. Identify key factors that could change to improve your problem
  3. Think through what levers you might pull to change something, and what might happen when you do

Basically you are replacing your big problem with the couplet of a smaller problem and a hypothesis of how you would approach solving it. A thing you could add, remove, change or optimize. You should include a prediction for the kind of impact this would have.

It's ideal to generate several of these for every motive, and evaluate them.

Sticking with our example motive, the summary of an approach for the abandoned shopping cart might be:

It takes 18 steps to complete checkout on our site, based on our analytics, 50% of the people who don't complete a transaction initiate the first step but by step 6 in our flow, 90% of those have given up. We are going to group steps in the checkout process so the overall process is simpler.

If you were doing this for real, you would want to include in your approach documentation what those 18 steps are, more details about how users fell off and where, identifying hot points and risks. Making this document a sort of "show your work" for a cross functional team of thinkers.

Another possible approach:

Most of our checkout process is the same information for every order, we should build an account system allowing shoppers to save their information and skip the checkout process entirely.


After reviewing analytics, it appears that a large percentage of the users who aren't proceeding to checkout are actively shopping on our site, adding items to their cart, and then remaining idle for several minutes before simply closing out of our site completely. We compared the prices in carts that did not get purchased with the same product on our competitors site and discovered that the equivalent competitor cart would be 10% cheaper than buying it from us. We believe that these customers are using our sites fantastic browsing experience to find the items they want, but then buying them in a cheaper store. We should either lower our prices in highly competitive areas, or invest in a discount program that customizes an offer for customers like this.

What's important to note about an approach is that it isn't bounded by just technology, or discipline. It is bounded by the motive. Do the research and thinking, let many approaches develop at this stage. Allow time for small cross functional teams to work through the problem and the approaches that might have a valuable pay off to emerge. Doing this well might take about a week. It's going to be almost impossible to do it well with just a single part of the organization represented in the creation process, so if you think you can just have product managers write the approach documents and present them to the team you are likely to run into a lot of downstream problems. This is where you bring reality into the problem.

One good way to generate these is to hand the motive to a cross functional team and give them a week or so to come back with several approaches. A healthy team should be able to generate $(n/2)-1$ solid, well thought out approaches in a week of fairly focused work. You can even have multiple teams working against the same motive.

As teams become increasingly skilled at this kind of thinking they may reach a point where they are able to do this research and thinking in-line with progress on other things. There is however something very nice about doing these at natural pause points when people have some time to dig into this kind of thing. It's a luxury to have that time for many teams.

If you can't make that happen, you should aim for a minimum bar of making sure that the people working on building your approach all are able to work on that development together at the same time. Handoffs are always challenging, but none more so than when you try and hand off thinking.

Process Step!

Bring all your great new approaches back to the larger group. Everyone who is participating in the process should read them all. No powerpoint. You aren't selling your approach, other people are benefiting from your thinking to get on the same page.

There are lots of ways to prioritize, pick and move your approaches forward. Some people like to put each one on a card, and let people vote, you can put them up in order and let people move them around over a couple of days or weeks. I've seen teams set up a kind of human bubble sort, where each team member gets to perform a few adjacent swaps. Some teams let people vote with their feet thinking of each approach as a thing a team could advance, and letting people work on whichever one they want. Do something that feels right to you, and the culture you want to have. It is reasonable to exercise some sort of filter on approaches at this stage, some of them might not be viable, talk them through and make sure people understand why they are/aren't viable. Remember that there is usually at least half truth in these things. So if you have an approach that says something like our prices are too high, you may not be able to lower them, but if the evidence is there, don't lose track of the business and market realities associated with that evidence.

However you do it, get teams associated with approaches, but don't go further. The next steps only the teams can do.

Continue in Rally Points

/ Roadmaps

Roadmaps Continued: Motives

Instead of starting with goals, we will start with a motive. A long term why framed as a reason. This motive should be substantial enough that everyone can agree that there is a problem, and a good reason. A motive should avoid a solution, but instead articulate a measurable change and the reason why the team or company needs to make progress on this now.

We lose 50% of customers between adding an item into their shopping cart and checkout. We need to reduce that to lower than 20% because it represents 50% of our potential revenue and turning more potential customers into actual customers will increase sales by $10,000,000.

It's hard to argue with the above. You might have larger problems in your company, so it might not be the highest priority, but once it made it to the top of the list for a team this motive could certainly consume a lot of energy.

Notice a couple of important things:

There is no indication of how or solutioning here, that comes in the next step. It's critical to avoid XY problems in this stage. If you are a team of one, and you are going to personally carry out all these stages for yourself, you can cut yourself some slack here, but most of us work in groups and teams, and it's not uncommon to get problems and goals identified by management and the response to come from a different group.

The motive includes an answer to why we need to fix this problem, and it's specific. It takes the form of Problem — Target — Why — What we get if we solve it. Each of those elements has a measurable thing that we can approach and move toward over time.

A good motive is unlikely to have a single solution, and more importantly, there aren't that many silver bullets in life, you would never look at a solution to this problem, and reject it because it only improved this problem by 20%. Yes that is short of completing the motive, but still that's a lot of progress. Good motives are directional, and identify the point where you might stop and re-priortize, but set up room for incremental progress.

A motive is something that almost any member of the team could sink their teeth into and in fact that's the next part of this framework.

Process Step!

It's perfectly reasonable to take problem statements as far as a motive statement and get them queued up as next, or later. Check before you take them to the next stage to make sure they are still valid.

Remember earlier when I said that your motives should be pretty uncontroversial? This makes them uniquely challenging to debate. Depending on the scale of your company, you might only be able to tackle a single motive at a time. Or maybe you are big and can tackle ten. This will take some practice to figure out. Don't bite off more than you can chew.

Up Next: Defining your Approach

/ tech

Is Google Duplex Inhumane?

Google announced and demoed Duplex this week, and it's really quite something. This is the stuff of science fiction in many ways. The recognition capabilities and dealing with some of the conversational branches is really quite impressive.

People seem to be thinking a lot about the fact that the synthesized voice includes fillers like "umm", which is a part of making the voice sound more natural and human. After listening to all the demo calls published on the Duplex site, I pretty quickly identified a couple of repeated tells that felt awkward. The "em hmm" that followed "hold on one moment" as an example. That's probably tweakable.

What worries me a bit more is the asymmetric time relationship in a transaction at scale. Restaurants today are already feeling a lot of pain around reservations, no shows, reservation selling, and the whole problem of dealing with reservations in the app economy. In NYC it's now normal that you will get a call confirming your reservation almost 100% of the time.

Starting this conversation as the initiator is theoretically as easy as asking Google Assistant to get you a reservation somewhere. Perhaps a five second command saving me from making a phone call, which sound great, but it triggers something on the other end.

While Google may not care a bit about how long that call goes on, it's awfully cavalier with the time of my favorite restaurant, or your hair stylist, and in a very synchronous way; that service worker needs to spend as long as it takes on the phone right now to extract from Duplex what is needed to complete the task.

Making a reservation or an appointment is basically filling out a conditional form. I need a bunch of information from you, check some information I have, and if everything is OK we both confirm and all is good. If people had total information, this could be an almost instant transaction. In today's world it might take a couple of minutes on the phone, but what keeps that reasonable is the implicit human contract that we are both spending the same amount of time to negotiate that form. The types of businesses that have people there to answer the phone don't typically have the resources to do a direct machine-to-machine integration to some Google reservation API, so now they are saddled with a machine calling them looking for the Sarah Conner of reservations.

It's important to remember that as sophisticated and complex as the demos we heard this week are, they left out one of the more unknowable parts of the conversation. The preferences and constraints of the user. My five second command initiation needs to have a lot of information in it. Perhaps your life is different than mine, but sometimes I want to go to dinner at a particular restaurant, and sometimes I want to go to dinner at a particular time, or near a particular place. These constraints don't come up in the demo, and they won't until the place I'm trying to go doesn't have room at my preferred time. Sure they can seat me 45 minutes later, but if I'm trying to get dinner before I see a movie, that might not work. Another night I don't care about time, I just really want to go to Zahav while I'm in Philadelphia or Lilia before June. Duplex is unlikely to know that, and that flexibility is difficult to convey. So will Duplex put the host on hold to ask me if 45 mins later is ok? Or what about another night. Maybe it will call back later? I'm sure we will all enjoy Duplex's ability to remember the last call and remind us of what we said before.

In some ways Duplex seems more suited to the other side of the call, answering people's requests when they call, a place where the patience of a machine is actually an asset and the information is flowing in the right direction. That's really just an improvement on call center automation software though, and we have already decided that we don't like talking to machines on the wrong end of the time value equation (e.g. "Tell me about your problem...") So why would we be willing to subject others to this kind of uncanny valley of communication?

Computers are great at magnifying intent, and it's not a stretch to imagine me asking Google Assistant to find me a reservation for 7pm on Friday that triggers a dozen calls before "You're all set!", it just seems like the cost of that ask could be substantial and invisible, and it will be borne entirely by the person who answers the phone.

Restricting Access on Locked Phones

Doesn't seem to be confirmed yet by Apple, but lots of stories about Apple restricting the Lighting > USB connection on locked phones after 7 days. What this means is that if someone takes your phone, but doesn't have your passcode, after seven days they will no longer be able to connect that phone to a physical device and copy data off the file system.

The file system is all encrypted, but while it sits on device, it's protected by the non-trivial hardware and software protections that Apple has woven throughout their hardware. If you move that data, even encrypted off the device, you still have a math problem to solve, but you can also solve that math problem at your leisure, without worrying about whatever is going on in the Secure Enclave, or any sort of ten tries and the phone deletes itself protocol.

Completely independent of your politics, or opinions on government rights to search phones and devices. This shows just how serious Apple is taking the stewardship of our privacy that we have all given them by moving our entire lives to these pocket computers.

In a past life I worked on game console security a little bit, and the big console manufacturers and silicon guys took this seriously. It was however serious because there was a lot of money attached to keeping the platform secure to protect the content. It had the side effect of preventing the execution of third party code, and that was nice, but it was a side effect.

If Apple moves forward with this, it's one of the first times we have seen a company of this size take a visible, proactive restrictive step to establish privacy and security of your personal data as a feature. There is no other reason to do this, it's not preventing piracy, or enhancing user convenience. If I was a government or law enforcement entity, I'd read this as the most powerful tech company in the world is not messing around.