Our mission is:
To provide high-quality medical imaging software services to our clients and meaningful, flexible, and financially rewarding career opportunities to everyone on our team.
This handbook describes how we develop great software while maintaining enjoyable, flexible, and financially rewarding careers. We wrote it for a few different audiences.
If you are considering joining us, this handbook should help you decide by providing insight into how we work.
If you just joined us, this handbook should contain everything you need to know to hit the ground running. We are excited that you are on the team.
If you have been with us for a while, then you are probably checking to see whether Black Friday is a company holiday (it is).
If you have hired us, this handbook may be rather dull, but we are glad that you are curious about how we work.
This handbook is hosted in a public git repository. Please suggest improvements! You can do so by submitting a pull request or making a suggestion in #general. For example, you have a question that you wish the handbook answered, let us know. If you are an existing employee and you think you can improve how we work, create a pull request.
We do our best to keep our values at the center of how we work. Our company values are to:
Treat our clients ethically.
- We don't provide unrealistic project estimates to close deals.
- We educate our clients so that they can make good business decisions instead of capitalizing on the lack of software expertise.
- We recommend partner firms if we believe they would be more appropriate for a client's problem.
- We write high-quality code so that it can be maintained as cheaply as possible.
Be pleasant to work with.
- We help each other learn new things.
- We compliment others when they write good code.
- We try not to complain.
- We don't dump our work on others.
Respect the autonomy of fellow developers.
- We avoid micromanagement.
- We value logic and reasoning over seniority when making technical decisions.
- We avoid prescribing up-front solutions to problems; we prefer allowing developers to explore their ideas first.
Pursue a deep understanding.
- We don't just code and hack our way through problems.
- We aren't satisfied just knowing that it works; we want to know why it works.
- We view the computer logically and without superstition---there is no magic.
Build quality software.
- We write automated tests to guide our design and ensure our code continues working.
- We write code that is as simple as possible for others to understand.
- We prefer projects where we have the time to build the system architecture correctly from the beginning.
- We only accept projects that will provide us an opportunity to learn.
- We offer developers time to acquire new skills and pursue their interests.
- We write articles to solidify our understanding.
- We enjoy experimenting with new technologies so that we can use the best tools for the job.
Be responsible for our work.
- We push hard to meet deadlines.
- We don't leave sloppy bugs for others.
- We don't leave broken code, even if we did not write it ourselves.
- We try our hardest to solve problems before asking others for help.
- We continually and actively improve the development processes used in our projects.
Understand the business context.
- We aim to understand the purpose of a feature before we build it.
- We use technologies with the best interest of our clients in mind, even if they are less appealing to us as developers.
- We don't waste time over-building features that are not relevant to the business.
Make the world better.
- We love working with talented people, regardless of their age, gender, ethnicity, sexual orientation or background.
- We financially contribute to open source projects that we use.
- We don't work on projects that we don't believe make the world better.
- We don't work on projects that we don't believe will be used or will be useful for others, as this is demoralizing.
- We value correct grammar and a strong grasp of the English language.
- We write with a clear and professional tone.
- We try not to send vague or confusing emails.
- We invest in improving our writing, presentation, and conversational skills.
Enjoy our work, and relax.
- We want everyone on our team to enjoy their work.
- We provide a flexible work environment.
- We push back on unrealistic deadlines.
- We encourage vacation to maintain a sustainable workload.
We suspect most of these values are not controversial. Still, if you disagree with any of them, or if you want us to add or modify any of them, please initiate a discussion! Here are three examples of how our values have changed over time:
After we hired our first developer, we added “We love working with talented people, regardless of their age, ethnicity, sexual-orientation or background”. A few months later we added “gender” to the list.
We added “We financially contribute to open source projects that we use” to the list because, as a profitable company that uses many open source projects, we feel we should give back.
We clarified “we write automated tests to ensure our code works (and continues to work)” by re-writing it as “we write automated tests to guide our design and ensure our code continues working” to highlight our belief that tests have multiple purposes.
Originally, one of our values read: “We don’t prescribe solutions to problems; we allow developers to independently discover their solutions first”. After some discussion, we changed this to: “We avoid prescribing up-front solutions to problems; we prefer allowing developers to independently explore their ideas first”. This change was made because we realized that sometimes it is too time consuming to allow everyone to explore their solution, especially junior developers working on problems that have been solved many times in the past. In these cases, we believe it can make sense for the more experienced developer to prescribe a solution up-front. We prefer to have junior developers to find their solution first because it is educational and can lead to better solutions (perhaps a new technology was developed recently, or the junior developer comes up with a new approach).
This last example highlights that many situations we run into as developers are not black-and-white. Our values are a foundation for discussion, but often we are weighing competing goods. For example, “We enjoy experimenting with new technologies so that we can use the best tools for the job” and “We use technologies with the best interest of our clients in mind, even if they are less appealing to us as developers” can be competing goods.
Most importantly, if you feel that we are not following our values, say something! We can not stress this enough. It is essential that you say what you think.
Several months after adding our commitment to contribute to open source software, we still had not done so. Someone brought this up, and in response we setup our open source contribution page.
Medical Imaging Software Services
We love working on medical imaging software. Our work helps doctors diagnose and treat patients in the clinic and helps researchers make breakthroughs in the lab. We believe that software has the potential to transform the medical imaging industry, and we are excited to be front and center in this transformation.
Medical imaging software is a specialized field, so we don’t expect everyone who joins our team to have a strong background in it. Many of our projects have challenges that are not unique to the medical imaging. That being said, you do need to be interested in medical imaging, have some mathematical background, and have a desire to learn more to be a successful part of our software team.
We Are a Fully Remote Team
We are a fully remote company. We don’t have a central office, and most of our communication occurs in email, Slack, and video calls.
Working remotely allows for a flexible work schedule. For example, David’s wife is a nurse. She works night shifts and during many weekends, but is frequently off during the work week. If David did not have the flexible schedule that remote work affords, he would see his wife much less often. As it is, he can work longer days when she works, and work shorter days when she is off. Also, because he works from home, he can see her when she wakes up in the afternoons.
Although flexible work schedules are possible for non-remote workers, they are harder to arrange or take advantage of. When everyone is working in the same location, there is a lot of pressure to be “visible” at meetings and during the typical work day. Going on an afternoon errand run is often impractical. Conversely, when a company employees only some remote workers, it is easy for those workers to get left out of meetings and company activities.
An all-remote company encourages everyone to focus on their value-added instead of hours worked because value-added is more visible than long hours in a remote setting.
There are many more benefits to working remotely which we will not list here. However, there are also important-to-mention disadvantages to working remotely.
Working from home is not for everyone; it can be lonely, and it is easy to go stir crazy. It is more difficult to separate work from your personal life.
If you have never worked remotely before, it is worth thinking through how you will manage or respond to these various issues. Some people prefer to work from a co-working space on some days. Other people like working from coffee shops in the mornings—Andrew usually does this. David has two “users” on his MacBook, one for his personal life, and one for work. This allows him to turn off email and Slack notifications when he stops working for the day by switching users.
It is more difficult to develop strong relationships with remote teammates because we can’t grab a beer after work or chat in person. There are a few ways we alleviate this. The first is via conversations on #random. Next are our 10x Discussions about various medical imaging and programming topics. Finally, we have retreats at least twice a year. More about our 10x discussions and our retreats in a bit.
We Are a Small but Growing Team
We are a small team. Currently Innolitics has six full time members. Andrew, David, Yujan (the Founding Partners), Willy (Senior Developer), Zach (Junior Developer), and Reece (Junior Developer).
We are planning on growing the company substantially over the next few years.
Working on a small team means we have relatively little structure and more personal responsibility. As an early member of our team, you will have the opportunity to grow with the company, and to influence how the company develops.
We work on projects of varying sizes. Our typical engagement lasts about six months, although we have been working with some of our clients for several years. Typically, everyone is assigned to a single project at a time.
Each project has a project lead who is ultimately responsible for the success of the project. The project lead’s responsibilities include:
- Being the main point of contact for the client
- Making sure there is someone to step in as main point of contact if they will be out of communication (e.g. on vacation)
- Advocating for the client’s happiness to the group (e.g. if the project could use some extra resources to meet a deadline)
- Relaying to the group what tasks need to be accomplished on the project (during task meetings as well as when unexpected items come up during the week)
- Organize tasks in the project management tool, and track deadlines
- Facilitate discussion about the proper tech stack to use on a project.
We usually have client progress meetings on Mondays, and additional meetings as necessary throughout the week.
Nearly every Wednesday from 3:30 - 5:00 PM CST we meet to discuss an article, video, or book chapter. Topics are usually suggested Friday afternoon and everyone is expected to read or watch the material before the discussion. Some weeks we’ll skip the discussion if there’s an impending deadline or many folks are on vacation. We try to pick topics that are fun and interesting and will make us better developers.
Please feel free to suggest topics in #learning. If we end up using your suggestion, please add a new item in our list of previous discussions.
You can see a list of our previous discussions here.
We meet two times each year to have some fun and get face time with one another. The retreats usually begin Thursday afternoon and end Saturday afternoon. The destination always changes. We cover the travel, housing, and food during the retreats.
Unless there is a very good reason (and please let us know as soon as possible), everyone is expected to attend all of our retreats.
Flexible Work Schedules
We value our flexible work schedules, however, this does not mean that we can work anytime we wish.
- Everyone should be available for our 10x discussions on Wednesdays from 3:30 - 5:00 PM CST.
- Everyone must be flexible enough to make client meetings. We typically try to schedule these on Mondays, however, it varies from project to project.
- Your work hours must, to some degree, overlap with the hours of other team members who work on the project. This overlap is important to ensure that code is reviewed promptly and timely communication can occur.
- All else being equal, it is best to work during the normal work week.
Performance evaluations occur every six months from your join date. Notes from the performance evaluations are stored in a google document, and are only visible to partners and yourself. Notes from the previous evaluations, and in particular areas of improvement, are reviewed at the start of the next review.
If you are new, we will also have an evaluation once you have been with us for three months to ensure that you are enjoying your new position.
We use email, Slack, and Skype for internal communication.
Email is best for non-urgent communication that requires a formal or well thought out response.
Slack is best for most everyday communication. Here are some rules of thumb for Slack communication:
- Write messages in the appropriate channel. Project related discussion goes in the project-specific channel. Discussion related to marketing goes in #marketing. Random chatter goes in #random.
- When someone asks a question or makes a request, respond quickly—even if it is just to acknowledge that you are “looking into it.” Often the other person will be waiting for a response and if you look into the issue before responding, the other person will waste time.
- @mention people when you need their feedback.
- If your presence or absence may affect other team mates, it is nice to mention when you start working, go to lunch, or stop working in #general. This notifies people that they need to ask you any last minute, potentially blocking questions before you leave.
- Only use direct messages when you have private stuff to say that would be of no interest to anyone else. It is typically better to stay within the project’s Slack channel so that other people on the project can see what is going on (even “future” people that may join the project at a later time).
We use Skype for all internal video calls because we have found it to be more reliable than other video conferencing services.
The person who initially mentions starting a call in Slack should initiate the call; this convention avoids delays that can occur when both members are waiting for the other person to call.
When on a client call, follow some video call etiquette:
- Mute yourself when you aren’t speaking if there is background noise or if many people are on the call.
- Look into the camera, and not at the video stream.
- Ensure you have proper lighting.
- Smile! It can feel unnatural smiling at a webcam, however, it makes you look better.
Respond to client emails promptly during the business week, even if it is just to say that you will respond in full at a later time. We have found that one of, if not the most important factor, influencing client happiness is quick and clear responses to emails.
Informal writing is sufficient for internal emails. However, when emailing clients, please pay extra attention to your grammar and spelling.
To retain flexible work schedules, we do not usually have a morning “standup” unless the client requests one. Instead, we post our progress in #standup.
The frequency and level of detail included in your standups should depend on the project and the team. If you are tightly collaborating with several other people, it may be worth posting progress updates daily. If you are the sole person on a project, a weekly update is likely sufficient. Please post updates at least once each week. It is nice for everyone else on the team to be aware of your work.
If team members or your project lead request that you post standups more frequently, please do it.
A typical standup should include:
- What you accomplished since your last update (if appropriate)
- What you hope to accomplish during this day (or week, or whatever time-period you post updates)
- Whether anyone is blocking your progress in a non-urgent way (if it is urgent, contact them directly).
Paid Time Off and Holidays
Members typically receive two weeks of paid time off during their first year, three weeks for their second and third year, and four weeks each year after that.
We also have Christmas Eve, Christmas Day, Thanksgiving Day, Black Friday, Memorial Day, July 4th, Labor Day and New Years Day off. If these Holidays fall on weekends, we observe them on the closest weekday. Please note that this list does not directly match the US federal holidays. For example, we do NOT observe Columbus day (a federal holiday), while we do observe Black Friday (not a federal holiday).
Notify your project lead in advance when you want to take a vacation, and be sure to request it using Gusto. Since we’re a relatively small operation, the more notice, the better.
One of the perks of working remotely is having a flexible work schedule. Because of this, sometimes we will take off during the week but will make it up over the weekend or in the evenings without taking vacation time. Taking off during the week depends on the demands of the project you are currently assigned to; for example, often we have client meetings during the week.
Payments and Compensation
We run payroll every two weeks. The last payroll of the year will include any annual bonuses. Payments are made using Gusto.
We discuss raises during every other six-month review.
We have a 401(k) plan that allows for traditional and Roth contributions. We provide an automatic 3% of your salary to the plan whether or not you choose to invest (free money!!). Our 401(k) plan provider is Vanguard, and the plan has many low-fee mutual funds available. You become eligible to contribute to the plan after six months of employment.
No Health Insurance
We do not currently provide company health insurance.
Open Source Contributions
Each quarter we donate $500 to an open source project. We decide which project through discussions with everyone in the company. You can see previous projects we have donated to here.
Securing company passwords is imperative. Many of the projects we work on involve patient data, and an essential aspect part of securing this data is to be careful with our passwords because most software breaches are due to human error and not technical issues. For this reason, we all must take password management seriously (while acknowledging that it can be a pain). Here are some good policies for password management:
- Use your company email.
- Do not write down your email password anywhere; memorize it, and use a strong password.
- Use LastPass for managing ALL company related passwords and sensitive information EXCEPT your company email account password.
- Do not write down your master password anywhere. This rule is essential, as the master password is the key that opens all the doors.
- You should thus only have to memorize two passwords: your email password, and your master LastPass password.
- Do NOT use your personal password manager for company business (e.g. the Mac keychain–—it is not as secure as LastPass, if nothing else because they allow super weak master keys which could be broken if your laptop was stolen).
- Each project should have a shared folder where all project-wide passwords should be stored. Individual developer passwords for the project can be shared locally.
- Whenever adding a new password, think through what would happen if you were out of town or on vacation, and someone else would need that password. If it would be needed, it should probably go in the shared folder.
- Secure items that aren’t a password, but are necessary for project work, should be stored in secure notes under the appropriate shared project folder. Examples of this are software license keys, etc. Include details on how to use it in the note as well.
- Share passwords via LastPass (and not via Slack or email).
When you first join our team, we will setup the following accounts for you:
- Google Apps - email, calendar, online file sharing, documents
- Gusto - payroll and PTO
- LastPass - password management
- Slack - team chat
- Vanguard - your 401(k)
You will also need to setup a Skype and Github account if you don’t already have them.
We will mail you a box of business cards.
Coding Best Practices
Please read through our Coding Philosophy and Best Practices.
This handbook is intended to provide a general overview of the company’s policies and procedures. Nothing in this handbook is to be interpreted as a contract, expressed or implied.
We may revise, suspend, revoke, terminate, change or remove, prospectively or retroactively, any of the policies or procedures of the company, whether outlined in this handbook or elsewhere, in whole or in part, with or without notice at any time, at the company’s sole discretion.