In this article I want to explore different aspects of scaling a company that need to be taken into account if you're trying to grow exponentially. Generally when discussing about growth we consider revenue growth to be the metric we're measuring. One thing that is important, and that is considered throughout the article, is to be a profitable company. There's no point in growing exponentially if it is unsustainable or you're expenses are always going to be superior to your profits.

In the best scenario, your business grows exponentially without requiring any additional human power. The second best case is that it grows sublinearly, meaning that as demand grows, the amount of people required to support the company grows slower than the demand itself. Past this point, growth either matches with how many people need to be hired, or worse, growth is slower as you hire more people. Here you may have exponential human power growth to get linear (or sublinear) revenue growth.

When hiring people, you need to be able to onboard them while having as little impact as possible on the existing employees. If existing employees need to spend time onboarding new employees, then nobody is working on product development or support during that period. Here again, you want the number of people responsible to onboard and train new employees to be smaller than the number of people being onboarded. In other words, you want the ratio of onboarded to onboarders to be higher than 1 to 1.

When a company grows exponentially, every time the company effectively double due to new hires, the culture is now at risk of instability. If for instance 100% of the existing employees were following the existing culture, and 100% of the new hires have a different culture, then there will be a culture clash with no specific half of the company being in control of culture. Unless culture continues to be managed through the process of onboarding, the initial group of people and their culture will rapidly become diluted.

We're not made to interact with dozen or hundreds of peers. As such, it is close to impossible for an individual to work with more than let say 10 direct peers. This means that teams or groups need to be created. This also means that interaction between teams needs to be managed somehow. Having multiple people from a team interact with another team leads to the implicit creation of a larger 20 people team, which does not work very effectively. On the other hand, having single points of contact between teams is a surefire way to have single points of failure. In this specific instance it is definitely necessary to have at least 1 or 2 redundancies.

It is also important to keep the people that have been at the company the longest. As the doubling period effectively divides by two the average duration an employee was with the company, losing those senior employees will speed up the drop in employee average tenure. This means that a lot of institutional knowledge will be lost along the way. This would also mean that you should possibly prefer to keep a senior employee at the cost of hiring a new employee, unless you believe that the amount of time necessary to onboard and be effective is lower than the average employee tenure.

The process of onboarding should be optimized as much as possible.

Anything that requires human power to scale linearly or superlinearly with itself needs to be optimized so that it grows sublinearly.

The onboarding process described here is specific to a software engineer joining a tech company. While some/most of the items may still apply to any job where you mainly work from a computer, the assumption will be that you develop software as an individual contributor.

  • Setup laptop
  • Access to slack
  • Access to zoom
  • Setup calendar reminders
  • Initial meeting with buddy
  • Access to git central repository
  • Installation of development tools/languages
  • Request software licenses
  • Access to CI/CD
  • Find where task management is done
  • Find the documentation to build projects
  • Connect 1 on 1 with each member of the team
  • Meet with manager 1 on 1
  • Define a 30-60-90 days plan with manager
  • Verify access to various systems (SSO, code repository, insurance company, payroll company, etc.)
  • End of week meeting with buddy

  • Setup and run the one step build process
  • Determine how are features/tasks prioritized, who prioritizes features/tasks
  • Review the team documentation
  • Review team practices/processes documentation (code style, code review, standups, planning, retrospective, demos)
  • Review common vocabulary, terminology, glossary documents
  • First PR + code review
  • Review the career ladder of the position

  • Review user definition, use cases, requirements
  • Read prior team meetings notes

  • Identify how deployments are done
  • Review the team roadmap
  • Determine where I can have the biggest impact
  • Determine a timeline where I'll have reached my 80/20 at the company
  • Determine the maturity of existing projects
  • Determine how fast can we iterate on certain aspects given the team/company composition
  • Identify the core/principal/staff contributors and their contributions
  • Review the architecture of the system
  • Review the database architecture
  • Learn about "how we got to this point"
  • Determine whether the product is a monolith or micro-services
  • Identify which (3rd party) tools are used by the team/company
  • Determine the portfolio of STARS situations of the team/company
  • Determine a rough estimate of the number of people in the different organizations
  • Connect 1 on 1 with important collaborator in other teams
  • End of first month meeting with buddy
  • First month performance review with manager
  • Informal 360-degree review with manager and peers on adaptation
  • Month 1 job satisfaction review

  • Team interaction diagram
  • Month 2 job satisfaction review

  • Month 3 job satisfaction review
  • List all the features you would like to develop
  • Define an appetite for the task (day, week, month, quarter)
  • Identify the features where the appetite differs between individuals and discuss them to reach consensus
  • Define the roles necessary to complete the task
  • Identify dependencies between features
  • Categorize the dependencies
    • Soft: somewhat depends on this other feature but isn't blocked by its absence from the codebase
    • Hard: depends on this other feature and is blocked by its absence from the codebase
  • Prioritize the features
  • Estimate the value of a features in dollars
  • Calculate a ROI (return on investment) as the estimated value of the feature divided by the defined appetite
  • Order tasks according to dependencies and ROI
08 Mar 2020

Reducing your error rate

History / Edit / PDF / EPUB / BIB / 3 min read (~430 words)

How can I reduce my error rate when using my skills?

When using skills in which you can make mistakes, it is important to monitor what you do and where you make your mistakes. Like any performance optimization problem, you want to figure out where you make the most mistakes and where you'll benefit the most from fixing those mistakes. If you make the same mistakes 100 times at the cost of a minute each time, that may be preferable to making 1 mistake that cost 100 minutes to fix, given that once the mistake happens, the cost stays the same.

Document your skills. Write down what you do, when you do it (triggers) and what kind errors you make during those steps. Evaluate how many times you make that mistake and how long it costs to fix. Then when you use your skills, track when you make mistakes and how long it takes you to fix the mistake.

As an example, think of a software engineer doing code reviews. Reviewing code requires going through a variety of checks: is the build passing? is the functionality properly implemented? are there tests? are the new files in the proper location? Without a list, the engineer is left looking at the code without any clear checklist. If he is methodical he will have a list he goes through in his head. If not, then he will most likely only look at the code and give it a summary opinion, that is, whether he likes what he sees, or not.

Given a non-explicit methodology it is hard to assess where the mistakes are made and which mistakes cost the most to fix. If you don't check that tests were written for the new functionality or changes, what impact will it have in the future? Depending on how likely the code is to change, the likelihood that something gets broken may be significant. While adding a test may require a few minutes, one has to judge how much time would be wasted if a bug were introduced in the piece of code. As code complexity increases, so does the cost of fixing issues in that code.

With an explicit checklist you will be able to track the things that you want to verify before code is merged. As your checklist covers more and more cases, this list will reduce the likelihood that the person who wrote code made a mistake that gets to production. By the same token it will increase your effectiveness as a software engineer to produce quality code.

05 Mar 2020

Adding tests to a project with no tests

History / Edit / PDF / EPUB / BIB / 2 min read (~309 words)

There are no tests on the project I joined. How do I get started?

When joining a new project without tests, here is the value you need to provide through the addition of tests:

  1. the application works and doesn't crash
  2. the application works and supports a few input cases
  3. the application works and supports a variety of input cases
  4. the application works and is robust to most input cases

Start by finding the main entrypoint of the program and call it in a test. Your test doesn't have to do much, other than ensuring you can start the program and possibly exit. Your goal should not be to assert anything yet, but to exert the code. Create a few tests that do very few things other than starting and terminating the program. Once you've covered a few use cases, you can use those tests to ensure that the application can start, do a few things, then terminate without crashing.

Start unit testing the various parts of the code that are critical. To determine what is critical, you'll have to dig into the code. With the tests you initially wrote you will get a sense of the "critical" pieces, simply due to the fact that they are executed whenever the program starts and stops, which are two things you always want to work.

When writing unit tests, always aim to write a test case that covers the happy path first. You want to demonstrate that the functionality a class or function is supposed to provide is there first and foremost. Then you want to test its robustness and its ability to handle a variety of input cases. Given a large codebase, start by covering most of the code with the happy paths before you start to dig into the special cases.