TL;DR:
- A drop in Velocity means not meeting milestones and deadlines in their time
- Retaining customer satisfaction requires at least a weekly update with something new and small
- Velocity is the right effort done. Time spent on preventable instability/maintenance or valueless goals is a Velocity drop.
- Engineers should practice thinking of value and customers for better decision making
- Preventing valueless executions is preventing a Velocity drop and it is a part of everyone’s job
- Product, management and development should work together to prevent valueless executions.
- Code what is solid enough, postpone the rest as much as you can
- Keep a culture of good questions asked at the right time
The effect Velocity has on Customer Experience/satisfaction is quite the obvious. You must keep your customers, internal (product, management) and external (end users) alike, satisfied through the years. That would require either perfecting/optimizing/tuning current experiences or creation of new ones. That is work to be done. A drop in Velocity means not meeting customer demands in time, better known as milestones and deadlines.
A senior product manager of a large American B2C enterprise, who also happens to be a good friend of mine, told me about an internal research they conducted. In order to just retain customer satisfaction as the research indicates, you’d need to push something new, even a small one, every week or two. In that kind of world Velocity is more important than ever.
Customer satisfaction aside, there are also the money makers, the business flows that eventually pay for your salary. If an engineer would spend time on bringing a server up instead of coding/fixing a money maker, that is actual money lost / not earned due to a Velocity drop.
The sales team at Wiser (2016), for example, had to prove a potential customer’s requirements before closing down a deal with him. From the sales team’s perspective, it was a small PoC. From my development team’s perspective it was a whole new feature. Unfortunately, my team’s Velocity was low. It took us weeks to deliver these newly required features. They were indeed complicated, but that was not the reason we did not deliver in time. As we spent half of our time on system maintenance, we just didn’t get to do that [see the story of the hellish core at Scaling Strategies]. Time wasted on maintenance was directly translated to lost potential deals worth hundreds of thousands a year to the company.
If you’d argue that it doesn’t count as low Velocity because effort on system maintenance counts as work, I would hardly disagree. Velocity is not only effort through time. Velocity is the right effort done. That is true both to instability as to customer experience. Development time, effort and resources spent on something that did not bring any value at all is another form of Velocity drop.
In Hebrew there is a saying “going full gas in neutral”. It won’t help you to push the gas pedal all the way through (effort) if your car’s gear is in neutral shift (no value). If we’d like to take this metaphor further down the road, pun intended, I would say that not only you’d be wasting fuel (effort) you’d actually be going slower due to friction (results of wrong effort). Amos Tversky, a Nobel prize winner in economics who I’ve mentioned in the preface, used to hate metaphors. He used to say they are a bad form of communication as each person understands what he wants and not what you wanted to say. That’s what good concrete examples are for.
Valueless execution
At Silo, our amazing engineering team had a lot of ideas. When it came to system internals, servers/communications/deployments/performance/etc I was the one they came to, as the engineering manager and architect. Just for practice sake, even when the idea was excellent, beneficial and I was all for it, I would still stop and ask “how does it affect Silo’s customers?”. Continuous practice, at the right context, makes sure the engineers’ thought process would include what value is and who is it for.
A good answer could have been “it will ensure a safer deployment thus less unsatisfied customers”. An answer of “faster deployment would lead to more satisfied customers” is a claim that needs to be proven. If you’d want us to thoroughly consider it, bring proof to the table. It may be true for mobile applications, but you still must ask yourself is it also true for a physical device and is it true for Silo’s customers. Google it. Investigate it.
Many times such claims are either proven wrong or marginally beneficial. That is okay, that is a good process. Preventing valueless execution is preventing a Velocity drop. That would be time and effort saved and invested where it should be. Even if you claimed wrong, by proving yourself wrong you’ve done the excellent job expected of you.
Guy, who was in charge of UX related development at Silo, once had an idea that would greatly affect the animations shown, it would make them look more natural. It would be a week’s worth of work. It would require to upgrade a major version of a framework (v2.3 to v3.4), which could cause further troubles as well.
Both me and Guy studied together in the university about UX. I had some practical experience, but Guy just has a knack for it. Although we are somewhat experienced, we are not alone in this. The decision is not ours alone to take. “Are the product team happy with the current experience?” I asked Guy. They were not satisfied. “Are they saying your solution would be of value?”. We kept a no boundaries culture between the dev and product, so Guy already verified it with them. “Great, go for it!”. That was not “us and them” separately, that was both of us unseparated, development and product working together to ensure we are preventing a Velocity drop, working towards goals and not away from them.
A questionable doubtful culture
The product team, who lead customer experience, could also trigger a valueless execution unintentionally, where the expected value is entirely not within the R&D’s domain but a 100% percent within the product’s domain.
One time Silo’s product team finished defining an important user flow and we were ready for execution. “Is it solid enough?” I asked. They did not understand what I meant, but that’s because I always like to add an ethos to dramatic questions. “What are the odds this user flow is going to change?”. My interest was for my team to code this only once, to reduce the odds of throwing away code. Even if it’s currently necessary to code it, it is effort lost that may be prevented. “It will probably change somewhat, as we have mock user tests with a mock device next month”. We did a technical breakdown of what was necessary and executed only the parts that were not expected to change. It was enough to correctly select a database, create the schema, and launch an entire new service. A month later, after the user flow was tested and changed accordingly, we asked ourselves again “is it solid enough?”. The answer was yes as if there were to be changes, it would be only after customer feedback. Then and only then we started the actual coding of the user flow.
Decision making based on customer feedback is not new and something that each company is supposed to do. I cannot emphasize enough how important it is to correctly gather and analyze such required information. Making a decision based on incorrect data, or incorrect conclusions out of it, would also cause valueless execution and a Velocity drop.
A system must provide this as well, or the very least make it easy to do. Not coincidentally, the Event Analysis system I’ve mentioned before, the one that was used for operational/tracing purposes, was designed for product and decision making requirements as well. It helped us to gain product related insights during our PoC. Without being able to see how customers used the product, we knew how they used it. We knew why and how. This had major consequences all the way to the device’s design, capabilities and roadmap, and also affected the company’s business priorities.
Management could also have their hands in and cause valueless executions unintentionally. Again at Silo, the COO who was incharge of manufacturing in China, asked the software team to utilise the container’s embedded RFID tag to help prevent container forgery by other factories. We brought in a consultant as there were known best practices out there exactly on this. Turns out that any solution would require gapless computers, an internet connection in mainland China behind a VPN (which is a hard presumption), encryption, secret management and a whole lot of coding in the device itself, in parts that could not be remotely updateable, meaning more tests in the factory and more physical testing stations to create. It was about three months of hellish work to execute prior to the manufacturing start, meaning to be executed tomorrow.
“Are you sure we need this?”, I’ve asked the COO. It turns out that the answer is yes, eventually maybe. It would take a competitor about two years to forge and sell our containers and he’d probably also forge the device itself. That would mean that no matter which technical solution we’d come with, forging is unpreventable. Once he said that he realised it may not be worth it. The patent and the tier 1 factory we are working with, these should protect us. Not the software.
We did need something minimal anyhow. We reversed the solution’s paradigm and came up with a solution that would require two weeks of work now that will allow us in the future, upon a proven measurable valuable need, to further invest more time. These were two and a half months of precious development time almost executed on an unproven value and false assumptions.
Preventing valueless executions is not easy to do and it is mostly not technical in nature. It is a state of mind, a state of thought and a continuous practice to pass to everyone around you. No matter your position. Do it whether you’re a CTO, a manager or a developer. No matter how senior you are.
Keep a culture of good questions asked at the right time.
Question everything.
Ask questions.
Ask yourself.
Ask everyone.
Make everyone ask everyone.
Keep a culture of beneficial doubts.
Doubts that will progress you.
Not doubts that will paralyze you.
Think twice, it’s alright.