The McKinley & Rice Introductory Manifesto for New Joiners
An introductory guide to living and working at McKinley & Rice for newly minted cadets
Version 1.2 (Last edited March7th, 2019)
Work and sleep take up 16 hours every day. We shouldn’t be spending two thirds of our lives creating just ‘acceptable’ products.
Let’s make amazing products that will stand the test of time. That will have our names written on them. And while we’re at it, let’s enjoy the ride.
Welcome to McKinley & Rice
— — —
We are excited to have you on board. Here are some essential tips to get you acquainted with our system. We call it a ‘Manifesto’ instead of a ‘Manual’, just because it sounds cooler. We also tried to keep it as short as possible, for your reading convenience.
— — —
We’ll be working at Office No. 602 Ithum Tower A, Sector- 62, Noida, Uttar Pradesh 201309 India. It’s a newly constructed office tower, housing a couple of eateries like Bikanervala, Barista Coffee etc. on the ground floor, and a metro station 2 minutes away.
Works together with “Attendance and Leave Policy” posted in Seminal.
The default working hours are Mondays to Fridays from 9 am to 6 pm with a 45-minute lunch break. Note that this is 12:30 pm to 9:30 pm in Seoul/ Tokyo, and 8:30 pm to 5:30 am in San Francisco, where the workday has already started.
Who we are
We first started out as a tech consulting company that spun off of a law firm in Seoul, and then expanded our operations to the U.S. Now, after closely working with Indian Software Development companies for the past couple of years, we feel that we have enough clients and enough support in the market to truly prepare for the future.
We hope that our Indian operations, named ‘McKinley & Rice Creativity’ will help pave the way for dominating the software development market in Asia, and will help us (1) Train and retain software developers that are truly creative and (2) Facilitate easier cooperation between ourselves and our Indian partner firms.
Our long term plan
1. To help other businesses launch their successful products
2. Once we are a strong enough development team, we launch our own successful products
What do we want to achieve as a company? It’s pretty straightforward. First, we learn from all the major players in the global Tech community. We will train excellent developers. Second, armed with our experience, we will go the extra mile, launch or own products, and overtake the market.
— — —
McKinley & Rice Creativity will be the Executive Wing for all other McKinley & Rice offices, focusing mainly on (1) Design and (2) Software Development. The Chief Operating Officer (COO) will be in charge of all day to day operations, legal compliance and government body liasoning whereas the CEO will act in the capacity of a Client Communications Lead.
Our competitors are not other Indian companies. We sell our services overseas, thus our competitors are developers in Silicon Valley, Seoul, and Beijing. So whenever a client comes on board with a new project, we expect that you take the time to look at similar successful products around the world. (A good website for this is ProductHunt.) What makes them unique? What did they do better? How do they integrate different functionalities? What tech stack do they use? How can we one-up them?
Within a decade the world will be even more connected, and when that time comes, simple lower-cost competition will no longer be an option. Thus we must quickly learn how to compete at global standards. We want every person in the company to be able to compete against their equivalents in the U.S., China, South Korea, and Japan within 3 years of joining the company.
Principles of operation
— — —
Autonomy with Accountability
· With great power comes great responsibility, and A-class players are comfortable with taking initiative. Every project will be divided into tasks, and for every task, 1 person will be the Primary Lead who will take full credit along with full responsibility for its planning and execution, along with being in charge of direct client communication. Atleast 2 people will be designated as Secondary Leads so as to ensure that there is a backup team in place.
· We don’t want project managers or business analysts. We always try to hire the best, and A-class players don’t tend to like being micromanaged. That’s why we want minimal hierarchy.
· Therefore, following Silicon Valley tradition, managerial functions will be integrated into the software development process. Upon receiving a client request, (1) Identifying what tasks must be done, (2) Creating a timeline, and (3) Executing the task will all fall within the Primary Lead’s scope of responsibility. Especially regarding the timeline, the deadline that you have agreed to will be an important performance measure that you will be held by. You may hit difficulties during the execution phase, and the CTO along with the Technology Leads will be there to help.
· Some might stay with us for life, others may stay for only a few years. Either way, work and sleep take up 16 hours every day. So let’s make the best out of our time together.
· Let us know your professional aspirations and dreams. To our best extent we’ll try to find a way to put the job in line with your life goals. For instance, if you’re a frontend developer who wants to go full stack someday, we can put you as a Secondary Lead on certain backend projects. If you’re a Laravel developer who is interested in Blockchain, we can put you as a Secondary Lead on certain Python projects.
· We can never overemphasize design. Why is Apple the most valuable company on the planet? Why does Google make their own CSS libraries? Take a deep breath and look at all the best companies in the world. Every single one of them has a distinct aesthetic philosophy that is in tune with their corporate culture. So never slack on design.
Work smarter, not harder
· In other words, plan thoroughly. Is there a better way to execute a given task? Take some time upfront to analyze the task and contemplate other possible solutions. Search Stack Overflow, Quora, GitHub etc. to see if there are existing libraries or frameworks that can help you with your work. Don’t spend 10 hours coding a component that is already Open Source.
· We don’t want you to do overtime if possible. This is not a company where overtime is mistaken for loyalty. Overtime makes people unhappy, is a burden on physical health, and thus harms the company in the long run. Let’s be efficient.
Types of projects we undertake
1. In-house fixed scope client projects
These projects are your run of the mill software outsourcing projects. They have a fixed scope and a deadline.
2. Small scale monthly client projects
These projects have no fixed scope and are smaller in nature. The clients are on a monthly retainer and will ask for either (1) A new functionality, or (2) A change in existing functionality, and it will be our job to give them good code.
3. Overseeing subcontracted projects
Some projects we won’t do in-house and will subcontract to our partner firms. We’ll be in charge of checking that they are made to specifications.
How we operate
Organizational Target for 2018
· Every team member must be able to compete with their equivalents in Silicon Valley, Beijing, Seoul, and Tokyo by 2023.
Primary and Secondary Leads
· Whereas the Primary Lead bears full responsibility for completing the task, the Secondary Leads are there to (1) Suggest alternative methods, (2) Learn, and (3) Understand what needs to be done in case something bad happens (e.g. the Primary Lead is sick).
· Good coders know that good programming has more to do with a certain way of thinking, and less to do with what language you are working with. Therefore, while the Primary Lead will always be someone with relevant experience regarding the task at hand, they may be paired with Secondary Leads from other backgrounds. (e.g. for a Node.js task the Primary Lead will always be a Node.js developer, whereas the Secondary Lead can be a Laravel or an Angular developer.)
· The default team size will be 3 people working on 3 tasks. So most people will be the Primary Lead for their own task, while being Secondary Leads for 2 other tasks.
· This organizational structure is to ensure that:
o (1) Hierarchy is kept to a minimum.
o (2) All developers will learn to be generalists in business, and specialists in tech. Thus there will be no need for an intermediary between the client and the engineers.
o (3) All developers will always be learning new things and honing their skills.
o (4) Source code will be reviewed on multiple levels. (a) The client will see the code when it is pushed to GitHub. If the client is not technically fluent, or has overlooked some errors, (b) The code will be analyzed during Code Review Sessions. © The code will also be reviewed by the Technology Leads on a regular basis.
Filling in the Gaps
· We know that oftentimes client requests are unclear, and at the very least will not have hammered the specifics down to the last detail. So you will have to take some initiative and fill in the gaps. For small and basic gaps, you can go straight ahead and iterate (e.g. even if the client did not write password encryption, you should use salted hash). For larger gaps (e.g. when the Application data fields don’t match the specs written for the Admin Panel), you should ask the client.
· Some tricky questions: What if the client wants something stupid (e.g. an App that makes no business sense)? Or what if there is a better way to execute what the client wants in a different way than what the client has specified? Well, it depends. You should definitely suggest it at least once to the client, but if they are adamant in proceeding with their stated requirements, just follow their lead.
· The ‘1 Primary Lead + 2 Secondary Leads Structure’ will be implemented on every level, resulting in a Fractal Design. Simply put, you will (1) Discuss, (2) Execute, and (3) Review on multiple levels.
· On a project level, whenever a new client project comes on board, the following steps would be carried out:
o (0) The Preparations Phase would include (a) Creating a new private repository and linking up their GitHub accounts as contributors, (b) Deciding who will be the Project Primary and Secondary Leads, and © Initializing an onboarding conference call.
o (1) During the Project Initiation Session you will (a) Analyze the client requirements, (b) Discuss relevant libraries and frameworks, © Break up the project into smaller tasks, and (d) Set high level deadlines with the team.
o (2) Then you will execute the project.
o (3) After the project is complete, you will run a Project Review (Post Mortem) to discuss how you would improve the execution should you be faced with a similar project in the future.
· On a task level, you would do the following:
o (1) During the Task Initiation Session, you would (a) Decide who will be the Task Primary and Secondary Leads, and (b) Set deadlines.
o (2) During execution you may encounter unexpected difficulties. You should first analyze the problem. What can we do as a company to solve that problem and get the project back on track? Why was that difficulty unexpected? Did you initially set the deadline too tight? Would adding more people to the task alleviate the problem? Remember, the worst thing you could do is to go over the deadline, so when in doubt, ask for help.
o What about quality? How would the best programmer in the world have executed the same task? Are we sure that we’re not sacrificing too much quality for speed?
o (3) During the Code Review, you should look at how other people solved their own problems. What can you do next time to bridge the gap between you and the best programmer in the world?
Daily and Weekly Requirements
1. At the end of every day, push your work to GitHub. Even if you wrote just a single line of code, push it to GitHub.
2. Never enter an online meeting without video. Video must be turned on initially. If internet connection is bad, turn the video off after the conference call has already started.
3. At the end of each week, send the COO a weekly report. Don’t overdo the report. Minimalism is stressed here. If it takes you more than 15 minutes to create the report, you’re doing it wrong.
The weekly report should include of 4 things. (1) What you did that week. (2) What will be done next week. (3) Any questions you have regarding the project. (4) What you are currently working on to improve your skill.
4. Task Initiation Sessions and Code Review Sessions should be held before and after each task is completed. Ideally they will last for 1 to 2 hours, and will be held every 3 to 4 days. These are important in 2 respects. (1) They will force you to really think and plan out what you’re going to be doing, and (2) They will help you learn new stuff and see what other people are working on.
· Project and task deadlines will be set after receiving input from the Technology Lead and the Primary/ Secondary Leads. Once the deadlines are agreed upon, you will be held by them. By default, our policy is to factor in a safety multiplier of (1) 1.3 regarding all projects, and (2) 1.2 regarding all tasks.
· Once again it must be stressed that in all professional settings, missing deadlines without good cause is treated as a very serious offense.
· We are aware that some engineers write less code but are of excellent quality, whereas others write more code but contain many bugs. To ensure that we are continuously able to incentivize improvements in performance and help individuals develop their professional skills above and beyond global standards, all engineers will be expected to include their names (or, following old hacker traditions, their Coding Alias) within the comments for each task. This will apply to Secondary Leads and the CTO as well. Therefore, the (a) the requirements of the task at hand, (b) the name/ alias of the Primary Lead, © the names/ aliases of the Secondary Leads, and (d) the names/ aliases of the reviewers should always be included in the comments.
· Documentation is important, but not as important as the code itself. Every organization has different requirements about the exact level of detail regarding documentation, and the CTO will be there to give constant feedback during the adjustment process.
· An abstract rule of thumb would be: Less documentation is required for common functionality, and more documentation is required for app specific functionality.
Performance evaluation policy
Works together with the “ Employee Reward, Recognition and Appreciation Policy” posted on Seminal.
· First of all, we have a no bullshit policy regarding compensation. Good performance will absolutely be noticed and compensated following specific rules. Bad performance will absolutely be noticed and met with consequences.
· Note that ‘Bad Performance’ is different from ‘Making Mistakes’. To err is human, thus mistakes will not be met with penalty, especially when the mistake was made during the execution of a bold, pre-authorized initiative.
· Good Performance is comprised of simple common sense. (1) Know what you can do, and what you can’t do. (2) Be in charge of tasks that you can do. (3) Do those tasks. (4) If you anticipate difficulty, ask for help before it is too late. (5) If someone asks for help, try helping them. (6) Keep learning to expand what you can do.
· Bad Performance is when: (1) Failure to fix an issue that has already been repeatedly commented upon. (2) Failure to keep a deadline. (3) Bad behavior towards teammates.
· Increases in compensation for renewed contracts will be determined 3 months before the end of the contracted period. Management will lay out beforehand what the key measurement criteria will be.
· The bonus clause stipulated within Section 5 of every Employee Agreement is very real and we wish that everyone receives at least some form of additional compensation. We don’t want people wondering whether or not they will be receiving bonuses up till the end of the year. Therefore, bonuses will be finalized and accrued at the end of each quarter, starting after the initial 4-month probationary period, but will be paid out according to the contract (i.e. the end of the contracted period).
· The most important, distinguishable factor that will impact performance evaluation is: Client contract renewal. Whenever a client renews a contract, it is a clear signal that they are satisfied with the result.
Dress code policy
Following the Global Tech Standard of Smart Casual
· McKinley & Rice’s official dress code is ‘Smart Casual’. ‘Smart’ means ‘neat’. Therefore, attire that might make coworkers uncomfortable, such as tank tops, halters, and backless shirts are not permissible. ‘Causal’ means that we encourage employees to dress comfortably for work. Therefore, hoodies, t-shirts, jeans and sneakers are welcome.
· Note that ‘Casual’ does not mean ‘Dirty’. Hygiene is an important theme in all of our offices, and thus all employees will be expected to be clean and well-groomed. Grooming styles dictated by religion and ethnicity aren’t restricted.
· We will deal with employees who wear attire that is inappropriate in this workplace on an individual basis rather than subjecting all employees to a more stringent dress code for appropriate business attire.
Lunch and break time policy
We are all professionals here
· We know that A-class players don’t need micromanaging. Only amateurs do. We also know that people can’t be productive and creative 24/7. So take breaks when necessary. Eat lunch when you feel like it. Pretty much anything goes, provided that you do your work, with the caveat of deadlines.
· Deadlines are important. For every project, deadlines will be set by you, and therefore you will be held accountable to them. and No professional occupation in the world takes deadlines lightly. The worst single thing you can do at this company isn’t punching the CEO in the face. It’s breaking a deadline.
A single A-class player > Many mediocre players
· We always try to hire the best players, or at least people who are capable of being the best players. We believe that once A-class players have worked in an environment full of other A-class players, they can never go anywhere else. Because superiority is addictive.
The Development Support Team
The CEO and Management
· What is the job of the CEO? What value does management bring to the table? It’s simple. Management creates systems that help people market their time better. For example, in a manufacturing plant, workers use resources (their time) to create products. In a sense, everyone’s time is embodied within the product. And thus management creates systems so that can everyone can get a better deal for the time that they’ve spent. This includes things like: A better team, a better working environment, a better daily experience, and better compensation.
· So what does management at McKinley & Rice do? (1) Market everyone’s time to the world better. (2) Help people grow and reach their full potential, so that their time can be better marketed to the world. (3) Create a strong organization so that we can impact society into the direction we deem fit.
· This is management’s job. And management will be held accountable for their position, as the same as everyone else.
The Design Team
· The Design Team will be in charge of all aesthetics. Why do people pay 10 times more to own a BMW over a Hyundai? Because the engine is 10 times better? No. They buy it for the brand. And design is the single most important criterion that launches successful brands. We want to raise the bar for software development, so it is imperative that the packaging reflect the quality of the product inside. So we believe that stuff should look as good as possible.
· This includes:
o Reverse engineering the latest aesthetic trends.
o Making sure everything that exits McKinley & Rice is in tune with the latest aesthetic trends.
o Selecting the color schemes.
o Discovering the appropriate fonts for each project.
o Checking the alignment, margins, and paddings for all components.
o Checking the animations for all components.
The Film Team
· We have noticed that the primary psychological barrier keeping potential clients from signing on is skepticism regarding India’s tech and design prowess. This is because many first world corporations still think of India as it were 20 years ago, which is reflected in a common inquiry our Marketing Team receives, “Our company tried outsourcing to India in the 1980s, and it failed. Why should it be any different this time?”
· To bridge this gap between perception and reality, and also in an effort to keep up with latest social media trends, we have decided to launch a corporate ‘Vlog’, which will demonstrate that Indian technology is more than capable of competing against that of other countries. The Vlog’s purpose is twofold: (1) Showcase Indian life and culture along with India’s rapid growth. (2) Make superstars out of our team members.
· Before each video is uploaded, the Film Team will receive approval from (1) all team members that have been significantly portrayed in said video, (2) the COO, and (3) the CEO, so as to ensure compliance with international and local laws.
Chief Operating Officer
· The Chief Operating Officer will be in charge of the entire office. This includes: (1) Overseeing all projects are done according to deadlines, (2) Giving credit when due (i.e. evaluating performance), (3) Having the final say in recruitment, (4) Assessing what can be done to improve team happiness and efficiency, (5) Ensuring legal compliance, (6) Managing Government Liasoning.
· Contact information for the COO:
o Mr. Kartikey Handa (P. 964.324.8835 / E. firstname.lastname@example.org)
Let’s set the bar higher for software companies around the world.