Tools Are Not Solutions
Why you should let *who* you are and *why* you do things define your business
It’s late summer 2015, and a bunch of ecommerce agency C-suite professionals are sitting around an outdoor conference room at a remote resort in Austin, Texas.
Everyone’s there because we all share an abundance mindset.
We all know that the 850,452 things we’re all worried about that could bring down our businesses are entirely within our own control — and that sharing a bit about what we know with other agencies, in confidence, can only help us all.
So, after sharing war stories about how and why we have master service agreements, how we establish payment terms, what our proposals look like, how we onboard clients, how we fire clients, what our EBITDA is and why it’s not what we want it to be, what our goals are, etc., etc., etc., inevitably, questions about tooling come up.
“How do you guys track time?” “How do you track projects and tasks?” “How do you share deliverables with clients?”
…and that’s all well and good.
I answered those questions that day last year, and I’ll answer them again today.
So, what is Rocket Code’s tooling?
Tracking time? We used Harvest. Then we used Everhour. Then some of us switched to Toggl. Now, honestly, I don’t care what my team uses.
Tracking projects and tasks? We used Trello. Then Flow. Then Asana. Then back to Trello. And now, it’s a combination of Trello for roadmapping, and Jira for task management.
Sharing deliverables with clients? Dropbox links and well-planned phone, Skype, or in-person presentations.
But here’s the thing — none of that fucking matters.
And more than that, I challenge the premise of the question altogether.
It’s not about the tools. Ever. And all of those things? They’re just tools.
And so here’s the alternative that I’d like to propose. First, accept that no tool is ever going to solve a problem in your business. Intent, communication, expectations management, and process (yes, that dirty word… process) are going to solve your problems—not ever the tools you choose.
If you let what you do and how you do it define your business, you’re just some company that does some thing, and there are plenty of other businesses like you.
Now that you’ve accepted that premise, here are the questions you need to ask yourself:
1 — What is the behavior that I want? Presumably, you either want your team to start a behavior or to stop a behavior. (You might also want them to continue a behavior… but if you want that, you might already understand that role that tools play, and you can stop reading right now.)
2 — How am I going to get there? This question is really about change management. If you’re going to ask your team to do something differently, they’re going to be asking themselves a few questions: What is changing? How does it affect me? When does it take place? Why is it happening? Be prepared to answer those questions, understanding that your team doesn’t understand where your head’s at by default. It’s your job to close that gap, and answering these questions can help.
3 — Why is this important? I think you’d be surprised how few owners can answer this question — or at least answer it well. To help you answer this question the right way, here are a couple of prompts:
If we do [insert thing] well, how can it make our business better? How can it make our team’s lives better?
If we do NOT do [insert thing] well, how will it hurt the business? How will it make our team’s lives worse?
If you can frame up the questions that way, you’ll be set.
Now, once you’ve answered those questions for yourself, might I suggest that you share them in reverse order with your team. As Simon Sinek would say, start with Why. Here’s what your team will want to know:
1. What are we doing?
2. Why are we doing it?
3. How is it going to affect me?
Got it? Good.
And now, I’ll give my answers to those questions that were asked way back when in Austin, Texas—but following this framework.
“Time tracking—what do you use?”
Why?
At Rocket Code, time is important because it’s all we have and it’s all we sell. And time tracking is important because it helps us understand how efficient we are with our time, and whether we can get more efficient internally, or whether we need to hire more people.
Some additional context: Our planning isn’t dependent on time tracking, but our reconciliation at the end? That is. There are only two ways to get more work done: increase the quality of our time (get more efficient), or increase the allotment of time we have available (hire more people). Without a handle on the efficiency of our time, I don’t know whether I should expect my team to get more efficient (i.e., we all make more money, our costs don’t go up, our clients are happier, the business is more successful, we’re more profitable, we can compensate our team more with salaries, bonuses, perks, incentives, etc.). And, when you hire someone, you’re invariably injecting a certain amount of chaos into a system. I suggest that the system be pretty buttoned up in an effort to minimize said chaos.
How?
At the end of the day, we don’t care. We don’t want to introduce friction into our system… but it’s also not pure anarchy. Teams within Rocket Code (business ops, design, and engineering) can all make their own decisions about time tracking. The only requirement is that it happens, and that we have access to it.
What?
We need everyone to track their time.
“Project management—what do you use?”
Why?
At Rocket Code, time is important because it’s all we have and it’s all we sell. (Sound familiar?) Our model is extremely transparent. So, in order to sell our time, we have to show our clients, proactively, exactly what we plan to do with it. We do this via “roadmaps,” and it’s part of our governance process.
After we have buy-in from the clients, the time we’ve sold becomes time that we have to execute on. We do this via “sprint boards,” and it’s part of our execution model.
Together, these things comprise our systems development lifecycle (SDLC).
Trello is what we use for roadmapping, because it fits our SDLC, because it’s easy to share with our clients, and because it holds us directionally accountable. We use Jira to get the work done in sprints, because it provides clear traceability back to the roadmaps, and because it helps our team get more work done better and faster with less overhead than some of the things we’ve tried before.
How?
We’re always planning four weeks ahead with our clients, and in two-week sprints. Thus, our conventions are as follows:
- Trello “Boards” are our roadmaps. One exists for each client.
- Trello “Lists” are our sprints. We’re always planning at least two sprints/four weeks ahead.
- Trello “Cards” are our epics. We assign amounts of effort (that we call “t-shirt sizes”) to these epics, and that’s how we book capacity for our sprints.
- Jira “Epics” are exactly our Trello cards. Perfectly and precisely. That’s our traceability between the two systems.
- Jira “Tasks,” “User Stories,” and “Bugs” are our requirements against which work is completed. Generally, these things all roll up into our epics.
What?
We need to effectively track our client accounts and their projects.
“Sharing deliverables with clients—how do you do it?”
Why?
If you work at an agency, you’ve almost certainly sent some (more thoughtful) derivative of this email:
Hi [important client],
We just finished the homepage concept. You can find a preview of it here: [file url]. We love it, and hope you do too. Take a look at it and let us know what you think!
[Salutation],
[Your name]
I can tell you right now, that’s not a good communication. Here’s why I say that. I’ve found, as I’m sure we all have, the more important the communication, the richer the fidelity of that communication best be. You wouldn’t break up with your significant other over text (I hope), you wouldn’t fire someone via email, and you absolutely shouldn’t be delivering important work via email.
Our general coaching is, if something can be taken the wrong way, or if you need to curate/craft the delivery, then escalate your communication — in tone, in medium, and in redundancy.
So, back to the point — client delivery.
We’re in ecommerce. When we’re delivering work, we’re taking something our client has—something that works, and works well, and we’re saying, “We think you should change this.” In order to communicate that, we require a presentation. We’ll never deliver a design without at least a phone call. Better than a phone call is a screen share. And better than a screen share is an in-person meeting. How you deliver your work can be the determining factor of its success or failure.
How?
- Set expectations: Schedule time with your client to present your work. Let them know what you’ll be delivering, what you need from them, and who you need present on their side.
- Build in extra time: Murphy’s Law says something like, “Whatever can go wrong, will go wrong.” Give yourself time to review the work internally. Get everything and everyone on the same page.
- Prepare: Run through the work and make sure you know what’s important to present. Simple enough.
- Control everything that can be controlled: If you’re sharing something in person, walk the client through it. Even let them know when to turn pages. If you’re presenting virtually, share your screen. Don’t deliver the work into the clients’ hands until afterward. It’s your show; run it.
- Follow up/deliver: Your client is your champion within their walls. Equip them with everything you think they need to get proper buy-in.
What?
We need to share deliverables with clients.
So, Rocket Code’s tooling is as follows:
- Slack for internal communication (we don’t send internal emails)
- Dropbox as a master file repository.
- Droplr for easy filesharing.
- Bitly for URL shortening.
- Toggl for some of our team’s time tracking.
- Everhour for some more of our team’s time tracking.
- Trello for governance and roadmapping.
- Jira for task and project management.
- Google Sheets for finance and capacity planning.
- Dry Run for forecasting.
- SalesforceIQ for CRM.
- Digital Ocean for hosting.
- Bitbucket for code management/VCS.
I’m sure the list goes on. These are all tools. And they’re important. But, they’re not solutions. And they’re certainly not who we are.
If you let what you do and how you do it define your business, you’re just some company that does some thing, and there are plenty of other businesses like you.
But you’re not, right? So instead, let who you are and why you do what you do define your business.
Like this article? Follow Thinkship below to get notified whenever we publish new hotness.
