Versapay: Digital Payments Mobile Strategy

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.

the foxbox way

1 post tagged with “the foxbox way”

The Foxbox Way