Do "basics" well

High performing teams are about interperson chemistry that is built on a foundation of the “basics”.

Take sports for example.

Learning to play a sport require you to learn the rules and develop basic skills to play. For soccer, it would be passing, tackling, lobbing and shooting.

When you join a team, there’s drills, runs and short set plays. These are repeated over and over during practice. During a full game, these disconnected pieces mix together to form fluid play. Play together with your team for long enough and magic starts to happen — team members anticipate each others moves to outplay opposition.

Drills, runs and set plays allow you to improve and build on the basic skills: passing, tackling, lobbing and shooting. They improve player fitness and execution during gameplay.

The act of continually working on the basics seem to lead to continued advancement. This is an interesting idea as it would be easy to assume the opposite — to advance further, one has to work on increasingly complex drills. I think it comes down to the fact that most complex things are built up from very basic elements. The more confident and efficient we are with basics, the more opportunity we have to put them together to do complex things.

Therefore, I believe, basics and chemistry form important attributes for any team.

Chemistry can be a complex thing to establish, with time, environment and the individuals themselves. It’s a whole other discussion.

It is easy to establish basics when talking about soccer. What are the basics outside the context of sports? I’ve been trying to figure out what forms the basics for a software engineering team. Is it design patterns or code reviews? Is it practicing readiness to production issues? Or perhaps, it is our ability to document and capture tasks in Trello? These seem to be the essential building blocks in a life of an engineer; solving problems by applying technical concepts into code, that outputs a product to deliver value.

Software is more than just code. At the heart of it, it is empathy and collaboration. It is a bunch of people, observing and acknowledging pain felt by themselves or others, deciding to take upon themselves to resolve that pain. Solutions doesn’t just come from one individual. It is the work of many, fusing their minds, disciplines and skills together to make something truly valuable. For me, the basics for a team are contained in these core values.

Basics has to be more around the idea of problem solving. That is all we do as a team, every day. Even our individual disciplines themselves are various ways dimensions of problem solving — research, design, engineering, analysis etc.

This idea became clearer when I recently read the book “The Culture Code” by Daniel Coyle. The book investigates the elements of highly successful groups. There is a great case study around Danny Meyer’s wildly successful restaurants. In a restaurant, how should one go about preparing staff for both conveying the right feel to customers and be able to react to new and complex issues that come up? It is impossible to cover all the bases and situations.

Danny uses the idea of “heuristics”. He captures the behaviours and his ideology in short, catchy phrases that are used in high frequency. Staff learn to apply these heuristics in every day complex situations, leading to very delightful customer experiences. Applying these heuristics seem to be the basics Danny get his staff to focus on.

These “heuristics” aren’t the same as rules. They are shortcuts for understanding and applying “guiding principles”. They convey a behaviour that is core to situations that arise in a restaurant environment. They allow staff to be thoughtful and creative, while being aligned towards providing customers with a unique, delightful experience.

Heuristics based in problem solving… these can be our basics.

Here are some ideas for heuristics I’ve been collecting with the help of others:

  • Just start.
  • Try and try again.
  • Optimise for fast recovery.
  • Act like it is your company.
  • Coaching over management.
  • Challenge assumptions.
  • Understanding the problem is half the solution.
  • Ask why.

“Just start” — we can apply this heuristic over and over in many occasions, whether people are stuck on a decision or unsure of estimates. It embraces the culture of a “maker” in having a bias for action.

Whenever someone asks me why we allowed a bug to go to production, I like to say: “Making mistakes is part of the job. We’d be better off if our system was optimised for fast recovery instead.”

We do workshops to help everyone understand how to write a good problem statement. Because “understanding the problem is half the solution.”

I believe that practicing these basics of problem solving can lead to powerful teams. They can provide the fundamentals that enable magic to take place.

Keep practising. Keep doing basics well.

Making Safari Suggested Passwords Sync with Chrome

With the latest OS X Mavericks, Safari browser introduced a very convenient way of generating safe, random passwords when you sign up for a new account with any website. I've started using this feature extensively. It syncs across my iPhone + iPad beautifully as well. Only problem is Chrome...

Right now, I have a manual solution. Turned out to be a little easier than I thought:

  • If you open up the Keychain app on the Mac, You should see two items of interest: "login" and "iCloud". Chrome picks up passwords from Login.
  • Go to iCloud section, arrange by modified date.
  • Select all the recent signups and do a CMD + C (copy).
  • Navigate to login section and do a CMD + V (paste). It's prompt you for your Mac password, go ahead and enter that.
  • Chrome should now pick up the passwords automatically, sync across to all your Chrome browsers from now on.

Wisdom on Pricing Software

Recently I came across this excellent blog post, "Million Dollar Art", by Nate Otto on the Signal vs Noise blog. I started thinking, how relevant is it for software? Can you simply put a million, or even 30 grand price tag on software?

We first discussed it at work and there was the rational opinion that IT products help save time and effort. If a single person's job can entirely by done by a piece of software, then it should worth that person's salary. This makes valuing software quite easy!

Why think when you can Google. I came across this wonderful article at Smashing Magazine: You're pricing it wrong: software pricing demystified. It talks about the rational price vs. the perceived value of a product. Seems like branding, good marketing, superior design, support, average price for competing products and a number of other factors can increase or decrease the perceived value of a software. Read the whole article and some of the related links to get a better idea. Highly recommended!

When it comes to apps, the perceived value always seems to be much smaller than the app is really worth. 99 cents is very popular on the App Store. However, I think it will be wise not to go with the flow and really think about your audience and what they'll be willing to pay. Better yet, try to bend your ideas to fit to an audience which has more money to spend (Business Store for example...). Most importantly, be flexible. Start with a slightly higher price and be wiling to experiment with the price. You can never know for sure. Don't give away anything for free.

There's one caveat: iTunes rankings! Giving an app away for free might mean that you get more downloads on launch day, provided you run a great marketing campaign. Then, things become real tricky moving forward.

We're about to do some testing with pricing with the launch of tvQ 2.0. Will write my findings post launch.