Foxbox Digital is an award-winning engineering-focused product development agency.

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

As we grow as a company, we've made the decision to be intentional about everything we do.  Rather than leave the important task of building a culture we can be proud of up to chance, we opted to sit down and think about it. Here's what we came up with for our culture-first employee handbook, which we've dubbed The Foxbox Way.

Creating the Foxbox Way, Our Culture-First Handbook

When I started Foxbox in 2018, I wanted our team to be intentional about everything we do. I didn’t want to leave it up to chance or let the culture have a life of its own. In many ways, the culture of Foxbox is an extension of how I operate.

I needed a way to communicate this to our team and prospective customers. I wanted our outside to match our inside. Meaning, a potential hire or customer should be able to have a consistent experience before and after joining us.

So, there are two things we set out to create.

 Create an employee handbook that dictates exactly what our company culture is, so new hires and existing employees have a frame of reference for how to succeed.

Externally-facing tagline and “core beliefs”

: We wanted to let our customers and the public know how we operate as a company. It’s kind of like giving them an inside look into what it’s like to work with us and what we stand for.

For the purpose of this article, I’m going to talk about how we created our employee handbook. If you want the details of the behind-the-scenes of our tagline, Move Purposely, 

When we started down the journey of creating an employee handbook, we looked for public examples of companies that shared theirs. We looked at Netflix (who was the original inspiration for this), Basecamp, and Tesla.

Basecamp released their handbook around the time we started creating ours, and I thought it was great. It was in-depth and used extremely straightforward, transparent language.

The reason I loved it so much was because there were zero possibilities of an employee “reading between the lines.” The handbook wasn’t a blanket “do the right thing” statement that would mean multiple things to many people. It gave every employee direction on how they should communicate, how they should be working, and how they should be making decisions. It covered everything from A to Z. It’s perfect.

 “Anti-Handbook Handbook,” which I thought was interesting because it wasn’t supposed to be viewed publicly. Of course, Tesla’s handbook is the exact opposite of Basecamp’s in terms of expectations from their employees. But, the one thing they both have in common is their direct language. There was no chance someone could misinterpret what was expected of them, especially how to work and communicate.

Now, on to our handbook, which we call the Foxbox Way.

After analysis, we all agreed that the Foxbox Way needed to accomplish the following:

. We have an organized onboarding process, and this is a perfect part of our new hires’ first day activities.

It should be clear and direct—no fluffy marketing jargon.

It shouldn’t be about how wonderful Foxbox is but focus on the realities of our business. Basically, it should be a real representation of how we work, not a magical unicorn representation.

After that, we went to the races. After many meetings, several edits, and re-writes, here are the 17 core principles we came up with:

The client isn’t always right — challenge them gracefully

Treat every client like you’ll be eating Thanksgiving dinner with them 5 years from now

Client Satisfaction > Our Profits — make decisions accordingly

See an opportunity for us to improve? Take it and own it

There are some meetings you absolutely can’t miss

How you work and communicate with the team is up to you

Each principle was broken out into further clarification. The Foxbox Way serves as a framework for our culture and values at Foxbox Digital. Every single piece of code we write, every interaction we have with our clients, and how we communicate with each other are all part of the Foxbox Way.

 It is unique to us, and that’s why it’s the Foxbox Way.

As planned, we used this document for our onboarding process, and it was received well. Many of the new hires commented that they’ve never been part of a company that was this direct on expectations, and it gave them a much better understanding of how we work.

One note: we view these as a set of guidelines, rather than rules. We respect that everyone has their own individual personality, and these principles are the common thread that ties us together.

We’re only a few months into this, and so far it’s been great: new team members feel instantly connected to the company and we all seem to be working more cohesively.

And yes, this is supposed to be an internal document, but similar to Basecamp, I thought it would be a good idea to make this public for other founders or leaders who are considering being intentional about their culture.

So, if you would like to see our culture handbook in its entirety, 

REASON 1

You Can Create Great Native-Like Experiences Across Multiple Operating Systems

REASON 2

It Focuses on Developer Efficiency Across All the Platforms You Care About

REASON 3

It's Native, Really!

REASON 4

You Can Reload "Instantly" with Fast Refresh and Modern Debugging Tools You Know

REASON 5

It’s Developed by Facebook, but It’s Open-Source

REASON 6

It’s Flexible

REASON 7

It Has a Big and Active Community

REASON 8

Great Companies Are Using It

REASON 9

There Are Great Integrations To Make Your Job Easier

REASON 10

Amazing Resources Are Available Online To Get Started

IN CONCLUSION

React Native Is the Way to Go for Many Reasons

React Native created the ability to produce real Native iOS and Android Apps with a single codebase, and has changed mobile app development in a big way.

We’ve dedicated a lot of time to mastering React Native, and it’s by far our favorite framework of choice when developing mobile apps.

Here are the reasons why we love it, and recommend it so often.

React Native produces real Native iOS and Android Apps with a single codebase, and its changed mobile app development in a big way. This is why we love it.

10 Reasons Why We Love React Native *And Why You Should Too

We believe that in order to make an impact in the world, you must do it purposefully. We believe that having the determination to succeed and willingness to adapt to situations greatly increase the impact of our work. These are our core beliefs.

Our Core Beliefs

We believe that in order to make an impact in the world, you must do it purposefully. We believe that having the determination to succeed and willingness to adapt to situations greatly increase the impact of our work.

We’ve seen too many failed projects that never made the impact that was originally promised, because there was no underlying purpose for the project to begin with, or a misaligned vision for what the product was supposed to accomplish. When you approach everything you do with a purpose and a resilience to succeed no matter the circumstances, you’re able to make a positive impact everywhere you go.

This is why we only invest in talent who are determined to succeed, and partner with clients who are purposeful in their mission. We exist to make an immediate and long-term impact on our clients & those in need.

We relentlessly pursue the truth with a deep focus on solving the problem at hand. We do our diligence and gain a deep understanding of the problem we’re solving before a single piece of code is written. We ask a lot of questions to uncover the real problem and verify the impact of the problem when we solve it.

We measure twice, cut once. Once we start coding and architecting your digital solution, we will already have confidence in our direction. This means no false starts. No over promises and under-delivering. This also means that we take calculated risks if we see an opportunity for further success.

We find our way around, and adapt to every environment we’re thrown into. We’ve had the pleasure of working in every type of business environment (From Large enterprises to scrappy, chaotic bootstrapped startups), and in every situation, we keep our cool and find practical solutions to big problems. We embed ourselves within the client, whether that’s onsite in their offices or within our own confines.

We have a bias for exploration. We will continue to find different ways to solve a problem until we’re confident that there will be little to no side effects. Instead of relying on brute-forcing solutions, we rely on our collective minds to uncover problems and solutions to anything we are working on. Our work is not done until it’s done and made an impact.

We are puzzle solvers, not a code factory.

We have a passion for overcoming challenges. We might spend a little more time upfront to understand what puzzle we’re solving, or how to solve the puzzle, but once we do, we’re filled with joy and fulfillment. Our team is stacked with problem solvers. Yes, we are engineers at heart, but we are more interested in solving the problems and not just writing code.

We structure engagements to allow our entire team to be dedicated to individual projects and focus on making the biggest impact possible. We maintain deep focus in order to get into flow and solve deep problems.

You can read more about who we are and the culture that drives us 

The “Foxbox Way” serves as a framework for our culture and values at Foxbox Digital. Every single piece of code we write, every interaction we have with our clients, and how we communicate with each other are all part of the “Foxbox Way.”

The Foxbox Way

The "Foxbox Way" serves as a framework for our culture and values at Foxbox Digital. Every single piece of code we write, every interaction we have with our clients, and how we communicate with each other are all part of the “Foxbox Way.”

This is not just a guide for new hires but serves anyone who works at Foxbox, including our leadership team and founder. How we hire, the clients we serve, and even how we act outside of the office are all part of the Foxbox Way.

 It is unique to us, and that’s why it’s the "Foxbox Way."

One of Apple’s famous ad campaigns was a campaign called "

." In this short video, they featured icons who changed the world (including Albert Einstein, Amelia Earhart, and Martin Luther King Jr., to name a few) and challenged people to think differently. As part of his 

, Steve Jobs said, “If they ever used a computer, it would have been a Mac.”

A big reason we created the Foxbox Way is to drive clarity on who would make a great Foxbox team member, and who would make a great Foxbox client.

We believe in Moving Purposely. This means everything we do is thought through. It means we value proactive actions versus reactive ones. It means we measure twice and cut once.

At Foxbox Digital, every associate on every project knows that our work is mission-critical to our clients. We take that responsibility seriously, and that shows up in the work we do and how we do it. Sure, we love to engineer solutions but we want to make sure there’s a purpose behind what we’re building, and we’re communicating with the team and client before we start coding away.

We believe that in order to make an impact, you must do it purposely. We’ve seen too many failed projects that never made the originally promised impact because they were trying to solve a hypothetical problem, instead of a real one. Instead of blindly following project requirements, we like to build with a purpose. Solve real problems for people. Release your software early with a minimal feature set then keep building and incorporate what problems actually come up from real users.

When you approach everything you do with a purpose and resilience to succeed no matter the circumstances, you’re able to make a positive impact everywhere you go. This is why we only invest in talent who are determined to succeed, and partner with clients who are purposeful in their mission. We exist to make an immediate and long-term impact on our clients.

Just like the fox (the animal), every step we take is intentional, calculated, and efficient.

We are a hungry group of engineers, entrepreneurs, and leaders who have something to prove.

We’re still a fairly new digital agency, even though we’ve had impressive growth. The drive to bring our clients to a better place is the foundation of success at Foxbox Digital. This means we should operate as if every client’s business is our own.

We’ll challenge every feature, celebrate every win, and stay up all night fixing whatever impedes our client’s future growth. There’s no reason that Foxbox Digital can’t grow to 500 or 5,000 people in the next 5-10 years.

All of our new hires tend to have a mixture of a great technical skillset and be naturally ambitious. We ask that you work like you have something to prove.

If you have a crazy idea on how to solve a problem, try it out. Failing is not just okay, it’s recommended. We’re building software, not performing heart surgery. Communicate your plan with your team and try to validate or invalidate your idea as quickly as possible. If it works, it’s a win for your client, your team, and for you.

As a company, we try new things all the time. We’ll experiment with a new service offering, and if it doesn’t work, we end it with little fanfare. We also experiment and evolve the way we manage projects. Some ideas work, some don’t, but by taking risks we ultimately improve the way we deliver.

Without taking risks, we would not exist. The opportunities that await us are endless, but we do have to pursue them. We’re not a "bet the farm on a single idea" type of company, but we’re not a “let’s sit back and see how this all plays out” type of company either.

We are communicators and translators first, engineers second.

Many of our customers are not technical, and that’s a huge reason why they hire us. They already trust us to get the technical work done. When speaking with our clients, it’s worth talking about what we’re doing technology-wise that will benefit their business.

They most likely will never know what concurrency or pattern matching is. However, they do need to know that the solution was architected to focus on speed and scale. They might not know the inner workings of Scrum or Agile, but they do need to know how we operate our projects.

Use metaphors to help them understand complex technical topics in a simple, relatable way. For example, to explain concurrency to a client, you can say, "We’re increasing the overall speed of the application, and allowing it to handle more transactions without increasing your server costs. That way, if you get a huge increase in users, you won’t need to reprogram it. It’s ready to go from day one. WhatsApp uses concurrency for their platform, and it works well.“

A good trick to explaining technical terms to a non-technical person is to Google <technical term> + benefits. So, DevOps benefits, Concurrency benefits, etc. These results will give you the layman’s terms for any technical thing you’re talking about.

We’re all excited by new technology, but it’s important not to use technology for technology’s sake. Blockchain, Serverless APIs, AR, and Graph Databases are all really cool, interesting pieces of technology, but they’re often not the best or simplest solutions to the problems we need to solve. Focus on the problem you need to solve and think of the simplest, most elegant solution to solve it. Obsess about the problem, but don’t get caught up in all the new shiny technologies.

As a general rule of thumb, we should stick to using the technologies we know and use across all of our projects. If you want to bring in a new major technology, you’ll need to sell your idea to your team and your architect.

Be prepared to explain why it’s so important and why nothing in our existing stack solves the problem. This is how we brought in Typescript and Hooks, but also how we turned down using Redux-Saga in order to stick with Redux Thunk, which works just fine to solve the same problem.

Our clients get excited about solutions. We get excited about problems.

Our clients pay our bills. In fact, the clients are our only way of making money. They have a clear product vision and hire us to build it. This means they tend to say "build this" and honestly expect us to do as they say. Most other agencies will simply build what the clients want, but not us.

Companies hire us to help them achieve goals. Sometimes what the client asks for is not inline with their own goals, and that’s when it’s our job to challenge them.

For example: A client asks to build a feature for a problem they are anticipating. They’re trying to predict the future, and we may just waste our time (and their budget) if we build it for them. Instead of solving this hypothetical problem now, you should propose to release what we have to customers and solve the problem when it actually happens. Chances are, the problem will never occur, and your client will thank you for being more efficient.

A real-life example: On a previous project, the client had designed a complex image recognition component where the app would read pieces of data from a paper form. The problem is there is no standard template, and it would have been inaccurate and unusable. Instead of building what they asked for, we proposed an alternative solution that is less automated but puts the user in control and will be more than 95% accurate. The client loved our proposed approach, thanked us, and asked us to implement it.

Challenge them in a respectful way by communicating "why" and your alternative solution. Remember, we are communicators and problem-solvers first, engineers second. In the end, though, the best we can do is recommend and advise, the client gets the final say.

 is a great book that goes into more detail on this topic.

Here are three points from the book that stand out and are especially relevant for our clients:

Let the other person feel the idea is his or hers.

 People inherently like ideas they come to on their own better than those handed to them on a platter. Ideas can best be carried out by allowing others to think they arrived at it themselves.

Honestly try to see things from the other person's point of view.

 Other people may often be wrong, but we cannot condemn them. We must seek to understand them. Success in dealing with people requires an empathetic grasp of the other person's viewpoint.

Be empathetic with the other person's ideas and desires.

 People are hungering for empathy. They want us to recognize all that they desire and feel. If we can sympathize with others, they will appreciate our side as well and will often come around to our way of thinking.

The job of the leaders is to support and empower the team. Some call this Servant Leadership, where leadership’s job is to serve you as the builders. Project managers provide developers clear requirements. Software architects unblock developers, help design solutions, and communicate the plan to the client to shield developers from attending meetings.

Your architect designs complex technical solutions, but they also need buy-in from their team. However, leaders are often wrong. Your team should always challenge them, and leaders should listen and make changes accordingly. And of course, just like we do with clients, challenge leaders gracefully.

Rob Volk story: At my last company where I was CTO, I presented my technical plan for a complex feature to the team that I spent the previous night designing. An intern on the project had the audacity to speak up during the meeting to challenge my design. He proposed another way to solve the problem, and it was much better. The team agreed with him, and so did I, and we went with his solution. After that meeting, I took him aside and thanked him for having the courage to speak up and challenge the CTO’s vision.

We pride ourselves on building clients for life. This means our goal for an initial engagement is to knock it out of the park, and also build a trusted partnership where we can help them with future engagements. This is a mixture of them telling us what they need, and us uncovering how else we can help them.

The opportunities are endless for us to partner with our clients and build mutual respect. We aim to grow relationships we will value for years to come.

There are going to be times when you have to make an engineering or product decision that will impact the client. For example, your first option will take a lot longer to do, but will greatly benefit the client, and your second option is shorter to do, and the client might not even notice.

In these situations, we ask that you do what is in the client’s best interest, even though that means it’s impacting our profits on the projects. These little decisions add up to make better products and happier clients.

Of course, there are limits to this, and whenever in doubt, reach out to your project lead on the best next steps.

We aren’t foolish to think that we have everything figured out. We know we have blind spots.

Think it’s helpful to discuss new books with the team? Start a book club. Hate the way we report issues on Gitlab? Propose a new solution and trial it out. If you see something broken or see a new opportunity, it means your team probably notices the same. Propose it to the team and own it. If it needs a budget, let Rob know.

Our clients are, of course, always #1. So, as long as what you propose doesn’t take too much time away from your core responsibilities, we will approve it.

We believe that putting client interests first and continually adding value to their businesses ultimately leads to unexpected returns. 

Give away your knowledge. For example, if you have the opportunity to mentor a developer on your client’s team, go for it. Don’t be concerned about teaching your way out of a client. You’ll actually become 

 valuable in your client’s eyes for helping them. 

We also believe in giving graditude to those who help 

 along the way. It feels good to receive gratitude and it actually helps us when we give it.

Whenever you’re given the chance to give first, do it. There’s a wonderful book on this topic called 

However, under no conditions should you risk the quality of what you’re building or detract from your core responsibilities. Stay away from stop-gap solutions as much as possible.

Build it right the first time, even if it means delaying when the feature will be complete.

All meetings are important (if they’re not, please tell us, so we don’t waste your time!). Some meetings, though, you absolutely cannot miss. Here are the two types of meetings we ask you to attend.

 We have a one-hour monthly meeting with the entire team. We don’t often get a chance to meet as a group, and this meeting is a great way to do it.

: We generally operate on a 2 week sprint schedule, and there are recurring meetings within it that must be attended. They may differ depending on what team, but generally speaking, those meetings are Backlog Refinement, Sprint Planning, and Demos. Those meetings are opportunities for you to learn what the goals of the sprint are and to be able to coordinate activities so no team members are blocked. We also use this as an opportunity to show off your best work.

We understand that things come up where you absolutely can’t make a meeting, and in those cases, please let the meeting organizer know as soon as possible. You should confirm your attendance to all meetings, so the team lead can get an accurate understanding of who is attending and who is not.

The number one rule for our team is that we must COMMUNICATE. We do this because it makes us a better team, a better firm, and, ultimately, a better final product.

Being a global and, mostly, remote team means communication is a must. This means both internally AND externally. At no point during a project lifecycle should there be any mystery as to what’s happening, who’s responsible, "Is it done?" “What’s left to do?” “Are we making money on this?” “Are we going to hit the deadline?” Etc.

The Foxbox Way includes open, consistent, bi-directional (that means listening and speaking) communication between all parties. We use a variety of tools to accomplish this (Slack, Zoom, email, text, in-person discussions, weekly meetings, etc.).

You’re encouraged to have and voice opinions—even dissenting ones.

You’re MANDATED to openly and quickly communicate any issues, concerns, problems, or missed deadlines. That means if you know we’re going to miss a deadline, communicate that as early as possible, not at the deadline! People are rather forgiving if they know in advance. Please, no surprises.

Take a peek into how this concept works at Pixar: 

https://hbr.org/2008/09/how-pixar-fosters-collective-creativity

We love Slack. It’s our main method of communicating internally and with our clients. However, we also recognize it’s a huge time sink. We have three main rules when it comes to using Slack (and other communication tools):

You don’t need to respond to Slack messages right away (seriously).

Video calls > phone calls and daily stand-ups > meetings.

Protect your mornings (and evenings) for deep and focused work.

Everyone has their own working style, but for the most part, productivity means doing your best work in times you can fully focus while minimizing distractions as much as possible. Your goal is to achieve deep work in order to accomplish things. If that comes at the expense of not being immediately accessible and responsive—that’s a good thing.

Here’s a more detailed article I wrote about how Slack is ruining productivity

We are not a grow-at-any-cost type of company. We prefer to hire kind, thoughtful team members. Being rude has no place at this company. Honesty is great, but honesty for the sake of hurting someone's feelings won’t be tolerated.

When giving feedback, it is OK to give your honest, truthful feedback. Instead of saying, "I think this thing sucks." It should be, “Have you thought about this?” or “What do you think about this alternative?”

https://hbr.org/2018/11/making-kindness-a-core-tenet-of-your-company

https://thriveglobal.com/stories/value-of-kindness-in-business/

https://www.entrepreneur.com/article/326114

https://www.forbes.com/sites/forbescommunicationscouncil/2017/07/25/why-kindness-matters-in-the-workplace/#550f848570c7

Rob Volk is the founder and CEO of Foxbox Digital. He started his career working as a technology consultant for Avanade, which was a Microsoft + Accenture joint company. He was able to work with a lot of big companies like Pfizer, USPS, and Morgan Stanley, mainly helping them build enterprise applications.

Most of the work done was traditional waterfall-type methodologies, which caused a lot of project issues and delays. How software was built for enterprises was broken, so a big reason Foxbox was created in 2018 was to help organizations build and deploy software with the agility of a startup.

He also had entrepreneurial and technical roots prior to starting this company. He was the CTO of Beyond Diet and implemented technology that scaled to over 350k+ customers, and was the CTO and Co-Founder of Detective (detective.io), a venture-backed intelligence platform that amassed 200k+ users in a short time frame, and was a $1MM ARR business.

Our first major client was Home Chef. This was, and still is, a big deal. Home Chef got acquired by Kroger, and at the time we were working with them, they were #2 on the Inc. 5000 fastest growing companies.

We helped them rebuild their mobile product in React Native for Android and iOS. Their CTO hired Rob to lead the development effort and train their team on React Native. It was a successful launch, and this gave us the confidence to move to bigger companies and projects.

Prologue

First, some history

Chapter 1 What is Elixir?

Chapter 2 Why Elixir Is Better Than Ruby for Your Business

Chapter 3 What’s Right with Ruby

Discord

Pinterest

Bleacher Report

Cars.com

Chapter 4 What Companies Use Elixir?

Chapter 5 The Best Elixir Resources Online

Chapter 6 Where Should I Start?

We’ve been using Elixir for the past 24 months, and I thought it would be a good idea to write down my thoughts on Elixir vs Ruby and why our engineering team decided to stop programming with Ruby altogether and put all of our efforts behind Elixir.

Elixir is designed for programmer happiness. Here is why Elixir is better than Ruby, and why you should choose it as your programming language of choice.

Elixir vs Ruby | How Switching To Elixir Made Our Team Better

Ruby wasn’t always a popular or mainstream language, but it did gain more popularity with the creation of 

Ruby on Rails by David Heinemeier Hansson

 (a fellow Chicago resident) in 2005. We used Rails as our primary web application framework for quite a bit.

When Elixir grew in popularity, we were quickly dazzled by its uncanny resemblance to Ruby, the language we already loved and cared about. The more we learned about Elixir, the more we understood its strength over Ruby and how it could tremendously benefit our business.

Fast-forward to present day, and the Elixir vs Ruby debate has been solved. We have switched completely to Elixir and thought it was one of the most important and best decisions we have made for our business.

The creator of Elixir, José Valim, was actually a Ruby developer himself.

So the first language I became really proficient in, really confident with, was Ruby. What I really liked about Ruby was this ability to explore, because the language is unrestricted and you can try out different things. And it’s very flexible—you can change it in many different ways. That was really what attracted me to Ruby at the time. [

José loved Ruby so much that in the earliest version of Elixir, he experimented with running Ruby in Erlang virtual machine! At the time, he was frustrated with inconsistent behaviors when running Ruby on multi-core machines. Concurrency was a very hard problem to solve in object-oriented programming languages, and José was not the first one to discover this.

However, he realized that in functional programming languages such as Erlang, the problem doesn’t even exist in the first place. This sort of lateral thinking opened up the path to solving many kinds of issues inherent with Ruby, such as background processing, long-running tasks, and process monitoring; while also incorporating the strengths and features from other programming languages such as Clojure, Haskell, and Python.

You can find a solution to the problem, but if you can make the problem disappear altogether, then, yeah, I’ll take that.

Most importantly, Elixir was designed with programmer happiness in mind, stealing Ruby’s main selling point. Elixir is growing as a mature language and should be acceptable for a demanding Ruby programmer.

Here is why I think Elixir is better than Ruby, and why you should choose Elixir as your primary programming language of choice. But first, let’s talk about what Elixir is exactly.

Chapter 2: Why Elixir Is Better Than Ruby for Your Business

Chapter 5: The Best Elixir Resources Online

Elixir is a functional, concurrent, general-purpose programming language that runs on the 

Inside the Box

Articles, updates, and ideas you can put to use.

Creating the Foxbox Way, Our Culture-First Handbook

10 Reasons Why We Love React Native *And Why You Should Too

Our Core Beliefs

The Foxbox Way

How Switching From Ruby to Elixir Made Our Team Happier and More Productive

Foxbox Digital 2019 Year-In-Recap (the Good and the Bad)