Ten Commandments of Product Development

At the completion of my six-and-a-half year journey at SmartOrg, I was requested by my SmartOrg family to reflect on the principles that had helped me greatly as Head of Product to build a team and software that I’m proud of. In response, I came up with my ten commandments of product development (and also a fundamental commandment 0 at the end).

Commandment 1: Be a hero for the values that build the space

When it comes to the values that matter to you, ask the question “If not I, then who?” Instead of waiting for someone else to stand up for your values, raise your banner high for what is truly important. In a counter-intuitive fashion, this commandment is critical if you are going to build truly awesome products.

To understand why, here is Christopher Alexander from “A Timeless Way of Building”:

You may wonder, if the rules are so simple to express — what is there that makes a builder great? It takes almost inhuman singleness of purpose to insist on them.

Alexander makes this startling remark after sharing the simple rules that are behind works of aliveness. The rules are so simple that one may wonder why we don’t see aliveness in things we build all the time. “All it takes” is our standing up for the generative rules or principles, and yet that is often too much to ask when we assume that someone else is going to stand up for them. Don’t compromise — if you have found a rule that embodies your values, the best way to let your team and your users know it is important is when you follow it.

One person who is a great inspiration to me on this commandment is my daughter’s kindergarten class teacher, Jessica. In the beginning of the school year, Jessica prepared us all to have our children speak for themselves, and not through us. In theory, that sounds great! However, in practice, it was the most awkward experience in my life when I walk into the classroom and find that the default communication mode is with my daughter and there is no space for me to inject myself in. Even though it was awkward, I realized that this is what I do want for my daughter and am so delighted that her classroom is truly hers. For the first time, I also started to think about what my daughter might be experiencing when we take her to other people’s homes and she gets seen through us instead of by herself. I have deep gratitude for Jessica’s work — and I would never be touched by it if Jessica hadn’t been a hero for this value and implemented it.

In our product development environment, we value slowing down and being intentional as opposed to reactive. Therefore, all our technical meetings begin with 10 minutes of meditation. When we first started doing this (thanks to prodding by our intern Krishnan Srinivasan and inspiration from Birju Pandya), I wondered how it would be received by the rest of the office. To my surprise, the first time we did this, our CEO and CFO asked if they could join when they saw us meditating. As we kept doing it week after week, other colleagues would ensure that voices were down to a whisper and no one disturbed us. If someone was having a bad day, they would even join in. This has become an integral practice in our technical team now out of respect for ourselves and our colleagues and I have benefited so much from it.

A lot happens in our fast-paced environment in a week or two. We value supporting each other in doing outstanding work, and this cannot happen if we don’t know what emotions we are bringing in. So, our weekly meetings start with meditation and are quickly followed by an emotional checkin — mad, sad, glad or afraid (from Software for your Head). This allows each of us to do a courtesy to the team and reveal what’s truly under the surface so that we don’t sabotage our work with our hidden emotions. We also value being a learning culture. That means little unless we actually learn. Our weekly meetings start with a light version of a retrospective — we make two columns: What worked well?, and What needs improvement? We go around and take ownership of improvements that need to be made. This works surprisingly well and allows us to enter into retrospectives once a year where just under 4 hours leads to incredible insights for the road ahead.

These values help us build a very special space for work — those outside our company feel it when they enter our space, and I hear things like “these guys get things done,” or “they do a lot more innovation with far fewer resources.” While outcomes are what people see looking from the outside, from the inside, our work really is with the values. My biggest surprise — how much support these values received from everyone. All we had to do was take the first step.

Commandment 2: Don’t be a hero when you are stuck

There is a saying I like a lot, “If you want to go fast, go alone. If you want to go far, go together.”

I have rarely found that asking for help gets us in trouble. On the contrary, some of the biggest challenges have come up only when people didn’t think to ask for help when it was quite clear that they were stuck and needed support. This commandment is particularly important in two contexts. First, when you have talented engineers who have a lot of confidence. They are dealing with a crisis of self-image in order to “give up” and ask for help. As a leader, feeling the pulse of the team and knowing who really needs to be supported is critical. Most of the time, people don’t share that they are stuck out of fear of punishment. It is a ding on leaders if the space is not safe for people to support each other, and I find that a leader’s work is really to build safety in the space.

The second context is when we work with senior consultants and think, “why am I paying this senior person if I have to now get help for this consultant?” I have found it very powerful to instead ask, “Is this senior consultant feeling safe to ask how I can support him/her?” Sometimes, that involves reaching out to the regular staff. Sometimes, that involves finding specialists who can get us unstuck in difficult situations. Not everyone is able to be a “full-time employee,” and yet, every human being needs to be supported when they are working on challenging problems. Everyone needs safety where they are not being judged, but being amplified and allowed to grow. Discrimination between contractors and full-time employees does not make sense if one’s goal is breakthrough innovation.

I used a one-day rule with my team. If you can’t figure out something even after spending 8 hours, you have spent too much time on it. Have a learning conversation with the communities that are there to support you.

Commandment 3: Be a ladder, not a leader

The dictum that inspires me is “All who come in touch with you should be able to climb up in their career.” We work with people at various stages of their life. Everyone wants to do work that they are proud of. How can we create the context so that people around us are able to do the best work of their lives? How can we help them climb up through whatever we have to offer? The laddership movement speaks a lot more to me than alpha-male leadership.

A special moment for me was when we were working with a super-talented engineer in France, Valentin Hervieu. He would crack very tough programming problems and had an aptitude for learning that was very special. He was a consultant for us, and he had been compensated for his work. When we filed for a design patent based on some of his work, we were not legally obliged to include him on the patent. In fact, lawyers often like to keep it clean and have contractors sign away IP rights as a prerequisite for doing work. However, he was a young engineer and every young person can do with a little help in their career. I included his name on the patent. It confused him at first but when he understood the gesture, he just opened up in a different way. I would send him tough problems and he never negotiated hours with me. On the contrary, I had to run after him and remember conversations like, “Hey you are doing all this work and not sending invoices — what’s going on?” He would invoice us for less than what he actually did, and would only invoice if he cracked the problem.

What is the value of that generosity and gratitude that had sparked in this engineer’s heart? I can’t put a pricetag on it. A broader principle is behind this commandment. It was the lifework of Mahatma Gandhi and the movement he left behind, called Sarvodaya. Sarvodaya is a conjunction of two Sanskrit words — Sarva (all)+ Udaya (rise). Gandhi’s model for growth was an inclusive one — where all rise together. If anyone falls, we all fall.

I know this goes counter to management adages around getting rid of B performers and keeping only the A’s. However, every time a team member has had a hiccup, what has actually worked is a total commitment to helping that person rise again. We are not ossified B’s or A’s — when we sense a strong commitment from everyone toward our own welfare along with being held accountable, we feel respected and counted — we then become coachable. That is the beginning of a meaningful journey toward our own growth.

Commandment 4: Be a philosopher first; a programmer/designer second

Ask “What does this mean about who I am?” before you write code or design a feature. Every feature, every line of code, every variable name is an expression of your caring — for yourself and for others. Who do you want to be in relation to what you write or design?

This is a hard one to follow, especially in anything that feels mundane. My big inspiration came from an unlikely source. I lived in Japan for two and a half years, and three months in that period were spent with a Japanese colleague as his roommate. This was unusual — he was going through a divorce and could not afford his rent. So I moved in to help him through that rough period. We would take turns doing dishes. I noticed one day that after I had done the dishes, he would redo them! I was offended and asked him why he was doing it. He looked at me and said the dishes I cleaned were still dirty. He showed me a dish and pointed out a few tiny specks that I had genuinely missed seeing. He then said, “Let me show you how to clean dishes. You have to bring in Zen. Feel the music when the squeezed liquid soap leaves the bottle and makes contact with your dish. Appreciate the pattern of the soap on the dish.” He took a few deep breaths. Then, he proceeded to make giant froth out of it and said, “Enjoy the froth in its fullness.” Finally, he proceeded to wash the froth and the soap off the plate, and gave another lesson, “As you are washing it off, it is not specks of food, but specks on your soul. See a reflection of your soul on the plate.” I never looked at dishwashing the same way again!

In the act of coding even a simple function, can we see beauty? Can we see meaning? One early exercise that I have often used to onboard programmers is to read Unpopular Essays by the great mathematician and philosopher, Bertrand Russell, and then summarize the core essence. This is very hard even for native English speakers, and I had non-native programmers on my team. The exercises opened something up in the minds of the programmers — something that allowed the structure of logic to be examined and felt for beauty. I was looking for comprehension, not debate. Our programmers had to show that they had grasped what Russell had to offer, and then formulate their own thoughts on the topic. They would lead lunch-n-learns where they would explain the essay to our team and I have fond memories of that.

Without having a philosopher’s mind, rules like “once and only once” become a draconian ideology that will stifle the heart. With the philosopher’s mind, rules like that become tools of inquiry that allow beauty to emerge and be felt.

Commandment 5: Your job is to work yourself out of a job

Attachment to one’s role causes stagnation and takes the space away for others’ growth. A guiding dictum for me has been, “How can you help those around you become a better version of you?” When someone wants to learn what I’m doing, it is in my interest to make them better than I could ever be. When that day comes, I become free. I don’t have to bear the entire responsibility and I can hand it to someone else so that I can learn something new.

Instead of getting insecure, I have found my own growth made possible because of others who took my job away. My biggest message to them is to continue developing those they are mentoring so that someday their job too may be taken away and they may become free to learn something new again. This commandment helped me not to think twice about handing the juiciest problems to others. I was able to focus more on product management and less on day-to-day programming precisely because of this commandment.

An extension of this commandment is what my friend Sumanth Jagannathan at Apple once shared with me that I have never forgotten. He shared his management philosophy where, as a manager, he would give the best work to others and do that which no one else wanted to do. In product management, there are things that need to be done which no one else is prepared or able to do — the only way to carve time out for those tasks is to let your team do the other tasks on your plate.

Commandment 6: Care more about user experience than your users think is humanly possible

Ask, “What would fill your heart with gratitude if you were a user of the system?” While everyone acknowledges that user experience is important, how far are you willing to go for it?

There was a particular customer who was facing a pain point on having analytic calculations in a large R&D portfolio take too long. As this customer was the only one facing the problem, we could have justified not dealing with it. We not only built a special feature to allow for quick recalculations, we also went above and beyond the problem — our feature even identified problematic situations and auto-healed the portfolio when the need arose. Our customer was so amazed by our responsiveness and solution that this account has grown continuously every year and more than the revenue received, we earned trust that is uncountable and truly counts.

Another time, we realized that our users found our software confusing because of an inconsistent visual language. We hired Jean Yao, a super-talented artist from Belgium, to work with us one summer. We didn’t get afraid of creative conflict and leaned into it. Her work with us resulted in two design patents and a visual language that does something magical — users automatically learn their way around and make the right guesses for where things will be.

In my school years at Stanford, I was fortunate to learn ethnographic research from teachers like Jennifer Wolf and Stephen Barley. This is an essential tool in a product team’s toolkit and we have taken the time to hire interns to do ethnographic interviews with our users. Every single time, the results allowed us to identify our blind spots, accept them and work with them to transform ourselves and how we listen. The beauty of ethnographic methods is that it isn’t about asking people about what they do, it also involves seeing what they actually do. While a traditional ethnography where we can go to our customer’s spaces and live there for a while is expensive and hard to do, we used ethnographic principles in an agile manner and invited our customers to a community of practice meeting we host every year in our office. On one of these, we noticed that while our customers asked for specific features, what they actually struggled with was understanding what the analytics in our system meant. It was even harder to explain these analytics to others. That insight led to the development of features that made our analytics transparent and accessible, and led to breakthroughs in communication in our user community.

I have never regretted hiring interns from schools that teach ethnographic skills. We have deeply valued both UC Berkeley’s School of Information (thank you Puneet Sharma) and Stanford’s D-School (thank you Vishesh Gupta). Puneet did an ethnography internship with us and turned the tables on us when he included interviews with us in his dataset. He discovered that we were not doing enough for our power users and that led to a foundational shift in our architecture to deliver outstanding power user experiences. His ethnographic work with us even led to a comic book that we use in sales!

Vishesh used his ethnographic analysis background to identify where our users were getting stuck. He then formulated five design questions that became central to our product management thinking. For context, SmartOrg’s product engages with analytics that drive great decision conversations about an organization’s innovation portfolio. The questions Vishesh came up with were:

1. Meaning: What am I seeing? How did it come about? Why does it matter
2. Tracking: What changed and why?
3. Auditing: Is there anything crazy going on? Where and why?
4. Testing: What happens if I change “x”?
5. Learning: How do I explain what I’ve learned to someone else? How can I learn this?

Users of SmartOrg’s software will recognize how our innovation has been driven by these questions. What really moves me about this is that with such a commitment to our users, we are able to recognize their pain even before they become aware of it.

Commandment 7: Get customers through the last mile

You win only if your customer wins. Reflect on the question, “What needs to be done to get our customer through the last mile?”

This commandment helps us take much more responsibility than we might otherwise have. It helps us commit to the success of our customer, and think a few steps ahead, instead of devolving into “that wasn’t our remit.” You will be surprised at the opportunities you see when you make it your remit to get customers through the last mile.

This means not just taking the request of our customer but also digging deeper into why our customer is making such a request. What is the customer’s remit? Are there requests of us that were missed that might make a big difference? We were recently engaging with a customer’s IT team that needed to interface with our platform. They kept asking for our SDK documentation which was in Javascript, and we noticed that their team was mostly proficient in C# and not Javascript. They were going to try and connect directly our REST API using C# and their questions were around that. We went to the next level and built them a C# SDK for our platform so that they could use the language that was native for them and get to the finish line without any sweat.

Opportunities to be of service can sometimes be very humble and small. We had a customer workshop in our office where we were going to set the customer team up on our software. I found out in the morning that one of the customer team members had to step out for a meeting in a different city near ours. Immediately my brain clicked in to this commandment. If this person left unguided, he’d get stuck in traffic and lose several hours, and that would give him less time with us apart from exhausting him for the next day. I worked out a ride on our local train system, gave him my pass so that he could go in and out quickly, and dropped him to the station. When I picked him up a few hours later, he was very happy and so was I that it had all worked out smoothly. I was able to catch him up the next morning, and I felt he absorbed more because of gratitude for the assistance he received. Every interaction with a customer is an opportunity for us to shine our spirit of service, not because of any reward, but because it is the greatest privilege in the world to be able to do something for someone.

Commandment 8: Be grateful for the community that makes you successful

We usually remember who to blame when something goes wrong, while ignoring the people who helped us be successful. One lesson I remember from Diana Larsen is “The community is ALWAYS larger than we think.” Give thanks. Often. Don’t take people for granted.

I love the Dalai Lama’s quote, “If you think you are too small to make a difference, try sleeping with a mosquito.” You do not want anyone to harbor ill feelings toward you because you took them for granted. That makes work that much harder and difficult, apart from taking joy out. This one is an important one for me as it is easy to miss this because of the pace of our work. It takes time to slow down and see the opportunities for gratitude. That is time out of what I have now come to consider “false progress.”

I try to learn the name of the person who opens our workshop’s door at 7:30 AM so that we can start our customer workshop on time. When someone goes out of their way to give us great service, I try not to rush to the next thing I can do and take the time to give thanks.

The team that you work with day in and day out are critical to your life and there are so many ways of giving thanks. One way I find meaningful is during our weekly light retrospectives (mentioned in Commandment 1) when we discover someone is going on vacation. In the dominant paradigm, it can be tempting to make people feel guilty for taking time off during a busy period and to immediately start asking if they have set everything up for business continuity. We counter the prevailing winds by pausing our meeting and clapping for that individual with big smiles on our faces. It is our way of giving thanks for who they are and what they mean to us. Their joy at being able to go without guilt allows them to come back and hold the same space for their colleagues.

There is also a broader world community to which we have a responsibility, for we are situated in that context no matter what we do. Can our best gifts serve them in some way? That question is always on our mind, and it has resulted in knowledge being freely shared on SmartOrg’s site so people who cannot pay us can still benefit from our gifts. We will have more to say on this in Commandment 10.

Commandment 9: Respect your tools; they serve you when you serve them

I find it important to reflect on this adage, “The warrior’s horse, the archer’s bow, the chef’s knife, and your tool. Are you respecting your tools enough?”

Sometimes, when you want to make something of a quality that has not been imagined before, you have to invent the tools needed to do this. Because of the agile software development lineage I come from (thanks to my teacher, Joshua Kerievsky), testing tools have been a big deal for me. Often times, our team has slowed down to invent upgraded testing tools that allow us to compare complex JSON objects better than anything else that’s out there (e.g. Smart Jasmine Matcher). When we attend to our tools so that they are reliable and truly help us do our job well, we gain a new degree of respect in our work and ourselves.

These small investments also create a culture. People know that shortcuts will be noticed and called out. In fact, the team is accountable for holding everyone accountable for quality, including their leader. I routinely see our senior programmers take time out to sharpen their tools before rushing in to build the next feature. The real turning point for me was when they started to do this without seeking permission. We even expect our consultants to take that time to produce work of outstanding quality.

One thing I have stood for is full transparency about the quality of our software. I had learned this principle from my friend and teacher Joshua Kerievsky, and heard about the orb that Rob Mee and his colleagues had built in the good old days of Extreme Programming that would glow red when tests failed. We are always chasing tough deadlines to deliver functionality, and yet, it was really important to me that our team slow down and design a gadget that got named “Sentinella,” which would keep track of our latest system health based on the results of close to a thousand tests (running on the cloud in Travis CI). A single failure would trigger the device to emit a disgusting sound every 10 minutes, signaling to everyone that something had really gone wrong. Our chief architect, Grant Steinfeld, did the gorgeous woodwork of Sentinella and wired up the electronics.

Sentinella, built using a Raspberry PI and inspired woodwork

Our programmers wired it up to Travis CI and wrote a simple AngularJS app to display the failure and emit the sound. Over the years, the gadget would sometimes stop working as we were focused on shipping our product — we have always made time to get it back up and running — because it signals to us and our community that testing and transparency is important. Quality is important. And sometimes, the tools to ensure the quality that we want have to be built with our own hands.

Sometimes, the tools that we need will emerge as a result of breakthrough innovation, and we need to be able to recognize it. There was a point in our development history when we found our front-end logic was breaking a lot. This was particularly hard to deal with as writing tests for front-ends is not trivial. A decade back, this was the reason behind the dictum to put all logic in the back-end. However, with JS making a huge difference in user experience, and our front-end being based on AngularJS, there was no escaping front-end user interaction logic. I didn’t like the fact that we didn’t have the right tools to do testing, and outsourcing testing to human testers didn’t seem sustainable or feasible either. Every year, we would survey the market for tools and everything seemed too complicated requiring major investments. Until, earlier last year, we came across Testim which uses machine learning to know what changes in the front-end constitute a real test failure versus a cosmetic change that can be ignored. It became a game changer in our testing toolkit and is now an integral part of our release cycle.

Commandment 10: Don’t be afraid to feel your values and share it with the world

I have found that people ultimately buy into your values (much more than your product). Live them well and tell that story to your customer. They do care.

At our community of practice meetings, I started to share our engineering process and the values behind it. Customers felt the joy that we felt in bringing them our product. This feeling builds trust and rapport and sometimes has even brought us more business. Once, after one such sharing, a customer felt that we had evolved our product in such an awesome manner since they had first signed on that they needed a software-focused workshop to catch up with its present capability. That resulted in us not only teaching the workshop but also creating a course for others.

The inspiration to bring our values to life comes from life itself. I was once at Miami airport for my global entry card interview. The government officer interviewing me said, “For the next five minutes, I can ask you any question I want. And you have to answer it.” I smiled and nodded. He told me to describe what we did at SmartOrg. I told him how we aligned finance with innovation and how our software delivered on R&D portfolio management using Decision Analysis. He was silent for a few moments and then said, “So you basically help the big guys.” I was stunned to hear that and tried to dance around it, “Well, we have a blog that also spreads knowledge,” but in my heart, I knew he was right. I came back committed to give some of our best gifts away, and that resulted in a free course on Decision Quality. Thanks to our super-talented Decision Analysis intern Alejandro Martinez, we followed up with a second course on building parametric financial models. I had no idea then how these courses would fit into our ecosystem of offerings. Then, we discovered that we work with lots of folks in a company who are far removed from our target users who are engaged with R&D innovation. These folks could be the IT team supporting the R&D team, and there is no easy way to help them get into our world. The courses we have built allow IT teams to support their own R&D teams and us, and help build a culture that understands the work that we do. This also connects with Commandment 5, and is the customer-facing version of working ourselves out of a job by making our customers self-reliant.

This also allows us to change our sales conversation to point out that we have free courses that are designed to break reliance on our consulting services so that customers can become independent. Holding the value of a customer’s self-reliance and delivering on it through such offerings touches our customers. They see SmartOrg’s offerings as visionary and worthy of their patronage. It goes beyond the specific details of the software we build and into who we are being.

These courses also allow us to serve the world community (picking up from Commandment 8) that wishes to educate itself on how to make great decisions every time (which is also the motto of SmartOrg). I cannot describe the joy that I feel in broadly sharing the Decision Quality course with people from all walks of life; giving away our finest story on making great decisions without any strings attached is so meaningful to us.

Commandment 0: Commit to “being” before you even know how to “do”

Here’s a bonus commandment. I didn’t call it Commandment 11 because this one is the most fundamental of all of them. I found this W. H. Murray quote in Mark Nepo’s The Book of Awakening, “The moment one definitely commits oneself, then Providence moves too. All sorts of things occur to help one that would never otherwise have occurred. A whole stream of events issues from the decision which no one could have dreamed would have come their way.”

Nepo writes, “We’d all like a guarantee before making a decision or taking a risk, but the irony is that taking the risk is what opens us to our fate. It’s like wanting to know what things will taste like before putting them in your mouth. It just can’t be figured out that way.

“I always seem to be relearning that real commitment comes before I know where anything is going. That’s what listening to your heart is all about. Without jumping off its perch, the bird would never fly. Without jumping out of your heart’s silence, love is never possible. Without asking to be whole, the divine essence waits inside everything the way bread hardens if never bitten into.”

I find this to be fundamental to any work that I do. It is important to draw an important distinction here between being and doing. In the world of being, we commit first and possibility and knowledge emerge as a result of that commitment. In the world of doing, we need to understand the whole truth of the situation, and only when we have thoughtfully engaged with possibility and feasibility can we make a high-quality commitment. We have to know not to confuse the two or else disaster will result.

For instance, a year back, our chief architect Grant Steinfeld had taken us to a conference workshop on ReactiveX being taught by Jafar Husain at Netflix. I had learned to trust Grant’s deeper intuition and signed up without any clue about why this was important. By the time Jafar was done with that excellent course, I knew we had to get into this new paradigm. This was a massive leap forward and it was the future. It would tackle an embarrassing user experience problem in our platform where massive reports, when canceled, would not truly be terminated in the browser. Netflix had to solve this problem in their own system — when you have requested a movie to play, and before it completes loading, you have changed your mind and clicked on another one, they have to ensure that two movies don’t load at once and crash your browser. This was going to be the way we would solve our problem. I committed my being to it. However, it would have been foolish to commit my doing without understanding feasibility as we had an existing infrastructure with AngularJS in which this had to fit in. It took us a while and several false starts to finally find someone who could help us out. It was a year when many releases were happening, deadline pressure was on, and yet, because I had committed my being to this, I kept finding small breaks when our team could do R&D. Our French consultant Valentin(from a previous commandment story) helped our team finally crack it, and our next release will ship with this solution. It is a very small feature, but I can tell you that when we finally saw the breakthrough, we all felt a huge sense of accomplishment.

When I committed to implementing this, it was a “no-matter-what” commitment at the level of being, which meant I was never going to give up. However, if I committed the entire business to implementing this, that would be an unpardonable management error and take us out of business. I had to be real about our capabilities so that we could all evolve and take the help we really needed to upgrade ourselves. That would take time and patience. Commitment to being is what creates time and patience, without which no challenge can be surmounted.

Commitment to being requires taking time out from our busy lives and introspecting. Some people do this with meditation retreats. Others take time out to commune with nature. I have greatly benefited from Amba Gale’s leadership retreats — every single one of them has deepened my connection to myself. I remember fondly the monk who laughed when I told him that I was going to learn management at Stanford. He remarked with a grin, “the one who cannot manage himself is going to learn to manage others.” Amba’s retreats put the entire spotlight into one’s own self, and from there, great insight and power emerge. Where the distinction between being and doing become clear, as does the need for integration. A big reason for SmartOrg’s incredible culture is the support every individual in the company gets to attend these retreats.

Moreover, we also take a week in the year to pause the doing and enter into a retreat to focus on who we have been being, and who we want to be. These retreats are an opportunity to invite wise teachers as facilitators to help us grow. Over the years, we have had incredible teachers touch our lives — like Prasad Kaipa, Jeannie Kahwajy and Rich Duncombe. Working with great teachers is part of commandment 0.

I want to thank my super awesome SmartOrg family — Suhui, Grant, Fan, Thilak, Yang, Peter, Deepa, Stuart, David, Melinda, Jim (and Don)! I will miss you all so much! A big thank you to all my teachers, named and unnamed.

I hope you enjoyed reading my list of commandments. What are your reflections? What are your commandments?