Every time we start an engagement, we sit down with our new partner to decide whether to build vs. buy software. It’s not something development shops typically do. We like our “hammer” of custom software solutions, but to be good consultants, we can’t treat every project like it’s a nail.
That’s why we help every partner weigh the advantages of buying software versus building. If we can find existing technology that meets their needs, we can save them tens of thousands of dollars.
Mobile usability testing is hard to do properly, and in-app analytics aren’t all that easy to collect either. But without the user insights both can provide, you’re leaving the success of your business up to guesswork. We can’t recommend you blindly launch a website, then try to improve usage by looking only at pageviews. So we also don’t let clients toss together an app, then guess at improvements based on download numbers.
That’s why, even though it’s hard, we’ve developed a mobile user testing process. We start by collecting the best insights we can while we’re building the app, then we track usage statistics and analytics after it’s launched. That way we can learn why users do what users do. To make informed decisions that improve the product and grow the business, we need to start with mobile app usability testing.
A code audit is the rare do-over in business, a chance to look through your existing codebase and make it better based on what you know now. Just like rehabbing an old house, code audits allow you to save everything that’s working and build on that, instead of scrapping the lot and starting from scratch.
This means they can be the best way to squeeze value out of what you already have.
You can trace most problems in software projects all the way back to the start. Maybe there was a large PDF of needs and requirements. A project kickoff meeting or call that had everyone nodding, but no one asking any questions. A set of goals for the project, but no understanding of how they support the goals of the business.
It’s no wonder things go off the rails — and yes, as a Rails development shop, we endorse that pun.
The most important rule of building and managing a remote team: the burden of communication is on the people working together from the same location, not the people telecommuting.
It may sound obvious, but I just can’t stress it enough. Because when your head is down in development on a project, it’s easy to slip into side conversations and asides that never end up getting communicated to the remote team members you’re leading. You have to constantly remember to project what you’re doing out to your remote team members. Or pretty quickly you end up working from two entirely different playbooks.
That’s why at Table XI, our primary work infrastructure is engineered to support remote work. While most of us are co-located, we want to stay flexible, and we currently have staff working everywhere from Chile to Seattle. Using remote-friendly systems does a couple of good things for us, which I’ll discuss later, but the key benefit is that it keeps people who are remote from being at a disadvantage. All our work happens in a remote-friendly infrastructure. The rest — coffee runs, lunch breaks, movie nights — are additive. You don't hear people talking about work on coffee runs.
Here are our tips for engineering effective remote teams:
At the most basic level, a faster site will do two things: save money and increase revenue. Since those tend to be the two things that boost any company’s bottom line, page speed is increasingly becoming a concern for businesses, especially now that Google’s counting it toward search rankings.
It’s true that to be successful now, your site has to be fast. People just don’t have the patience to wait for a site to load. The basic attention limits have been the same since Robert Miller wrote his 1968 paper: Anything under 0.1 seconds seems to happen instantaneously. Anything that takes less than a second allows users to keep their trains of thought and doesn’t require special feedback. Anything over 10 seconds, and users have pretty much forgotten all about your site or app.
When my husband and I decided to move to Seattle from Chicago, we were looking for a change. We thought we’d move somewhere with better weather, where we already had friends and family. And we thought we’d move somewhere with an active tech community, because we figured we’d need to get new jobs.
OpsConf attendees track how they're connected to each other
If you think it’s crazy to gather 19 of our competitors from 16 companies across three continents just to give them free advice … well, yeah, you would actually not be the first person to think that.
But the truth is that I started OpsConf — short for Operations Conference — at a time when I desperately needed some free advice of my own. Table XI was growing, and we were figuring things out on the fly. In the development world, it’s easy to fall into the trap of believing you’re the smartest, that you have all the answers you need. But two years ago, trying to figure out how to scale Table XI without giving up the things that make us great, it was pretty clear that I did not have all the answers. I needed a bigger sounding board. So I built one.
As engineers and problem solvers, we like good ideas, but we like good ideas implemented even better. To help somebody coalesce their vision into something that's actionable — that’s a process that’s rewarding for us. Doing a strategy inception gives us an opportunity to interact with people who are just ridiculously smart in their domain and to add tons of value by forming an actionable plan around their expertise.