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.
E-commerce is literally the most rewarding part of a web application — you can see money flowing into your company due directly to the code you have written. But dealing with payments and payment gateways is complicated and stressful. It's often the most complicated and precise business logic in a system.
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:
We’re experts at mobile development technologies, but the definition of “mobile” changes constantly. Because mobile usage is growing so fast and there are new tools and frameworks for building mobile apps every week, we have to be constantly finding, testing and adopting new skills and tools just to keep up.
That’s why we’ve made learning and teaching an important part of how we operate as a team.
I’ve written before about how much the tools and processes for our mobile team changed in the four years we’ve been around, but the truth is that they’re still changing. There are new tools and design patterns for structuring apps coming out all the time, a lot of which we want to try out. In the past year, we took React Native (a new cross-platform framework by Facebook) for a spin and really liked where it was going. Keeping up with what’s out there lets us give our partners the latest and greatest, and to do that efficiently we need everyone on our team to be looking out for cool things they want to bring to the group for testing.
I kind of didn't mean to go into development, which is how a lot of these stories start. I was a philosophy major finishing up school when I started learning Processing, a programming framework for building generative artwork and videos. Eventually I realized the programming part was rather enjoyable all on its own, so I went to Dev Bootcamp and spent 18 weeks learning Ruby. It was challenging, and I knew it was something I'd enjoy doing every day.
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.
For the client, the goal of working with a tech consultancy is simple — get as much value to the business as possible for your money. That’s how it should work. That’s how we want it to work. Clients are supposed to push back on us, ask questions about what we’re doing and help us align our work with their goals. Even if that means asking “What is this, can we cut it?”
As a project manager, it’s my job to help clients understand the value of what we’re doing. But when clients would ask about UX design, I didn’t feel like I had a good answer. I know that the value is there, but I could not voice it to my clients as well as I can for development.
I wanted to be able to better inform my clients and better advocate for my coworkers, so I added getting a better understanding of UX design to my professional development goals. I didn’t have joining a GV Design Sprint in mind, but when a new client hired us to work on a new product idea, joining the UX design team for two weeks on two GV Design Sprints seemed like the perfect way to get a crash course in design. Table XI covered the cost of me joining the sprint as an investment in my growth, so my participation was free to the client, and I was able to contribute while continuing to manage my other projects.
If you want to know the full power of a Google product design sprint, consider this: In one week we’re able to identify a new product or feature, build a prototype, and test it on real users. That’s impressive enough, but what’s truly remarkable is that design sprints let us do all this alongside our clients — and without tears or late nights. If anything, it makes us a stronger, better team.