It was my first week on the job five years ago when I asked “Should I write a test for the feature I built?” — “Do as expected” they said.
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, Do As Expected evolved in our hive mind from a recurring joke to a concept that represented the principles and behaviors we stood for as a team.
A simple question
We quickly figured out that we could use Do As Expected as a tool to grow and hone our culture by nudging each other to meet our peers’ expectations.
The question is: How did we know what 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.
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 what we organically came to expect from our team mates.
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.
There is always room for improvement, both at a personal and at a team level; we strived for perfection but knew it was and endless quest.
We had constructive and open discussions about why things were the way they were and how to improve them. After all, if no one speaks up, few things will change — and improvement comes only from change.
Respect others and their opinions
Open feedback and discussions became natural as the team members felt safe 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.
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 Originals, teams take better decisions when there are diversity of opinions:
“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 analysis paralysis, 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.
This meant we adopted a trial and error 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.
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 start small, which got us unstuck and into action.
Errors are obviously an integral part of trial and error. 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 psychologically safe:
“Shared belief held by members of a team that the team is safe for interpersonal risk-taking.’’
- Amy Edmondson
Code as expected
Do 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.
Minimizing WTFs/minute
We did our best to minimize the WTFs per minute metric. That is, how many WTFs per minute will someone (including your future self) blurt when they read/review your code:
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, “Does my team expect me to minimize the WTFs/minute?” I hope the answer is obvious.
Code Quality
In order to improve our code quality and define what bar we wanted to hold ourselves against, we read Clean Code by Robert C. Martin and later practiced its concepts together, in a series of sessions with the whole team where we learned by doing in mob programming-like setup.
Amongst the concepts Martin talks about, my favorite one is The Boy Scout Rule — Continuous Improvement applied to coding:
“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 why 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.
Ship it!
We also applied the trial and error concept to software delivery. We knew that the faster we shipped our software to the customer, the faster we learned what worked and what didn’t.
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 release early and often, releasing our products or features before we thought were perfect (of course this doesn’t apply to safety-critical software like avionics). Reid Hoffman agrees:
“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 Do AS Expected when building something, the outcome will likely work and be as expected. Applying this property to code:
If you do as expected when writing code, your code will likely be/behave/work as expected
I.e. Build Quality In. or, again, make WTFs rare and your team mates will be forever grateful.
In life
At risk of sounding like a philosophaster, you could go even further and apply Do As Expected to your life outside work. I think of it like a shortcut to Kant’s Categorical Imperative (not to be confused with 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 you would expect everyone else to do.
I will leave it here. Now, what does Do As Expected mean to you and your team?
Thanks to Lorin for being my mentor, my de-facto editor and for his help writing this article.