Execution Discipline

I have often been asked to help start-up founders look for technical talent because of my deep involvement in various open source software community work and because of various pro-bono community service I have done over the years.

As a software consultant building apps for customers and ex-freezer product lead for a local scientific instruments company over a career spanning 8+, 9 years, I have also acquired a deep understanding of product development cycles and the human dynamics between business and technology teams.  In a front row seat (as an employee and as a software consultant), I have observed first hand how successful product and business owners build their company and how unsuccessful ones behave.  Skills and luck (“market timing” for example) are factors that contribute to the success stories; and conversely, are also factors that can lead to a company’s downfall.

But above all else, the successful business/product owners I know are always those that have execution discipline.

What do I mean by Execution Discipline?

Execution discipline is about following clear methodologies when making product hypothesis, business or technology decisions and allocating resources. It is also about systematically evolving the methodology in a clear and deliberate manner as new facts and information becomes available.  In other words, one can start out with a completely wrong methodology, or a product hypothesis that has no demand for a given situation, but has the self-awareness and the temperament to evolve towards a more appropriate methodology or hypothesis.

Or to put it in Jack Sparrow’s words…

The problem is not the problem.  The problem is your attitude about the problem.


One of my most successful clients started out his online business ventures by working with a range of software developers.  When he first got into the online software business, he was completely unaware of all the intricacies involving online marketing, software development and the differences between all the freelance developers out in the market.  For more than a year, he hired various developers to build out various online apps he has in mind.  Every single one failed – because of a bad hire or simply because the idea he had has no legs – no one needed what he built.

With each failure, he learnt something new and evolved his approach.  Through this process of systematic trial and error, a product he built became immensely popular and profitable.

In the scientific instruments company I worked for before I started my own gig, my bosses exhibited the same kind of discipline.  They are relentless and systematic in their pursuit for perfection – whether it’s sales and marketing implementation or manufacturing (existing products) or new product development.  That is a discipline that sees a – at that time in 2006 – year-by-year company revenue of USD$11 million.  Yes, it’s not a Google-scale success.  But it certainly is a successful, profitable and self-sustaining business that is continuing to evolve and grow.

On the other hand, some of the worst kind of customers I had when I was consulting and writing software as a service, are business owners that change their mind in completely random whims.  Make no mistake, many of these customers are very brilliant people and are extremely well connected too.  They possess individual skills (marketing, sales or otherwise) that would easily match any of the successful examples I mentioned above.  It is almost as-if their brilliance is their curse – always distracted, always quick to change their minds before a hypothesis is tested and always having “the next new idea”.

So if you are to ask me what’s the one single attribute that I respect in a business owner or a product owner, I will say “Execution Discipline” – with no hesitation.

So why is this important?

Besides the obvious fact that execution discipline gives a start-up a better chance of finding product-market fit and thus achieve the elusive “start-up success”, technical talent likes working with business owners and leaders that behave in a predictable fashion.  Even when dealing with the inevitable uncertainties of a start-up company, a disciplined leader that is able to steer the ship and change directions in a calm, deliberate manner commands the respect of his/her team.

First time entrepreneurs often revel in the fact that they are completely free to move fast and change directions rapidly – and yes, indeed, the ability to change direction rapidly is one of the reasons why a start-up can do what a large, monolithic, established company cannot.  However, the mistake these first time entrepreneurs often make is to change directions randomly.  Don’t make the mistake of thinking that making changes rapidly is progress.  Change because data and facts emerge to signal a need for a change; and not because the entrepreneur has a “eureka” moment.

So start-up founders looking to hire technical talent: my advice is simple – be clear and systematic about the problem you want to solve and the customers you want to serve.  Everything else follows and evolves from there.

Does a start-up founder need to code? That is a story and a controversial debate for another time and not the focus of this post.

The observation I am sharing with you here in this post is simple: luck, market timing and skills aside, the most important attribute that technical people value in their leader is the leader’s ability to steer the ship in a calm, systematic manner – storm, kraken, or whirlpool.

Just like Jack Sparrow.

Working in a distributed team? Reduce email, use async tools

At Hackers & Painters last Friday, Jon Yongfook Cockle shared with a full-house crowd how he managed to build his online business while traveling around Asia.

As an independent technopreneur who manages his own Lean customer discovery cycle, designs his own interface, writes his own code and supports his customers online, Yongfook is able to live a balanced digital nomad lifestyle beautifully. Over a period of one year (since July 2013), he has built a web application with a strong value proposition that serves his target customers; and has created a sustainable online business with a recurring revenue that allows him to travel indefinitely.

What about teams?

His presentation led me to ask myself a few more questions in the context of a bigger team.

  1. If you are working in the context of a team to run a slightly larger business, can the team also function effectively as digital nomads?
  2. What are the skills and tools we need so we can collaborate effectively in the context of a team?
  3. What if you have a hardware component to your product and you are not building a 100% software product?

Before I began my journey to build an Optometry solution/product in AlgoAccess, I was working in a semi-distributed team as a tech consultant – with some colleagues working in Europe and some working locally in Singapore.  In that context, I set up and manage tools such as Redmine, Gitlab, Emails (obviously), Skype and use online invoicing tools like Freshbooks to keep the whole team in-sync.

My current team in AlgoAccess is a co-located team until recently. Over a period of 7 months of co-located work since Jan 2014, we have designed and built an Optometry solution from the ground-up.  We have raised a seed round of angel funding from veterans in the Optometry industry and we have designed and built a fully working product over 4 sprint cycles and a couple of months of on-site customer discovery and product trials.  Our product development pace is balanced and fast as a co-located team and even though our team also included 3 software interns, the co-located environment allowed us to share knowledge quickly, level up as a team and handle uncertainties with regards to product decisions (a typical challenge new products always face).

From co-located to distributed

This brings us to the next phase of our company/team – can we still function effectively in a distributed manner?  Now that the interns are heading back to school but continuing with us as junior developers and one of our core engineers will be working from the States AND we have a new mum who will be working in a flexible manner from her home and I will only be working on-site with customers or with hardware as needed – can we still share knowledge and skills effectively and continue evolving our product to serve our customers?

In technical jargon, we are transiting from an Agile/Scrum team into an Async Development team (special props to Adrian Quek for teaching me this term “Async Development”).

In my mind (and based on my previous experiences working in a distributed team), it is a challenging task to operate as a distributed team but it is completely possible. Many successful tech companies like Github, Treehouse, 37Signals (37Signals do have a core co-located team though) and Buffer have continued to grow and succeed as a distributed team.

In my opinion, these are some criteria, skills and tools that are pre-requisites for a distributed team to succeed:

  1. The hiring process must be rock solid and the company must be prepared to pay each individual well.  Distributed teams depend on the fact that each individual in the team has good mastery over specific tech knowledge and skills and each person must have good time management skills and be able to use a variety of tools (mock-up tools, communication tools, coding tools) to function effectively.
  2. Effective tools and shared understanding of systems must be made available to support the team’s day-to-day operations.  For instance, the ability to communicate fluently at code level and review code in Gitlab is critical.  The ability to illustrate software workflow in Illustrator or Photoshop and share ideas on Trello as a product development tool is critical. Members of the team should also avoid creating busywork by communicating using emails; instead, use communication tools like Slack which integrates with Trello, Gitlab and Google Docs effectively
  3. Jon Yongfook Cockle specifically mentioned that the best kind of businesses that are suitable for digital nomads are businesses which do not have any “hardware” or “physical product” components.  In our situation, this is unavoidable as our Wifi/BLE peripheral (hardware) is an integral part of our Optometry solution for our customers.  Fortunately, this peripheral is not too complex and in my opinion, it is still possible to provide the necessary hardware components to specific members of our team so that they can work from home; or simply head down to our co-working space at Blk 71 to work on the hardware integration work whenever required.
  4. Don’t always work with each other remotely — it is important for members in a distributed team to meet once in a while for casual get-togethers OR for serious work.  Nothing builds trust like face-to-face communication and in order for a distributed to work effectively, there needs to be a continual “maintenance” of trust between team members.

As our team transits to a more flexible working style, it is important for each individual to keep learning and keep improving their skill set in order to function effectively and continually contribute to our growth as a company and provide good support to our expanding customer base.

Aren’t Emails asynchronous in nature?


The problem with emails is that they create information silos.  This hinders autonomous involvement in actionables and creates long chains of discussions which end up being busywork when nobody takes ownership on decisions and actionables.  Favor the use of tools like Slack which allows individuals to choose for themselves which channel (of discussion) they would like to participate in, public and/or internal wikis and blogs so the barrier to participation for distributed team members is limited simply to a “search” action.

Individuals should acquire the ability to communicate effectively using various tools – public blogs (like this one), slack for internal communication and reduce busywork created by emails.

Why scrum? Why agile development?

Scrum and Agile development are simple methodologies intended to solve the problem of

  • long product development cycles; and
  • a mismatch between a product’s business requirement and the actual resulting implementation

This illustration explains such mismatched expectations, and the consequence of long development cycles.  For anyone who has been working in the software development industry for a while, you would probably have gone through the hell of the typical waterfall development approach.  With an outcome where everyone in the team is demoralized and where you end up with a bunch less-than-happy customers – an unfortunate, dysfunctional outcome.


Agile product development has its roots from lean manufacturing (not to be confused with lean start-up) from Toyota; and is a general framework to guide small, empowered teams to execute on their product development work in an iterative fashion.  The Scrum Master course I attended in Feb talks about a specific practice in agile product development known as “Scrum“.

Shorter development cycles (called “sprints”) of 2 to 4 weeks and daily team meetings known as “scrums” allow the product team, the product owner and the customers/stakeholders to regularly review the incremental improvements made by the team in each sprint.  This narrows the expectations gap significantly and the increased communication level between the product team and the stakeholders reinforces a shared vision for each product increment made.

The ideal size of a product scrum team ranges from 3 to 9 (but 9 is already too big in my my opinion), comprising sales/marketing and design/product specialists in each team, with a typical ratio of 1-2 designers/marketers to 5 developers in each team.

The 2-4 weeks sprint cycle can be visualized with this diagram.


Some definitions:

Product Owner

In each team, there will be a “product owner”, also sometimes referred to as the “product manager”.  This is the person responsible for prioritizing product development features in each sprint and over the course of the entire product development (a product development process comprises of many many sprints, each sprint being 2 weeks to *maximum* 4 weeks).

The Product Owner is almost always the business stakeholder and is directly responsible for the financial well-being of the project, including profits/revenues when the product is launched to customers.

Scrum Master

For a team of 5-7, it is also the norm to have a Scrum Master.  Note that the roles of the Scrum Master and the Product Owner are completely different things.  The Scrum Master is a guide and a process-people-skills-resource facilitator.  The Scrum Master, however, *does not* set the product direction and is not the person to decide on product feature priorities.  It is the job of the Product Owner/Manager to decide on product feature priorities.

It is important for the roles of Scrum Master and Product Owner to be cleanly decoupled – two separate individuals.

Product Backlog

The team and the product owner comes together on the first day (at the start of a sprint cycle) for a 2-4 hours meeting to define the product vision and to list out all the product features that needs to be developed based on the product vision (also known as the product “hypothesis” per lean-start-up concepts).  The outcome of this 2-4 hours meeting is a long long laundry list of features that should be build that are hypothesized to serve the product vision/goal.  This laundry list is known as the “Product Backlog”.

Sprint Backlog

After the Product Backlog has been established, the next 2-4 hours is spent on planning for the *current* sprint (I will simplify things by saying that each sprint is 2 weeks, not 2-4 weeks).   Many of the Product Backlog items will be kicked out and only items that *The Team* can comfortably complete in the current sprint (2 weeks) will be placed into the “Sprint Backlog”.

Once the Sprint Backlog has been decided, the sprint commences on Day 2.  Notice that Day 1 is almost always spent on building team clarity and deciding on feature prioritization with *everyone* present and involved.

In an ideal scenario, it also makes sense to invite “Customers” and “Users” of the product that is being developed to participate in a limited way during this first day of planning.  This is where “Lean Start-up” practices meet “Scrum/Agile Product Development”.

Daily Scrum

Once the sprint begins proper, a 15 minutes session is allocated at a fixed time *EVERYDAY* for the team members, scrum master and product owner to do a stand-up meeting.  4 key points are covered by the product owner and the team in this 15 minutes.  Each member will summarize and share:

(1) Done: What has been done by him/her

(2) To Do: What needs to be done next by him/her

(3) Blockers: any issue (whether Technical or Administrative or Human-related) that is preventing him/her from achieving his/her personal tasks


(4) Updates & Re-prioritization, if any:  The Product Owner can provide market updates/discussions with meetings with clients on the previous day etc to the team.  The Product Owner can also decide to *CHANGE PRIORITIES* of items that needs to be done.  When certain development item’s priorities get changed, it will – in all likelihood – result in existing features being de-prioritized.  The sprint timebox is strictly 2 weeks (for newer teams, it is preferable to work in 4-weeks time frame to factor in time for picking up new knowledge and getting to know how each other operates).  Which means like the “law of conservation of energy”, what gets added in implies something else gets kicked out (and thus, gets removed from the Sprint Backlog and placed back into the Product Backlog).


There are a few advantages for having a daily scrum.  For example, good development work requires engineers to be in the zone when they are working.  Instead of “interrupting” a developer who is deep in his/her code and working through his/her current task, by having a fixed timing for the 15 minutes daily team update,  Product Owner and Scrum Master do not “break the developers’ zone”.  Breaking the zone is a huge source of lowered productivity and causes increased mistakes in software development.

On the other hand, *not* having regular communications between the product owner and the team will result in mismatched expectations and poor implementation prioritization.  So having this regular 15-minutes communication on a daily basis is the basis for team to collaborate optimally.  Market/customer updates brought in by the marketing specialist or Product Owner during this 15-minutes scrum meeting is critical for ensuring that everyone is “in-sync” with and “re-synced” to what needs to be delivered.

Scrum” is simply a formalized term to describe a set of practices for a professional product development team to work well together.  The focus is on keeping collaboration processes simple and organized. It is not a “magical” cure-all solution.  It still requires that the company hires the right people with the right aptitude and attitude for the team, and that the team uses common sense to work with each other, and more importantly, that the product we are developing finds the right product-market fit (lean start-up).  A product team can be top notch, but if the product fails to gain market acceptance, we are still doomed.

For a start-up product (or more generally, software project) to be successful, it needs to have BOTH market traction and excellent product execution, product execution using “Scrum” and the agile development methodology as explained in this post.  And market traction, as a completely separate topic and as a story for another time, depends on the ability of the product owner and founders of the start-up to determine market size and the market need for their start-up product.