Skip to content

Latest commit

 

History

History
47 lines (38 loc) · 3.38 KB

compliance.md

File metadata and controls

47 lines (38 loc) · 3.38 KB
title date description authors tags hide_frontmatter
How we keep things on track
2019-03-13
Building an effective company is like building good software.
han
handbook
employee
performance
true

Building an effective company is like building good software

  • First, we define the specs.
  • Then we implement the specs.
  • After that, we test and make sure everything works correctly. So, first we need to define the specs, in this case:

Define standard for the company

We already produced our playbook as the specs so that our company has a base to run on. It's a place where the newcomer learns new stuff, the current members have a reference for the information that they needed. Compliance is actually the quality control (quality assurance) to make sure that the company is running exactly how it should be:

  • It is not a one time work but will continue throughout the company life, as well as envolving overtime when the company grows to maintain the standard.
  • It is not a one person work but the whole team effort:
    • We need every team member to review, contribute, suggest changes to our current playbook so it is up-to-date and follow the standard. This is our official agreement of the whole team on how things should be done
    • We need every leader of the project to be aware of the standard and actually implement it.
    • We need the whole team to do it right and is strong enough to give advise for our customer.

How do we check if the standard is being followed? From the playbook, we will produce a compliance checklist:

Compliance checklist

Compliance checklists are being built, the very first version is stored here which include the checklist for the Projects that we are running. It will be expanded to all other aspects of the company. The compliance process will be executed with the compliance plan:

Compliance Execution plan

Every month, the compliance checklist will be sent out to the person in charge of the project (it would be either in parallel OR incremental based on the company state). After they have answered all of the questions in the checklist, these will be the result:

  • Problems: These are the items that did NOT follow the standard
  • Reasons: Why those problems occurred
  • PIC: Person in charge of the problem when it occurred
  • Action: Action required to fix the problem
  • Assigned to: The person that will perform the action to fix the problem

We entirely trust the integrity and ethics of the person in charge of the project to provide their input for the check list. However, to make sure all the other team member are also aware of the standard, we will randomly pick a junior/fresher of the team and verify those questions to see if they understand. This is not to point finger to someone, but to encourage the new member of the team to be familiar with the standard of the team.

Results

Like in the software development, QC/QA duties are to find the defect in the places that the Engineers are not aware of not to blame the Engineer but rather to improve the quality of the work. Compliance checklist is made so that we can fix the potential problems that will reduce our outcome quality. It's the responsibility of each individual to maintain the standard and there will be Hall of Fame, Wall of Shame to those whose are NOT following the standard.