In February 2013, Marissa Mayer, the new CEO of Yahoo, decided to put an end to remote work at the company. In the memo, the company stated “to become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices.” All Yahoo employees were expected to give up any remote working arrangements and get back into the office.

I had a similar experience several years ago at a company I worked for when a new executive came on board. After a short period of time, he introduced a similar policy to the one above. We were much smaller than Yahoo at the time, but had been an extremely remote friendly organization up to that point. He described his motives as much the same (though he did let slip a few times that what he wanted was to look out of his office window and be able to see everybody in his department, for whatever that is worth).

So is it true? Do co-located teams truly perform better? Are communication and collaboration truly better when physically close?
​
The conventional wisdom today seems to believe that co-located is significantly better. I’ve been personally told that all the research points to that. But having experienced both poorly performing, co-located teams as well as high performing distributed teams, I wanted to take a closer look at some of the research as well as experiences of others.

There have been a number of studies that have taken a look at co-located and remote teams. While there could still be significant research done in this area (and I look forward to more of it), there has been quite a bit written and there are some key points we can glean from these studies.

How organizations support distributed project teams: Key dimensions and their impact on decision making and teamwork effectiveness
In this study, the researchers looked at how organizational support impacts project teams both in the decision-making process and the overall effectiveness. Ultimately, it found three key contributors to success:

1. Strategic staffing is significantly associated with team effectiveness. The team members are a critical part of the overall success of distributed teams.
2. Training and tools provided by the organization are critical in high-performing remote teams.
3. Team autonomy is incredibly important for quality decision making, especially in remote teams.
   ​

Exploring Agility in Distributed Information Systems Development Teams: An Interpretive Study in an Offshoring Context.
While the primary focus of this study is on the agility of distributed teams, and the difficulties presented by remote work, it also has some key takeaways for the success of distributed teams that I found helpful.

1. Agility is multi-faceted. It has to do with the team members, the team culture, the technology, and the processes employed by the group.
2. Understanding and collaboration are key to success and effectiveness.
   
   

Leadership Dynamics in Partially Distributed Teams: An Exploratory Study of the Effects of Configuration and Distance
This study took a look at leadership in partially distributed teams, analyzing the different dimensions of distance such as geographic, cultural, and temporal.
The key conclusion was that leaders must assist the team in bridging the distances. It took a different kind of leadership to make this happen on the teams, and ultimately took effort from leaders and team members to be effective.

Supporting the development of shared understanding in distributed design teams
Shared understanding is a key measure of communication effectiveness, especially on distributed teams. Reaching and maintaining shared understanding is critical, both perceived shared understanding as well as actual shared understanding.

For teams to reach this level of communication and effectiveness, they need appropriate training and support. The tools that teams have access to are also very important in their ability to communicate, work on tasks, and reach a shared understanding.

This study also highlights the difference between homogenous and heterogeneous teams, noting that more diverse teams (diverse in background, experience, location, culture, etc.) will require more support initially.

Project Risk Differences Between Virtual and Co-Located Teams
It shouldn’t be taken for granted that there are different risks in creating and managing virtual teams as opposed to co-located teams. This study looked at 55 project risk factors that other studies have identified as important to project success.

Of the 55, seven were identified as greater risks for virtual teams as opposed to co-located teams. These included insufficient knowledge transfer, lack of project team cohesion, cultural or language differences, inadequate technical resources, inexperience with the company and its processes, loss of key resources, and hidden agendas.

Effects of team member psychological proximity on teamwork performance
Some studies have claimed that as team-member physical proximity increases, the frequency and quality of communication increases, resulting in better team performance. More recent studies have found that there is no effect of team-member proximity on team performance. The missing factor may actually be the idea of psychological proximity, which takes into account all the aspects of proximity for a team.

This study analyzed the psychological proximity factors (spatial, temporal and social) and their impact on teamwork quality factors (communication, collaboration, coordination, and cohesion). Ultimately, reducing social distance helped overcome spatial and temporal distance, and was the most important factor in team quality. Social ties are incredibly important among team members. The spatial distance can be overcome with the right tools and coordination, especially when supported by the broader organization. And some sort of synchronous interaction is needed for overcoming both social and temporal distance.

Summary
Most studies I reviewed showed that there are hurdles to remote/distributed teams. But these challenges can be overcome with certain adjustments. We’ll take a closer look at some of those below in addition to a few examples from other teams.

I personally have had the opportunity to work on successful satellite teams as well as high-performing distributed teams. The success of these teams wasn’t by chance.

My Team
At one company, I worked for several years with a highly functional, and highly distributed, development team. Our lead developer was remote as well as our UX designer. Two other team members were primarily remote, and everyone else on the team was partially remote on any given day. As the product manager, I shifted my mindset from an “in-office” focus to a remote focus. Even being in the office, we utilized the tools for effective collaboration across the entire group. It gave everyone the chance to either be present physically or dial in, whether from their desk down the hall or from their office across the country.

This type of mindset was across the team. We often took time to call other team members regularly, even just to chat. This mirrored the kind of discussions that often happen sitting together. Our developers pair-programmed on the phone and shared screens regularly. Our UX designer and I regularly brainstormed and prototyped over video calls.

Our team was intentional in our effort. We had to be, given our distributed group and the fact that we were working on the single most important product for the company. We made it work and were incredibly successful in developing and launching a brand new product (more on that in another post). We hadn’t read any of the studies above, but seemed to understand intuitively or from previous experience that we needed to put in the effort to bridge the gaps and create a cohesive, effective team.

By the end of my time with that specific team, we had successfully launched our new application to over 100,000 students, saving the company millions of dollars and setting the stage for significant growth thereafter.

InVision
I’ve been interested in companies that either have remote teams, are fully remote from the start, or have transitioned to being remote. InVision is a prime example of a company that built remote work into their ethos from the beginning, and then transitioned to being fully distributed as they grew.
If you’re not familiar with InVision, it is a prototyping and design tool widely used across the technology industry. I’ve been using InVision personally for many years. Since it was founded in 2011, InVision has grown to over 1,000 employees and is used by over 5 million people at thousands of companies worldwide.

The benefits of being completely remote have been significant according to the founder, Clark Valberg, and CPO, Mark Frein. These benefits have included the ability to hire without geographical restrictions, saving millions by not having office space, and building a better product.

InVision has been incredibly successful, and has done it with a completely remote workforce.

Automattic
Automattic is the company behind Wordpress, a popular content management system and site builder that is behind many websites on the internet. And it is a fully remote organization. While it also didn’t start out that way, it moved to being fully remote when it realized that it could better empower its employees by allowing them to work when and where they wanted, and after deciding that too few employees were showing up to the office anyway. Automattic now has hundreds of employees across more than 60 countries.

As described in this HBR article, there are numerous lessons from Automattic, as well as some very compelling reasons why remote work has worked so well for them. One of the keys is creativity. Creativity thrives online, and allowing people to find the best way to work allows them to be far more creative than they might be otherwise. That means allowing employees to work when they are most productive, and from wherever they are most productive. Additionally, being distributed allows Automattic to hire the very best people regardless of location (a common theme among the companies I looked at who favor remote work).

Automattic has been very intentional in developing its culture, and it ensures there is ample communication on teams by hiring right, providing good onboarding and tools, and then bringing people together periodically. Those steps have allowed Automattic to thrive as a remote organization, as evidenced by its growth and continued popularity of its products.

Zapier
Zapier has been a remote company since its founding in 2011. It has literally written a book about the subject as well. For those unfamiliar with the company, it allows a user to easily connect apps together to automate processes or accomplish any number of tasks. It essentially allows non-developers to accomplish development tasks that wouldn’t have been achievable before.

Many of the lessons described so far are the ones that Zapier offers as well, as described in an interview with the CEO. The key benefits of remote work for the company have been in attracting and retaining talent, and in overall employee satisfaction.

Basecamp
No discussion of distributed organizations would be complete without discussing Basecamp. Its founders have long been proponents of remote work, and they have also literally written the book about working remotely.

Basecamp was founded in 1999, and has had a longstanding remote-friendly environment. Though the company has stayed intentionally small, it’s longevity and growth is a testament to its values.
The keys to success at Basecamp revolve around the idea of allowing employees to do deep work — limiting synchronous communication, interruptions, and meetings — and allowing employees to do their best work, however and wherever they do that.

Basecamp’s style is significantly different than many other companies. It may even seem radical. But the general principles are similar to other remote companies and they’ve clearly found success in what they’re doing.

So what can we take away from this? How can we make our teams successful and high-performing?
In order to be successful, forming and maintaining a remote or distributed team needs to be intentional, as some of the keys to success are different than co-located teams. While either structure (co-located or distributed) can be effective, both types of teams need to be designed and led with intention.
​

1. Team Members: As a company and team, you have to get the right people on board. One of the core principles for hiring at Automattic is the idea of no heroes. Everyone has to be a team player and getting hiring right is one of the most important steps. It doesn’t matter if an individual is the most skilled person at what they do, if they aren’t able to function within the team with good communication and minimal psychological distance, then there are likely going to be issues regardless of whether the team is distributed or co-located.
   
   
2. Shared Purpose and Understanding: A team has to have a shared purpose and it must achieve a shared understanding. This was a critical component in one of the studies cited above. Shared understanding is achieved with a common vision and actual communication. 
    
   Whether it is a remote team or a co-located team, achieving a shared understanding is critical. And it can’t be accomplished with documentation alone. It has to involve the right conversations. 
   
   In the case with product teams, I’ve seen the idea of “good documentation” take the place of conversations. But that simply won’t work. Good documentation is often the result of good conversations, but the documentation is often a lagging indicator (or a facilitator) in product development. It shouldn’t be seen as an end in itself. I’ve seen co-located teams struggle with this often. So achieving shared understanding must be intentional, regardless of whether the team is co-located or distributed.
   
   
3. Leadership: As the study referenced above indicates, leadership is also a key to success for teams, especially distributed team. This is a common theme throughout the company examples as well. Successful remote companies have to have solid leadership in order to make it effective. 
    
   This is true at the team level as well. It takes a different type of leader to manage a distributed team. So getting the right skill-set and the right mindset is crucial to success. This is where decisions have to be intentional. It may be possible to have weaker leadership when a team is co-located without impacting the team. But to have a successful distributed team, there is less room for weak leadership.
   
   
4. Technology and Tools: A theme throughout the research, as well as the company examples, is the need for the appropriate tools. This is far more important for distributed teams than co-located teams. Having worked on remote teams and satellite offices, I can attest to the importance of this. If the tools aren’t there to support the team (specifically the remote folks), then the team can’t be successful. Fortunately, there are tons of tools available today. I’ve utilized many common ones such as Zoom, Go-To-Meeting, Slack, Teams, Lucidchart, etc. But there are so many others that look great (that I need to experiment with). The key fact is that bridging the distance with tools is critical.
   
   
5. Organizational Support: The successful companies above were supportive of remote work. And that’s a huge key. They were able to build a culture of remote work. This is critical for companies moving to remote friendly work (which should be everyone in my opinion). The organization, particularly those in the headquarters or in the main office, needs to be cognizant of remote employees. More on that in another post, but thinking “remote first” will help get everyone adjusted to the idea of distributed teams.
   
   
6. Effort: As cited above, a critical component in team effectiveness is the social aspect of the team — the relationships among team members. While this may be easier with everyone in the office together, that doesn’t necessarily mean that relationships will develop between team members. In fact, other studies have found that even working in the same office won’t ensure that teams build the appropriate level of trust. This happens when the distance is perceived as far, even if folks are a few seats.
    
   There is a certain amount of effort that has to be put forward to build teams, whether they are sitting together or are distributed across the globe. Without that effort, the perceived distance between folks will be large, and thus the performance of the team will suffer.

When managed correctly, distributed teams perform just as well as their co-located counterparts. But therein lies the rub: you can’t simply put any team together and hope for success.

It would seem that co-located teams may generally perform better because they take the path of less-resistance. There is more room for mistakes when everyone is together in an office. You may not need as strong leadership or as many tools to make co-located teams effective. The effort to communicate can be smaller and the amount of time to bridge some of the distance can potentially be shortened. That’s perfectly fine. But let’s stop claiming that one outperforms the other.
​
With intentional leadership and design, we can create high performing distributed teams. As we’ve seen from the research and the examples above, the limiting factors to remote work are often in the effort put in rather than inherent in the nature of the team.

Like what you read? Feel free to follow me over on Twitter (@kylelarryevans) or sign up for my newsletter, where I post other interesting pieces and explore a range of topics.

References:

Cash, P., Dekoninck, E. & Ahmed-Kristensen, S. (2017). Supporting the development of shared understanding in distributed design teams. Journal of Engineering Design. 28(3), 147–170

Cha, M., Park, J., & Lee, J. (2014). Effects of team member psychological proximity on teamwork performance. Team Performance Management.20(1/2), 81–96

Drouin, N. (2013). How organizations support distributed project teams: Key dimensions and their impact on decision making and teamwork effectiveness. The Journal of Management Development. 32(8), 865–885

Ocker, R., Huang, H., Benbunan-Fich, R., Hiltz, S. (2009). Leadership Dynamics in Partially Distributed Teams: An Exploratory Study of the Effects of Configuration and Distance. Group Decision and Negotiation. 20(3), 273–292

Reed, A. & Knight, L. (2010). Project Risk Differences Between Virtual and Co-Located Teams. The Journal of Computer Information Systems. 51(1), 19–30
​
Sarker, S. & Sarker, S. (2009). Exploring Agility in Distributed Information Systems Development Teams: An Interpretive Study in an Offshoring Context. Information Systems Research. 20(3), 440–461

In my post about Product Thinking vs. Project Thinking, I highlight the differences between the two mindsets. Fundamentally, project thinking is about outputs and timelines while product thinking is focused on outcomes and solutions. And while there are instances where project management is critical, applying project thinking (or project management) to the entire lifecycle of product development is incredibly problematic.

And that is what I see with SAFe (Scaled Agile Framework if you’re unfamiliar with the term). While its intentions may be good — and there may even be companies or situations where it is helpful — as a whole, SAFe is the wrong answer. It may be a project management dream come true, but the issues with SAFe are numerous and significant.

Practical Problems
From a practical perspective, there are several issues.

Layers of Process. SAFe adds layers of process to product development that don’t need to be there. For example, Program Increment Planning (PI) is a formalized process by which all teams plan out and discuss their deliverables for the next quarter and align with all other groups. It is a formal meeting that takes place for several days. Now, this may sound good on its face because communication like this is a good thing, as is the planning and understanding that can result from it. But the process by which it is accomplished makes it overly burdensome in practice and takes away a team’s agility both by forcing the set meetings at the set time, and by locking in many of the commitments of those meetings with little wiggle room after the fact.

By putting so much focus on the structured meetings and process, it also takes away the emphasis on continual learning. Discovery shouldn’t be happening once a quarter, but continuously. Same with prioritization. Locking in these important aspects of product development to be done only at specified times does a real disservice to teams.

Generally speaking, if you look at the diagrams and processes outlined for SAFe, you can easily understand why the entire thing is overly burdensome and complex. Rather than simplifying or streamlining, it bogs down the entire development cycle with unnecessary processes.

Layers of Management. In addition to the heaviness of the process, SAFe also add (or keeps) layers of management throughout the development process. From the development teams to release train engineers to epic owners and beyond. The many layers of management reflect the many layers of process, complicating the overall workflow and adding a lot of cooks to the kitchen. While this may look incredibly appealing to managers, centralizing a lot of control at each level, the reality of having so many hands involved is often confusion and slow-downs as everyone steps on each other’s toes and each group may have different ways of doing things.

Additionally, it removes too many teams and people from the impact of their work. Instead of having a product owner or team responsible for features, and another layer responsible for business communication and yet another layer responsible for market needs, a development team should know and understand all of those facets. How can anyone be expected to truly deliver value to users beings so far removed?

Stagnation. In some regards, SAFe could be considered remedial agile. I never like to get into the debates about what is agile and what isn’t — they tend to be unproductive and pointless — but SAFe isn’t about scaling agile for large organizations in the sense that it takes agile principles and applies them to large groups. Rather, it is about beginning to apply some agile principles to large organizations that have no other agile experience. This could be great for a large company that is steeped in processes and waterfall methodology. But if SAFe is the end rather than a stepping stone in the process, it will ultimately result in stagnation of teams and products.

Philosophical Problems
From a more philosophical perspective, the issues are even greater.

Focus on Methodology. SAFe begs for the focus to be on the methodology itself. With the heavy processes and prescriptions, it’s almost necessary. This, of course, isn’t unique to SAFe. It is a fundamental issue with many methodologies: the process becomes an end unto itself. Scrum has the same problem, where the focus too often drifts from creating value for users to optimizing the development process, as measured by story points, velocity, etc. Optimizing may be important, but it is a means to an end, not an end itself.

Lack of Autonomy. Second, rather than giving autonomy to teams, SAFe removes autonomy from teams and ties them down often to lists of features. Part of PI often involves determining the features of the next 3 months. That isn’t necessarily a bad thing, but it becomes an issue by locking a team into features rather than outcomes. SAFe also ties all teams together into release trains and other processes. Rather than allowing a team to function independently — experimenting, releasing, and learning — teams are all formally tied together and dependent on each other. Decisions that may have otherwise been able to be made independently are now constrained by the process.

Lack of Agility. The purpose of agile is to allow teams to be, well, agile. That means allowing teams to design, build, test, learn, and iterate. The focus is on outcomes, which may or may not be achieved by certain features. Having agility means being able to shift priority or feature in order to better deliver the outcomes. It allows teams to learn from their experiments and then make adjustments as they go. This type of agility is the antithesis of the planning and processes imposed by SAFe and project thinking in general.

Hiding the Real Issues. Finally, rather than addressing the real underlying issues, many of which are described above, SAFe can cover them up with its processes and prescriptions. If an issue an organization faces is too many interdependencies among teams, SAFe’s prescription adds lots of planning and coordination between those team prior to having work begin. That is great if those dependencies can’t be decoupled. But what about organizations where they can and should be decoupled? Rather than tackle the hard work of reducing complexity, we paint over it with more meetings and processes.

That includes complexity from a product as well as from a people structure. If there is too much hierarchy within an organization, SAFe realigns it, but doesn’t fix it. The real issue is likely too much structure already, and the solution may be to flatten the organization so that people can actually have ownership of their work.

Finally, rather than fostering better communication up and down the chain, SAFe adds too many layers. If the real issue is executive communication and buy-in, SAFe may seem like a good answer with its processes and pyramid structure. But it doesn’t address the underlying issue, which may be a lack of understanding or a lack of real involvement from executive leaders.

Theoretically, SAFe is meant to solve some real problems for teams and organizations. Unfortunately, it fails in too many regards in practice. By overburdening teams with heavy processes and prescriptions, it ultimately takes away too much autonomy and agility. Rather than supporting product development teams, it asks that product teams support all the layers of management above. This isn’t unique to SAFe, and managers too often have their roles backward in thinking their teams are meant to support management rather than the other way around, but it is ingrained in the process.

SAFe is another embodiment of project thinking. While product thinking is the solution for product development, it is easy to slip back into a project mindset where the goal is to map out features and outputs and then simply focus on delivering them on a specific timeline. And that is what SAFe does: it puts the focus on outputs rather than outcomes. Success is measured on committing to features and then delivering them throughout the quarter. Of course, this is great if you’re right about all your guesses ahead of time, but that won’t generally be the case. And when processes take the place of outcomes, it’s not good for teams, organizations, or users.
​
Ultimately, the focus should be on the users of our products and services. We should eliminate as many processes and constraints as possible to better allow our product teams to deliver value. That means reducing complexity and organizational overhead, not adding to it. Get the right people and the right goals, then get things out of their way. Principles will scale to any size, so get those right and you’ll find the right scaled structure.

If I could pick one thing to kill because of the problems it causes, roadmaps might very well be at the top of the list. And it's not that I don't like roadmaps, or at least the principle of product roadmaps. It's the misunderstandings that they bring. Sometimes the misinterpretation of a roadmap actually causes far more problems than the roadmap sets out to solve. Why is that? And what can we do?

Purpose of a Roadmap

The first thing is to really understand the purpose (or purposes) of a product roadmap. Fundamentally, a roadmap is a strategic document used to create the overarching product vision, articulating the value you're delivering to users and the business in order to gain support and alignment. 

I break this down into a few key categories:

1. Inspiration and Vision: A roadmap is meant to help others see the vision of what we're doing. This is one of the most critical purposes of a roadmap because without a coherent vision, no product will be successful and no team will be functional. 
2. Communication: A roadmap is a communication device. It is meant not only to inspire, but also to allow users and business partners to know what is coming up and where the focus will be. It helps take the overarching vision and make it understandable and clear. Many groups simply need to know what's coming in order to prepare for it. And a roadmap is a great way to accomplish that.
3. Discussion: The roadmap is meant to help facilitate discussion about the direction and focus of what we're doing. Hopefully once we've created the vision and opened the channels of communication, we can have the right discussions about the problems we're solving and the outcomes we're focused on. This is critical because we also want to get feedback on our roadmap. It can be the first "test" of our strategy ensuring that we've prioritized correctly. That feedback can be invaluable in ensuring direction and buy-in.
4. Alignment: And of course, once we've had the critical discussions, the purpose is to get alignment around our product strategy and outcomes. A roadmap facilitates all of this communication and planning to ensure our product team is focused on achieving the right outcomes for our users and our business. It helps align our product teams and our stakeholders so we're working toward a common purpose and goal.

All of these pieces are crucial, because a roadmap is a living document. The purpose of a roadmap isn't to create an artifact that we can refer people to or post on a page somewhere. The items above are a continual loop as we learn iterate. By creating the vision, having the right conversations with users and stakeholders, and adding the learning that we get as we progress, we can continually refine our direction and plan for the future.

So Where Does This Go Wrong?

The purpose of the roadmap sounds great. Who doesn't want to inspire their users and stakeholders while ensuring everyone is strategically aligned? Why would anyone want to kill that? Where does this go wrong? 

A roadmap is not a project plan. Far too often a roadmap gets confused for a project plan. A roadmap isn't meant to be the detailed execution of specific projects. It's not meant to commit to dates for releases or timelines for features. There is certainly a place for that level of specificity, but it isn't the roadmap, especially as we look several quarters into the future.

A roadmap is not set in stone. This is probably one of the biggest problems that many of us have faced. Far too often a plan is put in place at the beginning of the year with themes or focuses for the entire year. And we get stakeholders or users who view the roadmap as a commitment to those specific items, even if we find we need to pivot along the way. This problem is exacerbated when the roadmap becomes a project plan with specific features called out far in advance and commitments to them made with dates. See this article for more about keeping a product mindset.

A roadmap is not a list of features or requirements. A roadmap should be strategic. It should be focused on the vision and direction of the product, and the problems we're solving. It is about the value we're delivering, not necessarily the features. While it certainly is okay to talk about features on the roadmap, especially the near-term features that we're confident in committing too, it's important to caveat specific features with the understanding that the features are meant to solve a problem or achieve an outcome. We aren't simply delivering a wish-list of features.

Key Principles

Now that we're clearer on what a roadmap is and isn't, what can be done? How can we craft roadmaps that fulfill the needs of users and stakeholders while still allowing us to learn and iterate along the way? 

No two roadmaps need to necessarily be the same. And I won't advocate for any specific template over another here. I've used variety of different types of roadmaps and they all have benefits and drawbacks. There are a few key principles that are true of most roadmaps. 

1. Focus on Outcomes: As mentioned above, the key purpose of a roadmap is to convey the benefits and outcomes of our product development. So any roadmap we create should focus on the value we're providing and how we can measure it.
2. Understand the Audience: You will likely have a variety of groups interested in your roadmap. Each audience may need different things. Executives may be more interested in financial implications of the product development while customer support needs to know what new things are coming so they can be prepared for questions. This may entail tailoring the details of the roadmap to the audience (though I'd avoid maintaining completely separate roadmaps and just focus on different things for different groups where possible).
3. Keep it Clean: Don't get too bogged down in details in the roadmap. As mentioned above, it's not the place for the project plan. It's not the place for extensive details. They will only confuse users and stakeholders and raise lots of questions. It's about the shared understanding. Stakeholders who are intent on getting into details can refer to the project plans or backlogs if necessary, as part of a separate conversation.
4. Convey the Vision: Ultimately the roadmap is about telling the story of your product and getting alignment on the direction. Make sure that it is a cohesive narrative. Often this can be done in a simple, visual format. But in other cases having a longer form narrative may be appropriate.
5. Keep it Updated: Since the roadmap is a living document, make sure that it stays updated. There is no quicker way to lose the value of the roadmap than to let it become stale. If it is going to be the vision and direction of the product, make sure that it stays that way and that everyone is continually bought into that direction, especially as changes happen. 

An Example

What I have done with my roadmaps, and what (fortunately) seems to be becoming more and more common, is something like below (this is very simplified, but has the key ingredients): 

The internet is currently working quite well. It has been for a long time. So obviously we need to drastically change it. 

I guess I'll risk standing apart from the "cool" crowd and say that net neutrality is a silly idea. The most obvious reason is that the internet is working just fine. Yes, if it's not broken, the last thing we need is government bureaucracies "fixing" it. 

But what if internet service providers start to restrict what I can access? What if they blocked certain sites unless I upgraded to a premium plan? What if small businesses had to pay to play? 

All great points. And what if all the unicorns in the world decided to stop dusting us with glitter and rainbows and turned against mankind?

Beside the fact that the internet already operates with fast-lanes for companies willing to pay, the arguments in favor of net neutrality continue to set up non-existent problems in order to impose a so-called solution. 

And that solution would be turning ISPs into utility companies, nominally under full control of the government. Of course, what could go wrong with that? The government has time and time again shown that it cannot even succeed at basic functions. So obviously it should be put in charge of internet access. 

If that is the view you subscribe to, I certainly hope that you are happy with the internet exactly as it is right now. I hope you're happy with your current service, the current speeds and bandwidth etc. Because by turning ISPs into utilities, we would effectively take away any incentive to continue to develop and improve infrastructure. It is happening already as the debate rages on.

Perhaps the scariest part of the net neutrality argument is that it is based on regulatory forbearance. The idea that regulators, once put in charge of the internet, would govern with a light touch. If anyone can please point to any regulatory agency that has ever governed with a light touch, especially in our modern era, I would be much obliged. Regulators by nature seek to increase their regulatory reach and power. There's no way around that.

Why shouldn't companies like Netflix and Google help in the build-out of infrastructure, or pay to have their content delivered faster if all parties can come to an agreement? Let's not act like Netflix is some sort of start-up either. It consumes huge amounts of bandwidth. Wouldn't users be better off with Netflix helping to deliver movies faster? And wouldn't non-users be better off with freed up bandwidth. 

Now I'm certainly not arguing that we allow Comcast to hold companies hostage. There are already rules and laws in place to deal with that. And what incentive would Comcast, or any other ISP, have to do something like that in a competitive market?

Competition ultimately will be the thing that helps consumers the most, not additional regulation. We all have multiple options for ISPs and they continue to grow. Last year we had a company start a new service in our area, offering double the speeds for the same price. We made the switch. The other companies quickly followed suit, offering faster speeds and lower prices. That is what we want, isn't it? Government simply can't regulate that into existence. 
 

The Moto 360 launched on September 4. I got one on September 6. As my friend who picked one up the same day said, we were probably among the first 10 people in Utah to have one. I was fortunate enough to have a wife who was not only eagerly awaiting the launch, but also was monitoring inventory at Best Buy around the state in order to grab one for me as soon as she could. An early birthday gift. Very early, and very sweet.

I've been looking forward to having a smartwatch for quite some time. I wanted to get a Samsung Gear when they first came out and have been interested since then. I'm a watch guy, and a gadget guy, so it's just about the perfect intersection.

So what has it been like so far? Better than I expected. I didn't really realize how often I would be using it. Even that first weekend had me surprised. 

I'm a person who is constantly checking my phone. Emails, texts, news alerts and notifications in general have me reaching for my phone frequently. Now those are all on my wrist. I see each one as it comes and can act accordingly. No more digging out my phone just to realize it's a Groupon email. The same goes for music. The control is on my wrist, so I can skip songs easily now.

All these things are great for when you're sitting at your desk, and even better when you're driving. We also went for a drive up the canyon that Sunday. I didn't realize how convenient it would be to have all my notifications so easily accessible. I can't tell you how many times I've felt my phone start to vibrate and had to pull it out to see if it was something important or something that could wait (almost always the latter). 

And it has inspired me to use services I hadn't fully utilized before. A colleague wondered how the location based notifications worked. So I set some reminders for myself for when I got to work and when I got home. When I arrived, my watch buzzed my and popped up my reminder. I've also started using voice commands with it. I've never been much for the voice commands until now. But having a wearable helps voice commands make a lot more sense, whether doing a quick Google search or replying to a message.

And let's talk about the style for just a second. It looks like a watch. It's the kind of watch I'd be interested in if it wasn't a smartwatch. The leather band is subtle yet stylish (and leather bands are just generally better anyway). I've gotten compliments on the watch and people didn't even know it was a smartwatch. That's how it should be.

Are there things I'd change? The battery life is the first that comes to mind. But I'm not a guy who wears a watch 24/7, so charging really doesn't feel like a massive problem to me. If I keep the screen on most the day, it lasts me 12-13 hours. If I change it so it's only on when I look at the watch, It could probably go 25+ hours without a problem. And I'd love for it to be a bluetooth speaker, but that may just be the James Bond lover in me.

Admittedly, a smartwatch won't be for everyone. But I think it will be for most people soon. And as the software continues to improve, it really feels like the possibilities are limitless. I'm probably hooked at this point, so no turning back anyway.

It continually surprises me how many of my friends, family members, colleagues, etc. refuse to use different social networks. From Facebook to Twitter to Google+, they are set on staying disconnected in our modern world.

The most common reason I hear is that Facebook is stupid or Twitter is pointless or something in that vein. People just play stupid games or post what they just ate for lunch. Granted, those things do make Facebook stupid and Twitter pointless. But I think most of us would probably agree that there is no quicker way to get hidden from a timeline or unfollowed than to do those types of things.

It's really too bad that some unsavvy users have given such a bad rap to otherwise powerful tools, especially for newcomers (and very latecomers). As I fight to convince a few stubborn friends to join Facebook, they refuse to see the potential good and just focus on the bad. When we all want to get together for something, it is always arranged through Facebook, so they inevitably miss out. And staying up-to-date on what's happening in each other's lives? They're left in the dark.

I seem to have an even more uphill battle with Twitter. But if you want to hear about the latest news as it breaks, there is no better tool. And if you want commentary on that same news? It's certainly the best place. And if you want to know what someone had for lunch? You won't, because you already unfollowed that person a long time ago.

Of course, I'd be okay giving up Facebook if my battle in favor of Google+ would go anywhere. It really hasn't, and that's a shame because it's so much better.

I can definitely understand not understanding certain networks or hot new apps etc. While I generally try to utilize as many as I can, not all of them work for me. That's certainly not their fault, it's just how I tend to use the internet and share things.

Now certainly there are concerns with any social network. But that's why you just have to be a savvy user. You wouldn't refuse to ever use a hammer again because there are some people in the world who don't use hammers appropriately. It's a tool just like any other. If you focus on using it correctly, it will be a huge benefit to you. And to me.

A recent conversation among colleagues reminded me of a few conversations I've had over the years. The most recent version was in regard to Google Glass. Most of my colleagues see very little use for that kind of technology and don't think it's practical or even desirable. 

I of course disagree.

If price weren't such an obstacle at the moment, I would undoubtedly be sporting Glass right now. And as soon as it becomes more reasonable, you can count on it for me. While many people ask why you'd want to be plugged in like that all the time, I ask why you wouldn't? Something like Glass has so much potential to be a game changer. Notifications in real time. Instructions as you need them. Who knows what else.

And frankly, aren't we that plugged in already? If I can eliminate the step of taking out my phone or flipping through tabs, wouldn't I want that?

This reminds me of a conversation I had years ago when the iPhone was new and other smartphones were nearly unheard of. I thought the idea of having everything in a single device was perfection. Others weren't so sold though. Why would you want that? We have a phone that calls and texts, an iPod for music and then your digital camera for whenever you needed it. Why pay to have all those things together?

Why would you want that indeed.

So I'll happily be a beta user as much as I can. Even if it doesn't quite pan out, and there is certainly no guarantee that Google Glass is the future, I'll happily embrace the latest and greatest. And who knows, maybe having a phone that also has all your music will pan out.