How we handle time off

in Work Smarter


In a year, you get 10 days off. You accrue more days at a specific hour to hour ratio, and they will roll over at 50% for a maxmimum of one year. You’re allowed to get sick 7 times in a year. Sick days do not roll over. Other than that, you have to be in the office 8 hours a day, starting at 9. Welcome to Kindergarten.

When we get to college, we are charged with the responsibility to direct our own lives. No one will be calling if you don’t go to class. If you’re ill one day, no one questions it; you just have to find out what the missed work was and get it done on time. No big deal, you’re adults now.

Then, you graduate, enter what they call “the real world” with “a real job” and you’re told exactly where to be and when. Exactly what days you will have off. How much you’re allowed to get sick. How the game of accruing time off works, the only thing more complex than accruing rollover minutes on your cell plan. This baffles me. That’s not the real world. You’ve graduated into a world where “adults” are treated like children, apparently expected to be less responsible than college students, exemplified by the red tape that adheres you to your desk.

At Mindsense, we believe that if people have exciting work that motivates them, and a relaxing and fun office to go to, then they will do what they need to do, without rules for when they must be present at their desks. We understand that some people are more productive in the morning, and some people are more productive later in the day. We’ve seen that when people are given a greater level of autonomy, their motivation increases, but also their work is no longer tied to counting hours at a desk to “earn” the time to spend with their families later, rather their work becomes more directly tied to the greater mission of the organization. We also place a lot of importance in making sure people have the freedom to be with their families when they can be.

Team members get 0 vacation days. 0 sick days. 0 holidays. You don’t accrue time off. Instead of focusing on when and how much someone is in the office, we focus on what needs to be done, and what is accomplished. At the beginning of the week, team members decide what they will get done, and at the end of the week, they share their finished products with the team. Team members can be in the office when they know they are most productive, and no one is counting their hours to make sure they’ve earned time off for their family vacation in the summer.

We feel this is how all working professionals should be treated. Unfortunately, it’s not the case in most organizations. But we hope we can help pave the way to empower professionals with freedom and autonomy, while taking care of our responsibilities of providing meaningful work that has a significant impact, and an exciting, relaxing, and fun place to come each day to work and collaborate.


Sound interesting? Join our team! We currently have two open positions.

How we handle feature requests

in Work Smarter

Feature request blog post header3

On the surface, feature requests seem like a stressful chore, but on a higher level, feature requests are a sign of a healthy product and an engaged user base. After all, if users don’t like a product or don’t care about it’s success, they would not take the time to request features at all.

Rather than become distracted and bogged down by these requests, our team uses them as a powerful tool. We collect, read, distill and record every feature request we receive, identify themes, and prioritize to plan future updates and releases.


Requesting a feature is one of the most common reasons customers communicate with us. Both our in-app and online support portals have an easy method of submitting feature requests.

In building an email experience from the ground up, we ignored all preconceived notions and “features” of current email clients. This resulted in the intentional omission of many features that people have used as a crutch for years. To continue this process of finding the deeper problem that needs to be solved, besides a description of the feature being requested, we specifically ask for the reason that feature is important to a user’s workflow. We often learn way more from the reasoning behind a feature request than the feature itself.


Every feature request that we receive is read by a member of our team. We’ve found that we have to be in the right mindset to really get the true value out of feature requests. Therefore, we don’t read feature requests immediately as they come in, but rather engage in periodic feature request spurts. We normally don’t respond to requests unless further clarification is needed.


One major reason that we read each request individually is to distill the true meaning of it. While other software companies crowdsource some of this process with community forums where users can post and vote on features, we find that reading each individual request and reasoning provides far more depth and insight about what is actually being requested. By understanding the true reasoning behind a requested feature, we are often able to solve the root problem in a much better way than the specific feature that was articulated.


We keep a record of all of our feature requests. It sounds bizarre, but we actually use Basecamp to maintain this record. We create a to-do item for each feature that is requested and then add a comment with additional reasoning each time the feature is re-requested. Basecamp allows us to easily re-arrange the to-do items so we can keep most frequently requested items at the top. I call it a ‘record’ because we don’t reference this daily. We don’t dwell on feature requests, but use them as an asset to our product design and software development.


About once a month, we spend time looking at feature requests not as individual items in a list, but as a pulse check of what is important to our customers. In a simple example, if many of the most common requests involve changes to the interface, we know that it might be time for a UI redesign.

Right after we launched Mail Pilot for Mac, we received a lot of requests to “integrate with [insert other favorite app here]”. While many of these applications had APIs that we could integrate with, we stepped back and realized that if we opened up the ability to save and drag email items from Mail Pilot to other applications or anywhere within the operating system, users could create their own workflows of integration. If we viewed these requests as to-do items and not as a theme, the solution would have been far more complicated.


Finally, with our record of requests and a list of themes as tools, we prioritize what features will go into the next release. First, we estimate the difficulty and time involved in developing each feature. Then, we determine the number of development hours that we want to devote to a specific release, and we arrange the features within that release based on metrics of importance and a value to time ratio. Generally, this allows us two to four headline features, a half-dozen medium level features, and more than a dozen fixes or minor features. Once we choose the features for an upcoming release, we update the Mail Pilot Workshop so our customers can track the progress of development.

Share your insight

We hope this sheds some light on our process for handling feature requests and why we like to get as much information about each one as possible. If you have any suggestions for improving this process, feel free to reach out! And, of course, if you have any feature requests, let us know. Now you know we read them all!

How we communicate internally

in Work Smarter


Because we build email clients, many people assume that all of our internal communication is funneled through email. While we do use Mail Pilot for some of our internal communication, we currently use a variety of tools and constantly search for new applications to communicate digitally.

Communication is crucial for our small, busy team. Alex and I work full-time, normally from our office in Blacksburg, VA. Nathan, our customer support manager works remotely from Orlando, FL. We consistently have part-time independent contractors and student interns who always utilize a high percentage of remote working.


HipChat is described as “Group chat and IM built for teams”; that’s exactly how and why we use it as our most common form of digital communication. HipChat is our method of communicating more informally and instantly. Quick questions, sharing a success story, posting a relevant news article, and short status updates most commonly flow through HipChat. We have multiple rooms set up and it’s incredibly useful to know who is in each room at any given time. Even when we’re communicating with others across the office, HipChat provides a means of communicating without disrupting someone’s train of thought.


We use Mail Pilot for more formal communication like sending and discussing important documents or sharing an in-depth thought or idea. A high percentage of our emails involve simply forwarding external communication to one another with internal commentary. We make a point not to use email for anything that requires a quick or instant response as we know HipChat is a more efficient means of conducting that correspondence.

While we often use email for more formal communication, we’ve also evolved a unique way of pulling the unnecessary formalities to get to the point more quickly. Our messages to one another stylistically resemble an internal memo rather than a business letter. We also pay specific attention to utilizing concise, descriptive subject lines to further streamline our communication.

Pivotal Tracker

While our implementation of agile methodology deserves it’s own blog post, the main reason that we use it as such a small team is because it’s more than just a method of working – it’s a process of communicating. To facilitate this process digitally, we use Pivotal Tracker. This application has grown to more than a manager of our sprints; it’s become a tool we use to communicate about tasks, projects, and stories. In our use of Pivotal Tracker, we’ve noticed a dramatic decrease in the number of distracting questions/conversations such as “What are you working on?” or “Are we going to add this feature?” because we all have access to this information in real time. This is especially helpful for customer support; Nathan can quickly and easily inform customers what features can be expected in an upcoming release or are in active development. This is the kind of openness we strive to have with our customers.


Collaboration is a major form of communicating. Our Basecamp “Projects” aren’t traditional projects in that they don’t have a start and end point. Rather they’re categories (such as products, themes, etc.) of collaboration. I didn’t fully realize this until writing this post, but we mainly us Basecamp as a method of record keeping. For example, we track our most frequent feature requests as To-Do items. This enables us to document, reorder, discuss, and complete them when we get to them. We also keep track of news and blog posts regarding Mail Pilot and document some of our favorite tweets in one of our projects. In all, we use Basecamp for communication that doesn’t require response or attention in the immediate future. We all know that these items exist in Basecamp and can update them when we think of it and reference them when necessary.


Both developers and non developers at Mindsense utilize GitHub’s Wiki and Issues communication tools. While the general topic of all communication in GitHub is development, it is not limited to technical communication. For example, rather than a more traditional shared spreadsheet for all of our test email accounts, we have a Wiki for this information. Because we track confirmed bugs in Pivotal Tracker, we use GitHub Issues to document, track, and discuss problems before we determine what bug is the root cause. In addition, we track and discuss smaller level improvements via Issues. By handling the actual tracking of confirmed bugs in a separate area, it’s much less scary for anyone on the team to add and discuss a problem in GitHub without wasting time wondering if it’s worthy of creating a report.


I know what you’re thinking. It seems archaic and bizarre to think of the phone as being a main communication tool in a startup, especially one whose flagship product is a digital communication application. However, there are some instances in which a phone call is incredibly beneficial. Most notably, I communicate with Nathan about customer support several times a week via phone. Whether we’re working through a technically complex support ticket, discussing ways to address common questions, or planning a new aspect of our online support portal, I prefer to have these conversations over the phone. With customer support, I’ve learned that the context of each situation is incredibly important, and a quick instant message or email can’t provide as much context as a phone discussion.

We Believe

in Announcements, Work Smarter

Here at Team Mail Pilot, we couldn’t be more excited to be writing our own story. We have many ideas and beliefs about how innovative startups should work. We wanted to somehow put these concepts into writing. In today’s world, all companies are obligated to have a mission statement. Unfortunately, it seems like every corporate PR department shares a single template titled “Generic Mission Statement”. Mission statements have become diluted and redundant.

Thankfully, there is a growing trend among some of the best companies in the world, those who are truly in touch with their core way of life, to have a company credo. A credo is far beyond a mission statement. It becomes a true statement of belief and identity. Those within the company know it, and embrace it. Those outside of the company realize it, customers appreciate it, and fans love it. We believe that a company’s credo should be an intrinsic part of everything that company does.

From our minds, to the white board, to code and customer support, and every step in-between, we’ve grown to recognize the essence of what we do, how we do it, and why we do it. We’ve developed a personality, a methodology, an intuitive sense to how we get things done. We believe everyone should adhere strictly to their values and beliefs, and that in adhering to our values and beliefs, we grow as individuals and as a company. We believe that sharing our credo with the world will change us from a company that is faceless to one that is understood, connected with, enjoyed, and respected.

Here’s our company credo:

I. More Mission

We believe that mission statements should mean more.

  • We believe in fancy words, but we also believe that our mission statement should be more mission and less statement.

II. Pushing Forward

We believe that outdated and poorly thought-out solutions should be turned on their heads.

  • We believe that over-engineered solutions are all too common and that piling more and more complicated features on top of broken systems is simply lazy.

  • We believe in professionalism in the software industry and that forcing an over-relaxed work environment is a counterproductive juxtaposition.

  • We believe in challenging this current state of affairs with more natural and intuitive solutions that are designed intentionally to accomplish well-established goals.
We believe that software should push people forward rather than hold them back.

III. Work Smarter

We believe in creating our own dream jobs and in playing to our strengths.

  • We believe in collaborating and balancing our strengths to form a productive, aware team.
We believe in working on solutions to our own problems, interests, and passions.

  • We believe in our ideas and in standing behind our products for the long-haul and we believe all startups should be fueled by this same passion and not dollar signs.
We believe that innovation and ideation should start from the ground up, ignoring all preconceived notions and solutions.

  • We believe in responding to competition through innovation and not through legal exploitation.

  • We believe in our supporters and our fans—without them believing in us, we wouldn’t be here.
We believe that working smarter does not mean working more.

IV. Organized Chaos

We believe that email should not consume our lives.
We believe that email is not going away and that ignorance is not bliss.
We believe that an email application should focus on getting things done and become a productivity tool that fits naturally with current workflows.

  • We believe there can be organization in the chaos.

V. Get on with your day

We don’t just believe in these things, we act on them.
  • With today’s software, users are often forced to do more work to get less done.
At Mail Pilot, we do more work so you can get more done and get on with your day.

Gone are the days of two-liner mission statements that are meaningless. It takes many words to accurately depict our actions and the thought processes behind them. This credo is our playbook, and it addresses every aspect of everything we do at every stage of our business. It is designed to be fluid, yet consistent. We hope it provides insight into how and why we’re reimagining email to work better for you.


Jobs and Artisans

in Work Smarter

The time couldn’t be more perfect. This is a time when people are starting to think about who they are giving their money to. People want to know who made what they are using, and what their story is. Society is starting to prefer a local option over a large, corporate one. There’s also another big reason why the time couldn’t be more perfect.

“The Great Recession” they call it. Its effects are being felt globally. And even though here in the United States we are no longer in a financial recession as of 2009, you’ll still hear people talking about it. Why? Many people are finding themselves without jobs.

The word “job” showed up in the 16th century as a way to describe a piece of work. It described petty work, and is still defined as such in some dictionaries. People did not have “jobs,” they had a craft; they were artisans. They made things with their craft. They sold their crafted things to each other.

It wasn’t until the industrial revolution that jobs would be known as big companies with large numbers of people working for them. Then a funny thing happened. In 1882, the phrase “on the job” originated, meaning “hard at work.” “Job description” showed up in 1920. Thirty years later, things began to change, when “job security” originated, and in 1972, “job sharing” entered common use. The etymology of the word “job” alone shows a lot about the rapid birth, growth, and recent decline of jobs [1].

Let’s face it: jobs are on the decline. Many people are settling for jobs they dislike, or jobs that pay less than what they deserve. There’s never been a better time to once again embrace being an artisan. It’s time to find your craft. Who knows? Maybe your craft will catch like wildfire, and “jobs” will be a thing of the past to you.

Now seems a better time than any to harness the visionary inside of you; conceptualize, ideate, plan, and execute your idea. What is your craft? What is it you want to make, do, or see actualized in the world? Is it developing software, starting a children’s camp, publishing your own magazine, making your own line of clothing, writing a book, growing your photography business, or something completely different?