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

Inside the Box Foxbox Digital Blog

Versapay: Digital Payments Mobile Strategy

The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches, so agile transformations are key. However, knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore time-tested agile principles that will help your organization build innovative products that customers love.

How to Nail Agile Collaboration and Build Better Products

Agile, as a modern framework and approach to developing software, has evolved significantly over the last couple of decades. Today, 

 means producing quality software in short, fast increments, also known as continuous delivery.

The rapid rate of technological change is forcing enterprises to reinvent themselves and provide more flexible approaches to addressing the needs of consumers and individual business units. This is precisely why agile adoptions and transformations are key. Business today is different than just three years ago, and organizations must be quick on their feet to keep up with the competition, or they simply won’t survive.

Knowing that agile is important is one thing, but the ability to properly implement the main principles, tools, and techniques of agile is another. Let’s explore several time-tested agile principles that, if properly implemented, will help your organization build innovative products that customers love.

Don’t Move Forward without Total Agile Buy-In

In order for agile to work, everyone in the organization who will make that transition needs to buy in. It’s that simple!

Now, it is obviously difficult to switch a team—especially one used to waterfall approaches—to agile overnight. It doesn’t work that way. However, a good way to onboard agile into an enterprise is to start with one product team and build consensus on the team through meetings, brainstorming sessions, and actual Scrum adoption in order to generate total agile buy-in within that team.

This means bringing all of your team members together—the UX team, the product owners, developers, and IT operations— and getting them out of their silos and introduced to agile.

It’s important to note that the entire organization doesn’t need to be agile to succeed. A prime example is BMW. It's not that you must roll out agile across the entire enterprise to succeed, it's that you need to roll it out within a complete business unit to be successful. While BMW's mechanical engineering side is unchanged, its software development side is totally agile, and they do not function at odds.

When You Know You’ve Nailed Agile Collaboration

There are a number of core principles and qualities that constitute a true agile project.

People over process and features over systems

The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Putting people first means frequent and transparent communication to ensure that customer needs are being met at each stage of the development cycle. If the process or the tools drive development, the team is less responsive to change and less likely to meet those needs.

Within the Agile Manifesto, there are 12 key principles that characterize how agile works. Of those, three focus on the importance of collaboration:

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

In Scrum, we manage change in two-week cycles with whatever is being built set in stone, but what's happening next is constantly in flux until we commit to the work. This is reflected in the second underlying principle of the Agile Manifesto: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

No system is ever treated statically. In fact, you must work under the assumption that people, markets, demands, and everything related to the development cycle are in constant flux.

Iterative approach to product development and testing

Agile collaboration means that software development takes place in smaller segments, so that feature code is designed, developed, and tested in repeated cycles. This is undertaken through regular team sprints that produce working code, which can be regularly showcased to the customer.

The 10th principle behind the Agile Manifesto says, “Simplicity—the art of maximizing the amount of work not done—is essential.” This is probably the least understood principle but the one with the biggest implications.

The idea here is for development teams to focus on the “why” and then work backward to solve the customer problem. It’s the Pareto Principle, or 80/20 rule, in action: You have to ask yourself what 20% of the effort will yield your team 80% of the results.

There are numerous flavors and approaches to agile and how to structure a team, but one of the most well-known examples is a Scrum team. A Scrum team is a cross-functional group, usually between five and 10 people, who have the skills, talent, and ability to define, build, and test a customer-friendly software solution.

My company has adopted the “Scrumban” methodology, a hybrid of kanban and Scrum, in order to support our needs as an agency and help us succeed in product development. For it to work for us, we use these three roles:

The agile project manager is the facilitator of the agile development team and responsible for helping the team get the resources they need to reach their deliverables on time. This leader protects the team from problems and distractions and works with the product owner to ensure the development process is on track.

In addition to the classic ScrumMaster responsibilities, the agile project manager is involved at least peripherally in the decisions around the product and is empowered to provide lower-level product support, such as clarification on the details, or to make a quick decision on a feature, should the product manager not be available.

The product manager is in many ways the voice of the customer, and is ultimately responsible for the vision and definition of the product. The product manager ensures that the agile team works on the right features at the right time. This individual must liaison closely between the development team and customers to ensure a clear and deep understanding of what product features are needed in the application.

In addition to the classic product owner responsibilities, the product manager also helps the client understand our process and how to be a part of it, so they can take a larger role in development and be more involved with the creation of the product.

The development team is a cross-functional group of members with the skills to build, test, and deliver digital products that customers and stakeholders love. That might include business analysts, user experience designers, developers of all stripes, and more.

The Scrum team is self-organizing and empowered by the organization to manage their own workflows. At the end of the day, it’s not just about coding, but working together to build an innovative product that is successfully tested and deployed.

Avoid These Roadblocks to Agile Collaboration

Many complex factors go into the success of an agile project. There is no magic formula you can point to and say, “This is the solution.” It’s easier to identify the roadblocks to an agile transformation.

With that said, there are many things frequently causing companies to trip over themselves when attempting an agile transformation. Here are my top four roadblocks for agile collaboration that frequently happen.

To work effectively, agile requires total buy-in throughout the organization. We’ve already discussed this point at some length above. But total buy-in also reflects a major cultural shift in the way an organization works, thinks, solves business problems, and delivers solutions.

Agile is a cultural transformation for any organization, and it’s easier if it starts with the executive leadership, but it’s not unheard of for organizations to start a transition to agile within a team and then gain support up the chain.

Developing a product just because it’s cool is not going to drive it through to successful delivery. From its start, an agile project must reflect the organization’s overall mission, vision, values, and goals, and those elements must be reflected in the actual work being done.

If there’s not a continual effort to organize the product roadmap into a series of incremental builds that are prioritized in a strategic manner, then the project will fail.

The success of an agile project really depends on the team’s synergy and their ability to work together proactively with passion to see the project through to completion. Coding skills are important, but they are not everything. It’s a given that your team will have coding and DevOps chops. But onboarding a team of strangers who don’t know the strengths and weaknesses of their colleagues, have never worked in an agile environment, or are stuck in a legacy mindset, are all recipes for disaster.

One of the fastest ways to fail at agile is to take a “mix and match” approach by trying to blend agile with waterfall under the wrong circumstances. It's not a matter of which methodology is better, but rather knowing when and where to use what.

Waterfall makes sense as a methodology in situations where you have a well-defined process to create a product, and you have “known unknowns.” It allows for the process to be optimized based on foreseeable issues, such as in manufacturing.

On the other hand, agile should be used when there is a lot of complexity, you have a lot of “unknown unknowns,” and the issues are not foreseeable. Agile uses the inspect-and-adapt method to account for those unknowns, allowing a team to react quickly and readily to shifts and changes in the marketplace and how the product needs to evolve.

Many enterprises are undertaking massive transformations to deliver faster and keep up with customer demands, but when this fails, it often can be traced to their inability to properly implement agile methodologies. By fostering a collaborative culture, encouraging the principles that support a true agile project, and being aware of the primary roadblocks to agile ways of working, you can set your teams up for success.

Foxbox Founder & CEO Rob Volk Sits down with Fanni Karolina Tóth, host of the Level-Up Engineering podcast to discuss how you can write a meaningful, useful culture document for your team.  

Rob Volk on Level Up Engineering Podcast

Hiring great people lays the foundation for a solid company culture, but when it comes time to scale your team, it's important to codify what's important to you so you don't lose what's you've already cultivated during growth.

Foxbox CEO Rob Volk sat down with Fanni Karolina Tóth on Coding Sans's Level Up Engineering podcast to discuss The Foxbox Way, our culture document we published earlier this year.

Give it a listen below and tell us what you think! What do you think growing companies should do to preserve their culture as they scale, especially when it comes to the challenging of hiring engineers?

Rob Volk on Level Up Engineering Podcast: How to Create a Culture Document

There isn't a single business operating today that hasn't felt the effects of changes from COVID-19.  Here's what's happened since December 2019, both good and bad (but mostly good.)

Foxbox Digital Q1 2020 Update: Culture & COVID-19

This is the quarter that changed everything.

Foxbox Digital started the year on a high from the success of 2019. We grew our team and invested in our culture. We created a culture book called The Foxbox Way with the goal of maintaining and strengthening our culture as we scale the business.

We created a tagline for Foxbox Digital, 

. We did some soul searching and tried to sum up who we are in two words (what do you think?)

Then COVID-19 hit the US hard and everything changed.

It impacted us, and I had to take necessary, stress-inducing action. The end result is that we are surviving through this. I'm sharing everything that happened with complete transparency, and I'm sharing what I learned as a leader (and the mistakes I made to learn that lesson).

I know many companies go on for years without ever creating a tagline, and in many cases, a tagline isn’t created until the company is very successful and popular. But I wanted to create one to communicate what stands us apart and to give our prospective customers and potential hires an idea of what it’s like to work with us.

I didn’t want to be just a software development agency. The world doesn’t need another company that can build software. So the biggest reason was to differentiate us and communicate our value proposition.

When I started Foxbox Digital 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 Digital 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.

I have to say that I’m really happy with how it turned out. If you want to see our new company handbook, read 

, and if you want a behind-the-scenes look into how we created the handbook, check out 

We published some blog posts we’re proud of

When we write content, we take it seriously and put a lot of thought and work into it. An average blog post can take us a month to write, edit, and publish. The time it takes could be shortened if we didn’t have anything else to do, but for the most part, we make sure to get it right.

Here are three blog posts we’re proud of:

How We Onboard Our Remote Engineering and Product Management Team

 — We actually had this planned to publish before COVID-19 came into our lives. I think we do a really good job at remote work. If you’re interested in this, check it out.

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

 — React Native is the foundation of this company. We do plan on expanding outside of just React Native, but we thought this would be relevant for anyone considering building software.

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

 — Another great, technical article on why we enjoy using Elixir.

COVID-19 and the impact on Foxbox Digital

On Wednesday, March 18th, I sent a company-wide email about the impact of the pandemic on Foxbox Digital. I was cautiously optimistic: we were in a good place relative to other digital agencies, and definitely as compared to other businesses in general. And it’s also worth mentioning that new information was coming in every hour. Although there still is uncertainty at the current moment, nothing compares to March 18th.

From a logistical perspective, working from home was an easy transition and required basically no ramp up period. We’re a remote-first company, and so in early March with one days’ notice, I asked everyone to work from home. Someone came in sick to the office and I made the executive decision right then and there! We will continue to work remote until it’s safe for us to return to our offices.

Seeing the early effects of COVID-19 on the economy, I expected that it would be difficult to close new clients, and some current clients would either scale back or pay later, but I also thought that we would be able to close more clients than we actually did.

One advisor suggested I “flex every variable cost I could.” So I made the decision to cut marketing and recruiting. I cut my own pay in half, too.

But, as it turns out, I was too optimistic. The pandemic, and its aftershocks, got much worse here in the US and it impacted Foxbox Digital more than I thought. Like many other small businesses, I’m still waiting in line for the SBA Paycheck Protection Program, and for Congress to replenish the funds. And, because of my previously optimistic tone, I also caught my team off guard as the situation worsened.

What’s happened in the last month? We had clients scale down or pause development entirely. We also didn’t close some new clients that I had expected we would.

With that in mind, here’s what I said to my team on our monthly Town Hall:

 The truth is that we don’t know how long this will last. It’s affecting everyone: our current clients and our future clients.

In order to get through this, I’ve had to ask some of my team to make sacrifices. It was an incredibly difficult decision, one that gave me stomach pains for a week. As difficult as it is, it allows Foxbox Digital to live on. We’ve had to let one team member go, and had to ask several to go on furlough. One of our developers volunteered to scale back to half-time in order to be with his family, which was helpful for our company.

I can’t control what happens next. As you’ve seen, things are changing every day with this pandemic. I can't promise that we won't ask some of you to furlough again in the future.

What I can promise you is that I value every single one of you tremendously, and furloughing anyone is the last thing I want to do. I've already put this business at risk trying to make it work by trying to keep everyone. Most companies let people go a month ago.

What I need from you is to simply keep delivering for our clients. I know this is stressful, but what we need to do is focus on our work and that’s what you have control over.

This is difficult but if we come together and do what's needed, we will not only survive, but we'll come through this pandemic stronger than before.

What I’ve learned through all this is when we’re navigating uncertain times, the message I deliver to my team needs to be realistic. I put an optimistic spin on my first message to my team. My goal was to put everyone at ease, and it backfired.

The interesting thing is that as compared to my super realistic second message, the first message actually made my team more nervous! They were all scared after I told everyone that the business, and the employees, were going to be okay. I’m sure they looked around and saw every other business laying people off and thought, something isn’t right. I had to hold an AMA (Ask Me Anything) a few days later to answer questions.

But, after I delivered my second message, this time over Zoom, my team saw that I took action and I did the things that needed to be done. I couldn’t promise they’d be safe and I acknowledged that I didn’t know what the future would bring. That was real, and they saw that.

When I ended my speech and opened up to questions, an interesting thing happened -- we started joking and everyone’s spirits lifted. We talked about our own experiences in social isolation, and what we had been doing to pass the time after signing off each day.

My rallying call worked. My goal was to tell it how it is, and encourage everyone to step up and deliver for our clients. Let’s focus on the things that are in our control, and not worry so much about the things that aren’t.

I’ve learned a lot through this experience about how to lead when things aren’t easy. I’m incredibly grateful and proud of my team throughout all of this. They have been positive throughout the entire experience, and they continue to push through, even with all of the stress and uncertainty.

I wish for everyone to be safe, and if there is anything I can do to help, please let me know. I know there are many businesses worse off than we are, and some have been completely destroyed, but we are all in this together as a community.

Stay positive, and stay safe, and as always, feel free to 

We used to onboard our new team members the same way as other organizations. Now, we dedicate nearly a full week for onboarding, where every single hour of the day is scheduled and planned towards training. The result of this effort was honestly unbelievable.

We used to onboard our new team members the same way as other organizations. We made sure they got their laptop, set up their email, had badge access, talked about benefits, etc. That took about half a day, and the rest was meeting with their team, then they were on their own.

Now, we dedicate nearly a full week for onboarding, where every single hour of the day is scheduled and planned towards training. Instead of throwing our team right into work, we invest in their training. The result of this effort was honestly unbelievable.

The short-term impact was immediately noticeable. Every new team member was ready to go on the fifth day. They had fewer questions and made a bigger impact on project work faster. The longer-term impact was even more substantial. We’ve noticed a stark difference in our team members that were onboarded our old way vs. the new way.

What’s interesting is that at the end of the training, our employees will usually remark about how amazing the onboarding was and how they had little to no onboarding at previous companies.

Here are two quotes that stand out from our new hires who just finished onboarding.

"Honestly, I loved the mix between docs, recorded sessions and meetings. It was great to meet the CEO and have a chance to talk with him about our core beliefs."

"The onboarding was a lot different than my last company, and that’s a good thing. It was great to get a real picture of what we’re building, and the team behind it. I really appreciated how organized and structured the process was from start to finish."

Yes, a little humblebrag there, but I really believe that being intentional about onboarding is the core of our growth.

So, at a high-level, here are our principles.

Every hour of the day should be planned and scheduled before the new hire joins

This means that by the time they open their email for the first time, their calendar is already full.

In this schedule, we cover the following topics:

Workspace logistics and operations onboarding (where most onboarding starts and stops)

 — Provide access to all the tools they’ll be using for communication, productivity, project management, etc. It’s also important that our team sets this up prior to them visiting. All they have to do is log in.

Get to know the culture of the company, and ask questions

 — This is why we created the "Foxbox Way," which is our culture handbook. It details exactly what the culture of our company is. We give them this document and give them a dedicated time on the calendar to discuss what questions they have about our culture and how we operate.

Project management/product management works (video)

 — We run a tight ship on our projects. We don’t like to leave anything up to guessing, and we give each new hire a detailed view on how we manage projects and deliver software, and what we expect from them. We provide them with a pre-recorded video about how it works. We find a video works great in situations where details don’t change much. It makes sure we don’t miss anything in a live onboarding.

 — Every new hire gets a buddy they can ask questions to. Not entirely a novel idea, but we’ve found by actually telling them, "This is your buddy," instead of, “Ask anyone a question, we’re a lovely group of people,” new hires are more likely to speak up and get their questions answered.

 — Facebook used to have a policy where new engineers would make a code commit to their public website on the first day. This allowed their engineers to get familiar with the coding environment, and also make them feel like part of the team on day one. We have a similar concept with our “core app” that is internal to us. We introduce them to the app and have them work on a planned backlog of new features.

Coding standards/pair programming sessions

 — For our engineers, we walk them through our defined coding standards, and also schedule a single pair programming session with one of our developers to get familiar on how we do things.

We used to assume that if our developers worked in an Agile environment, that they were familiar with point estimation, sprint planning, and retros. They usually were, but they weren’t familiar with how we do it, which is the most important.

So, when we put together the calendar, we try not to make any assumptions on their exact knowledge. If we assume, then the new hire might be too afraid to ask simple questions and reveal their lack of knowledge on a topic that everyone assumed they know.

We solve this by putting it on the calendar and "re-training" them on the core of how it works. It’s quick but super effective.

The Culture Handbook is the core of onboarding

A big reason we invested a lot of time in our culture handbook, "

," is because we didn’t want our new hires to guess what our culture is like.

They should know exactly how we communicate, how we talk to our clients, and how we work. They should know the story of how the company was founded and how they fit into our story. Instead of explaining this in a one-on-one meeting, we define everything in a document, and it’s the second meeting of the first day for a new hire.

We schedule the meetings so they get exposure to different team members.

Our CEO, Rob Volk presents the Foxbox Way.

Our Head of Product Management presents the PM onboarding process

And our VP of Engineering presents the engineering onboarding meeting. We also schedule follow-ups with them every day to see how they are feeling. Even though this isn’t necessarily on the calendar, we make sure that we answer any questions during the on-boarding directly.

This process alone has made our team members more productive and effective. I highly recommend that your team creates one as well. Don’t leave your culture up for guessing.

Every person gets a personalized schedule

If they are an engineer, they get the engineering onboarding. If they’re a PM, they get the PM onboarding.

I would estimate that 50% of onboarding is the same across the board, but we make sure the other 50% is unique to their role.

Also, the actual number of days of training depends on the role. Engineers tend to have the longest on-boarding since there are many tools and processes that they need to be familiar with.

But, what we also do is make sure we personalize it to them as well. Even if we hire two engineers with the same background and some role, we will incorporate special meetings we think they could add value to. For example, we had one engineer who likes to write blogs, so we connected him with our marketing team during onboarding to make him feel comfortable pitching blog posts he wants to write or needs assistance in writing.

In Notion, we create a general onboarding document for each role type, but we also create a new onboarding document for each person. That will dictate the calendar invites being sent out.

The question "Have you met Kelsey yet?" should mostly never happen

With our old onboarding process, which was essentially HR/Logistics onboarding, new hires would often only meet people that were on their project. This ultimately meant they didn’t meet a lot of people on our team who were potentially useful resources for them.

So, in some situations, our engineers would have a challenge that they struggled with and didn’t know there was someone in the company who’d already solved that same problem before. This sometimes led to weeks of productivity losses before someone stepped in and said, "Have you met Kelsey yet? She could solve this problem for you in minutes."

During onboarding, we show them our organizational chart, and the breakdown of members per project, even the projects not relevant to them.

One of the main comments with the developers during our 1:1’s is that they are not aware of what is happening on other projects, and so our hope is that by showing them early what everyone else is working on, it will give them more context of where they can be helpful.

We do this to show them where they fit within the organization, but how the rest of the company is laid out. During our monthly town hall meeting, we also make sure that we present our newcomers, and announce them on our #general slack channel.

By being intentional about our onboarding process and scheduling meetings beforehand, we introduced new hires to anyone that had a direct impact on their role, and resources they most likely will need down the road. By setting up a video call with the relevant resources during onboarding week, they were able to establish an early connection.

We recently moved to Notion for our "wiki"-style knowledge base and are absolutely in love with it. Notion is one of the first things we give our new hires access to. It’s a massive upgrade from our ad-hoc Google Docs storing of documents.

The biggest benefit of using Notion is that it’s really easy to find things and link to other documents we’re working on. With the navigation on the left, the new hire gets a complete picture of their onboarding and other things they should be looking at.

They can look at notes from previous town hall meetings, status meetings, etc., right away.

For onboarding, we like to list out each activity per day, as the screenshot shows. Bullet points work great, and we link to any documents or media relevant to their onboarding process. This way, the new hire knows exactly what they need to be doing, with little to no help from our team.

No extra work during onboarding until they "graduate"

We are very careful not to assign them project work, even if the project is waiting for them. We’ve made that mistake in the past, and it’s never turned out to be a good idea. We take our time with onboarding because we know the impact is worth it.

So, if you’re going to create an onboarding process, it makes a lot of sense to protect their time and not overload them with client or project work. Let them onboard, and then put them to work.

The week long onboarding process might seem excessive, but it works phenomenally well

I don’t think we’ll ever look back from this process.

Now that I’ve seen the short-term impacts on employee happiness and the long-term impact on productivity, this onboarding is one of the best decisions we’ve made.

We had two cultural goals we assigned to ourselves this year.  Choosing a tagline that reflects who we are as a company that reflects why we do what we do was one of them.  Here's a peek into how we did it.

How We Chose "Move Purposely" As Our Tagline

This is part two of our culture series, where we give you a behind-the-scenes look at how we’re building our culture and brand.

 of this series, there are two things we set out to create towards the end of 2019:

: An employee handbook that explains our company culture, so new hires and existing employees have a frame of reference for how to succeed. You can read it and download our company handbook at this link.

An externally-facing marketing tagline and what our “core beliefs” are

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

We actually started by creating the company handbook before the tagline. We thought creating the handbook was more straightforward, and that turned out to be correct.

Here’s the process of creating our tagline and core beliefs.

Our new tagline is Move Purposely, and it is accompanied by our core beliefs, which you can find in the next section.

I know many companies go on for years without ever creating a tagline, and in many cases, a tagline isn’t created until the company is very successful and popular. But I wanted to create a tagline to communicate what stands us apart and to give our prospective customers and potential hires an idea of what it’s like to work with us.

What’s the point of documenting our core beliefs?

Core beliefs are statements that describe “what your company believes in.” In a world where most companies talk about 

 we do things the way we do them. We recognize that the work we do is somewhat commoditized. There are thousands of other companies who could claim to do the same work as us.

But our secret sauce, the core of what we do, the reason why we outperform many other agencies, is our why. And we wanted to communicate that internally and externally.

We also knew our why would fuel the creation of our tagline, so we started with creating our core beliefs before our tagline.

We relentlessly pursue the truth with a deep focus on solving the problem at hand. We do our due 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 cut once, measure twice. Once we start coding and architecting a digital solution, we will already have confidence in our direction. This means no false starts and no over-promising and under-delivering. This also means we take calculated risks if we see an opportunity for further success.

We have a bias for exploration. We will continue to find different ways to solve a problem until we’re confident 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. Our work is not done until it has made an impact.

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

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.

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.

Yes, we are engineers at heart, but we are more interested in solving problems instead of just writing code.

Now, the tagline. Here are the steps we took to create our tagline, Move Purposely.

I feel like every tagline creation process starts with a Google search. And, of course, you end up evaluating the most famous ones like Nike’s “Just Do it” and Apple’s “Think Different.” These taglines have stood the test of time.

But we aren’t a billion-dollar company, so we went back and forth on what our tagline should encompass.

It has to represent who we actually are as a firm

: If the tagline sounds great but doesn’t deeply represent us, then we have to pass on it. I’ve seen too many companies with mission statements and taglines that they don’t actually live by or stand by. I wanted our tagline to have meaning and depth. I didn’t want it to be a token marketing ploy.

It should be unique, memorable, and ideally two words

: I’ve seen some longer taglines, but I’ve always been a big fan of shorter ones. The more words in a tagline, the less memorable it would be, in my opinion.

It shouldn’t be specific to the technologies we work with:

 Although a majority of our work is specific to React Native, we’ll grow to work with a variety of technologies. And I wanted our team to think bigger than just a specific technology, or even technology in general.

It’s something we stick with for at least five years:

 We wanted to create a tagline that would last a long time, if not forever, even though our company is only a few years old and creating a tagline might be jumping the shark. This rule ended up being the biggest constraint for us.

We also didn’t want to start with what we do, but instead with our why. Why we do what we do?

 Are our differentiators really that distinct from everyone else? “We do things better” isn’t a tagline or a differentiator.

How much of the company culture is derived from me, the founder and CEO?

 We also considered the personality attributes related to how I lead the company.

What are the attributes of a fox, and is there any relation to our name Foxbox Digital?

 Well, if you ever wanted to know why we named the company Foxbox, you’re not going to be too impressed. I wanted a name that hints at what we do without being obvious. There are beautiful, cunning foxes on my favorite ski mountain, and they stood out to me. We build things, and so a box represents what we build. We had to add “Digital” for SEO, and because it says that we’re a digital agency. That’s the truth!

When we were evaluating our tagline and core beliefs, we started to see if there were any attributes from a fox, the animal. This turned out to be 

Here is an excerpt I found online about the 

Flamboyance is not the fox's style; it prefers to remain inconspicuous in a small, cozy house, which is usually organized and neat. Choosing subtlety and cunning over brute strength, they are unquestionably hunter personalities and are usually in good physical shape and perform well in pastimes that challenge both mind and body.

Largely misunderstood to be a shy, retreating individual, it's the fox's stature as a small carnivore that defines its survival strategy. Because it cannot succeed using brute force alone, the fox must rely on its sharp mind and engaging personality to garner resources.

Inside the Box

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