Given the COVID-19 crisis, most companies that can have shifted to temporary work from home policy. While about a quarter of those companies are likely already adept at working remotely — at least to some degree. The rest are completely new to this way of working and it’s not an easy shift. I’d like to share a few tips from our experience working with remote-first companies and across distributed teams.

Continue reading …

Carbon Five has worked with a variety of clients across the globe and within our own five offices that require remote collaboration while maintaining a sense of camaraderie and team cohesion.

With a lot of teams transitioning to remote workforces, we opened up the conversation to share some of our best practices. We would love to hear what you are doing as well. Tweet us at @carbonfive to share any other tips and tools your team finds effective!

Continue reading …

Beyond Just Features and Bugs

Projects tend to have three types of “tasks” for developers to do: features, bugs, and chores. Features and bugs are mostly self-explanatory. Features deliver direct customer value. Bugs are features that are not working as intended. These two tasks focus on direct connections to the users. Chores provide indirect customer value. Indirect value can be hard to identify as it can come through a variety of paths.

Continue reading …

Companies have been successfully partnering with consultants since the dawn of time. Think IDEO’s work with Apple to create the mouse or Microsoft’s work with IBM to create MS-DOS. Our nation’s competitive strength comes, in large part, from this openness to collaborate, to learn from each other, to move quicker, and to leverage outside strengths, when needed and without shame.

Regardless of where you stand on the topic of partnering, there is one thing you have to realize. If you’re in tech and growing fast, there is a high likelihood you will have to partner at some point to meet your goals. Today’s labor market is just too tight to fill all the demand for experienced software talent.

Continue reading …

Each team has their own tolerance for what is and is not a reason to request changes on a PR and block it from being merged. This may be rooted in process, fairness, and expediency, and may be a company or team decision. Whatever your personal philosophy may be, the team as a whole and often the company has to come to some sort of consensus as to what constitutes a reason to block a PR. Over time, I’ve gotten a little more “block happy” and I’m going to talk about some of the advantages and pitfalls of blocking, and give you a mega list of reasons you might want to block a PR.

Continue reading …

What’s the most important meeting of your day? For everyone involved in building your product — product managers, developers, designers — it should be the daily stand-up. Where else can you learn what your coworkers are doing, get your work unblocked, and get energized, all in 10 action-packed minutes? 

Continue reading …

It’s a simple idea that can help your digital product take shape; when a user enters your system, do you hand them a map or a path? What’s the difference? Great question, and in this case, the metaphor is pretty literal.

So you want to grow your product? That’s super awesome. Growth is often a goal that startups rush towards. 

“We need 100,000 monthly active users yesterday.” – random startup person 

Growth can mean a lot of things. Maybe you’re trying to grow the number of users, or increase time spent using your product. Whatever it is, growth usually means moving metrics. But meeting your growth goal takes a very meticulous and strategic design process. You need to try out ideas and see what actually works. In this article, I am going to share how to set up a successful experiment-driven design process that can help you identify the features and changes to grow your product. Let’s grow!

Does your product development team do a weekly retrospective? At Carbon Five, we think it’s the most important meeting of the week. Here are some tactical suggestions for facilitating a retro, so your team understands their challenges, celebrates their successes, and comes away with an actionable to-do list.  

Back at my first job in tech, we paired 95% of the time. Many people were new to pairing. As it was my first job, I was relatively one of the more junior people on the team, which is an especially difficult position to be in for pairing. It was an incredibly intense experience for the whole team with many growing pains. There was a lot to navigate and no set-aside time or structure to do that, so I started having “pairing retros” with my teammates. It made pairing a lot more manageable and I started having better experiences with my pairs. It’s now something I’ve continued to do throughout my career.

The concept is fairly simple. Set aside a time when you’re not pairing, to talk about pairing.