Just Do As Expected

It was my first week on the job five years ago when I asked “Should I write a test for the feature I built?” — “ ” they said. Do as expected Little did I know back then that “Do as expected” would become a tool to evaluate and improve the team’s performance, write better code and even become a better person. I was told it all started with a support request. A multi-national team in Asia was working around the clock struggling to integrate a poorly documented third party service. Countless hours were thrown at the problem but they couldn’t complete a successful transaction. Finally a response to the support ticket came in. A response with only one sentence: “Please do as expected.” The one native developer in the office immediately said “oh!” and fixed the problem. The team was confused — how did Daniel translate “Do As Expected” into a working solution? It turned out that it made him take a step back and review whether any of the parameters that had appeared to be optional were actually required and just not documented as such. After a short time, he figured it out and the problem was solved. Over the coming months and years, evolved in our hive mind from a recurring joke to a concept that represented the principles and behaviors we stood for as a team. Do As Expected A simple question We quickly figured out that we could use as a tool to grow and hone our culture by each other to meet our peers’ expectations. Do As Expected nudging The question is: How did we know was expected? Our team had a strong culture by the time I joined, so the answer was easy. In younger teams you might want to openly discuss what seed you want to plant for your culture. what We started asking ourselves a beautifully simple question: “ ” What does my team expect me to do? Does my team expect me to improve this outdated documentation? Does my team expect me to speak up when I disagree on something? Does my team expect me to prank my team mate when she leaves her computer unlocked? What follows is my account of we organically came to expect from our team mates. what Everyone is responsible As : Jez Humble says In high performing organizations, nothing is “somebody else’s problem.” This for us meant having a selfless and helping mindset towards each other: everyone would help fix whatever was broken, no matter who broke it — it was everyone’s problem. It also meant that we owned our shit as a team and expected everyone else to own theirs. When other teams failed to deliver what we needed, we would build the solution ourselves rather than be blocked and entertain long email threads playing the blame game. Continuous Improvement Without realizing it at first we found ourselves in a positive feedback loop where everyone tried to improve. As we continuously tried to exceed the team’s expectations for ourselves, that made improvement happen. , both at a personal and at a team level; we strived for perfection but knew it was and endless quest. There is always room for improvement We had constructive and open discussions about and how to improve them. After all, if no one speaks up, few things will change — and improvement comes only from change. things were the way they were why Respect others and their opinions Open feedback and discussions became natural as the team members voicing their disagreements and opinions openly. We knew there was nothing to fear: as long as we were respectful with others, we would be listened to and respected back. felt safe We expected everyone to be open to feedback and to divergent opinions, and not to take it personally: we had . strong opinions, weakly held We didn’t know at the time but it turns out that, according to Adam Grant’s , teams take better decisions when there are diversity of opinions: Originals “Recognize that dissenting opinions are useful even when they’re wrong, and go out of your way to reward them. Promote and celebrate the people who openly disagree with you and criticize you.” - Adam Grant, Why you shouldn’t hire for cultural fit Bias towards action There were times when we got stuck in , or we tried to please everyone when trying to decide on something. We learned that, in that situation, information is more valuable than opinions or hypothesis. As action is the only path to actual information, it flows that we had to take action to move forward. analysis paralysis This meant we adopted a approach when we couldn’t agree on a decision or when we were not sure what path to take. Once we tested a Proof Of Concept (POC) for each proposal we expected everyone to trust the data and agree on whichever proposal produced the best results. trial and error Nassim N. Taleb calls this notion of beneficial trial and error : Antifragile tinkering “For you don’t have to be right that often. All you need is the wisdom to not do unintelligent things to hurt yourself (some acts of omission) and recognize favorable outcomes when they occur. (The key is that your assessment doesn’t need to be made beforehand, only after the outcome.)” - Nassim Nicholas Taleb. “Antifragile: Things That Gain From Disorder.” Building POCs also forced us to , which got us unstuck and . start small into action Errors are obviously an integral part of This approach worked for us because we were not afraid of making mistakes — everyone saw errors as a way to learn and improve. In other words, we felt : trial and error. psychologically safe “Shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’ - Amy Edmondson Code as expected can also be applied to Software Development. As a developers, we used it (and still do) to remind ourselves to follow certain good practices. Do As Expected Minimizing WTFs/minute We did our best to minimize the per minute metric. That is, how many WTFs per minute will someone (including your future self) blurt when they read/review your code: WTFs This is also known as : The Principle Of Least Surprise “You should reduce the amount of surprises future-maintainers (which is future-you) will face.” - Stephen Haberman or . The Principle Of Least Astonishment So, “ ” I hope the answer is obvious. Does my team expect me to minimize the WTFs/minute? Code Quality In order to improve our code quality and define what bar we wanted to hold ourselves against, we read and later practiced its concepts together, in a series of sessions with the whole team where we learned by doing in -like setup. Clean Code by Robert C. Martin mob programming Amongst the concepts Martin talks about, my favorite one is — Continuous Improvement applied to coding: The Boy Scout Rule “Always check a module in cleaner than when you checked it out.” No matter who the original author was, what if we always made some effort, no matter how small, to improve the module. - Robert C. Martin Our most important tool to keep the quality bar were Code Reviews. We were honest and straightforward in our Code Reviews — no matter the seniority of the developer — and this sparked the necessary discussions about things were done that way and lead us to find cleaner and better ways to write the same feature before the code even hit Master. why Ship it! We also applied the . We knew that the faster we shipped our software to the customer, the faster we learned what worked and what didn’t. trial and error concept to software delivery We had a good Continuous Integration & Delivery pipeline and monitoring, so we could afford to be biased towards shipping, feeling confident that if something went wrong we could quickly and safely roll back the release. At a higher level, we also tried to , releasing our products or features we thought were perfect (of course this doesn’t apply to like avionics). Reid Hoffman agrees: release early and often before safety-critical software “I believe that if you’re not embarrassed by your first product release, you’ve released it too late. Imperfect is perfect.” - Reid Hoffman, Imperfect is Perfect Transitive property I just made this up, but as a rule of thumb I would say that if you when building something, the outcome will likely work and be . Applying this property to code: Do AS Expected as expected be/behave/work If you do as expected when writing code, your code will likely as expected I.e. . or, again, make WTFs rare and your team mates will be forever grateful. Build Quality In In life At risk of sounding like a , you could go even further and apply to your life outside work. I think of it like a shortcut to (not to be confused with ) philosophaster Do As Expected Kant’s Categorical Imperative the Golden Rule Act only according to that maxim whereby you can at the same time will that it should become a universal law. - Immanuel Kant, Grounding for the Metaphysics of Morals Or Do as expect you would everyone else to do. I will leave it here. Now, what does mean to you and your team? Do As Expected Thanks to Lorin for being my mentor, my de-facto editor and for his help writing this article.