On scaling up teams

I’ve been doing a lot of reading on teams lately, coming up with pretty common trends, such as the importance of good team dynamics, namely people are a huge reason why a team is productive or not. Or in other words, throwing a bunch of random people together an expecting a good team to emerge is a pretty big anti-pattern if there ever was one.

What I’ve found is most people’s theories on team dynamics and building a good team tends to scale to around a dozen folks max. But what happens when your team gets larger?  All of a sudden that tight knit group begins to fracture into their own tribes, which is when the dreaded “office politics” begin to emerge.

I was reading this blog post the other day, which really spelled out what happens. Quoting from them…

The craft itself – the creation of that new business model and new product to solve a big, painful problem,  is a smaller and smaller portion of the time and energy pie chart (at least, for managers/execs/founders). In some ways, that’s a sad, frustrating thing. And in other ways, it’s a healthy, normal part of  scaling.

Why? Because getting bigger and working cohesively toward common goals comes into conflict with so much of human nature.

Human nature dictates that we:

  • Form tribes to build identity and camraderie – yet in a scaling startup, this causes untenable, painful, progress-stopping inter-team rivalries.
  • Invent a common enemy upon which we can heap blame and against which we can fight – sadly, inside the tribes that naturally form, there’s often a tendency to create that common enemy internally (it could be marketing vs. engineering or testing vs. production or sales vs. execs, or any number of others).
  • Minimize the positives and focus on the negatives – that could be feedback from customers, internal critiques, manager reviews, product imperfections, or weaknesses in process. It’s so easy to forget that we somehow beat the formidable odds against building something that worked, something that attracted customers, something that scaled, and a company where hundreds of people really do want to work.
  • Resist change at all costs – yet in a scaling startup, change is the only constant, and processes, procedures, formats, teams, and everything else has to change to be successful.
  • Act emotionally, yet believe our decisions to be driven solely by logic – we tell ourselves we act rationally, but can easily prove that irrational biases rule our minds. This wouldn’t be nearly as dangerous if we could recognize these biases, but in another failing of human nature, we cannot – we cling to the notion that our decisions, unlike the rest of our species, are uniquely logical.
  • Lose empathy as our numbers grow – tragically, when we need empathy the most (as an organization gets bigger and there are more people to consider and more complexities between them), our nature is to rescind it. It’s easy to empathize with a small group you see everyday, but much harder to extend that empathy to everyone in a larger group (especially those you may not know well).
  • Create rules and process to prevent against repeats of singular abuses – the old adage of one bad apple ruining the whole bunch becomes more and more likely the larger a startup grows. Process can be wonderful, but sometimes we create a process just to ward against some bad behavior from a former employeee and, by doing so, ruin the company a little more for everyone. Use process to free and enable, not to punish and restrict.
  • Irrationally romanticize the past – “Remember how things used to be? It was so much better three years ago when I first started here and…” -everyone at any organization, ever. But I remember three years ago. It sucked compared to today. Our ability to delight customers paled in comparison. Our ability to attract talent was in the toilet. Fear about our budget and our bottom line was a daily occurrence. 2013 is superior in so many ways and I know it, but even still find myself fondly remembering (or, rather, misremembering) back in 2010 when (in my human-addled mind) it all seemed so much easier.

This really nailed it on the head; as a small and nimble team, the sense of camaraderie gives you this sense of security and drive. And this is a good thing, as in the early days the focus on getting a product to market and getting a revenue stream established gives a team clear vision and goals. But when you hit one of those plateaus, things get a bit more cloudy on where to go from there.

I don’t think there’s a magic bullet to avoid all of this. Nor can you try to cling on avoiding team growth as a way around this. You need to know it’s coming, and make sure you don’t let the larger team grow apart.

Working successful outside the cube, a redux

It’s been a few weeks since I was in Belgium for the excellent 2012 PHPBenelux Conference, which brought together beer, chocolates ( at least for the wife ) and PHP together for an excellent two days of fun and community. And I did a new talk, Working successfully outside the cube, which was a new talk for me that I got great feedback from.

But, from reading the comments, there’s two points I didn’t really hit on well during the talk, so I figured I take the time now and try to answer them here.

What is the cost to my employer to be remote?

There isn’t a hard and fast answer to this question, and it depends upon your organization’s structure and policies along with what technologies they already have in place. Generally speaking, you’ll need this:

  • A computer that is portable enough to take between home and work. This is a laptop for most people, but if you have one of those ultra-portable desktops that would work as well. But anymore, the cost between a desktop and laptop isn’t very much. Even if you don’t work remote having the convenience of being able to take your laptop to meetings, over to your boss’s or co-worker’s desk, or out to a customer site, far outweighs the minor additional costs.
  • Tools to communicate with co-workers. This usually means IM or IRC for quick messaging, Skype or a soft phone for talking directly with someone, and Gotomeeting or WebEx for doing screen sharing. Most organizations I know of have these sort of tools already in place for their marketing, sales, and/or support teams, and if not many of these are free or low cost to use.
  • A way to access servers and other resources in the office remotely. This is most likely a VPN or other secure connection, which chances are good already exist if you salespeople or other executives that are outside of the office working with any frequency.

It’s probably best to investigate this first with your boss to see if there are any hurdles you need to get past, but chances are good the infrastructure is already in place.

What are some best practices for collaboration tools for remote workers?

While everyone’s organization is different, here’s what I find that works best for me:

  • Got a quick question? Use IM or IRC for this, unless you don’t need an answer right now, then use email
  • Want to chat an issue over with someone? Use Skype, or perhaps Gotomeeting/WebEx if you need to show your screen to someone.
  • Need someones attention now? Direct IM, text message, or email works best here.

As for soft skills in effective communication, check out a blog post I did about respecting other’s time a while back for some good points on effectively planning meetings and learning how to make sure your interactions are productive with others. And next weekend I’ll be doing a talk at the virtual Day Camp 4 Developers conference around how to navigate the business world, which should also help you out in your quest to better plug into your organization and be productive while a remote worker.

Hope this answers everyone’s lingering questions from the talk. Thanks again for all the great feedback, I hope to do it again soon…


Being respective of your time, as well as others

One of the biggest challenges I’ve run into in being a “remotee” is the daily interaction with other team members. When you are just a cube, an office, or a desk away, there’s always that common water cooler or coffee pot that provides a natural place to interact with others. Or, if you have a question, you can always just stop and ask. Being able to physically get together without having to make much effort is a real bonus for people working in the same office, but can be a bit more challenging if you are remote team member. But this can also be a blessing in disguise, allowing you to concentrate on projects more and be interrupted less often.

What many people don’t realize is that every interaction with fellow team member or collegue is a meeting, and having that meeting is taking he or she away from thier normal duties. Organizations don’t hire people to be in meetings all day, they hire them to be productive contributors to making the organzation as a whole successful. This is where being remote has it’s advantage, as it’s easier to turn off the outside world by turning off your virtual links where in an office you have to hide somewhere to when you need some heads down time.

I recently read the book “Read This Before Our Next Meeting“, which talks about how to improve the quality of the meetings you hold, and at the same time eliminate those pointless meetings that drag your team down. The big takeaway I had from the book is that you need to be respectful of other people’s time. How do you best do this in the context of meetings? Here’s some good starting points:

  • Every meeting should have an agenda, a purpose, and a goal. This helps avoid those “open discussion” types of meetings which can quickly diverge away from what you are really meeting about. A meeting should have a clear purpose that is communicated to the attendees an agenda that everyone has before the meeting so they are ready to discuss the talking points to be addressed. And in end, there should be some tangible goal to be achieved by having a meeting, whether this is a decision to make or action items for people to take out of the meeting to work on separately.
  • Keep meetings short and to the point. Avoid blocking out an hour of someone’s time for a meeting when 15 or 30 minutes will do. This also helps keep you on topic and focused, forcing you to avoid the conversation from spinning out of control.
  • Invite only who should be there. Sometimes we like to play the politics game and make sure certain people are at a meeting. Other times we are worried about “making descions behind closed doors” and thus overinvite to make sure nobody feel out of the loop. If someone really just wants to know what happened, but not really needing to contribute, then take notes or record the session so they can review later. Then if they feedback they can follow up outside of the meeting. The goal here is to have less people in a meeting, which reduces the chances of a meeting spinning wildly out of control.
  • Use smaller meetings for planning, and larger meetings for approval. A friend of mine once told me that the best meeting is one where the decision has already been made, you are just getting everyone’s OK on that decision. I completely agree with this; smaller meetings are great to brainstorm since you can easily have a discussion, but with each person you add keeping everyone on topic gets harder and harder. It’s best to bring a plan to a meeting to have it approved or rejected, then outside of the meeting deal with all the details.

What are your pointers for effective meetings and finding ways to be respectful of people’s time? Let me know in comments.

Want to save the US economy? Hire remote!

I was talking to my boss the other day on his drive into work. He was complaining about how bad the traffic was getting in the South Bay area over the past few weeks during rush hour, and corolating this to how much ecomonic growth is going on in the valley right now. People are hiring like crazy, and as a result it’s becoming harder and harder to find talented developers. I contrast this to the rest of the country, especially where I live in Ohio, where the slowdown in the ecomony and the impending recession are hot button issues and very noticeable.

It’s as huge of a disconnect as I’ve ever seen. But how could we “connect” them back up?

I ran across a great article the other day, which talked about a trend called “Rural Sourcing“. What this does is look into the vast rural sections of the country to build virtual teams and a remote workforce. This allows companies to cut costs by hiring Americans ( gasp! ) that live in areas of the country that have a lower cost of living, where even 20% paycut on the salary earned in those high cost markets will let you live quite comfortably. Plus, employers don’t have the added overhead cost of office space that is becoming harder and harder to come by in many areas, like the Bay Area.

But why not offsource to a far away location like India, China, Eastern Europe, or Africa, where the costs are even lower? Here’s a few good reasons:

  • There isn’t a language barrier to overcome. While English is the defacto language in tech, it doesn’t mean that those in areas of the world where it’s not the predominant language are fluent at it. This is one reason why call centers are moving back to North America in droves.
  • Time difference. It’s quite difficult to work agile with a team when there is little to no overlap in your daily work schedule. In the US, worst case there is a 3 hour time difference between team members, which is quite easy to deal with an enables a team to easily work as one with great visibility. Try that with a 14 hour time difference ( hint: it doesn’t work as well ).
  • Quality of product. This isn’t to say that other countries can’t build something as good as an American, but it’s quite difficult to be agile when there is a time and language barrier to overcome. Offshore teams have to often fall back to building things to spec, since that gives them the best guidance on how to produce what is wanted. But conveying the idea of innovation, thinking outside of the box, or just experimenting tends to not to happen because of the disconnect that happens between developers and product owners. If your team is all on a similar schedule, and can work more agile and less waterfall, the end product will turn out better.
So if you are a company in San Francisco, New York, Boston, or some other high cost market with a shrinking talent pool, try looking else where in the US for talent. By doing it you are saving the US economy, one new hire at a time.

Making in-roads in your organization when you are 2000 miles away

What’s the best way to meet your co-workers? Break their app of course!

I remember fondly how I got on the radar of much of the company I work for in one fell swoop.  One morning I decided to get ambitious and try to move a bug of older bugs for a feature I was working on to be assigned to me, so I could process them individually and close them out. Great idea I figured, and definitely a good way to show the ROI on a project by saying “hey, this change clears out X number of bugs off the backlog”. So heck, why not do it?

As we use Sugar internally to manage bugs, I saw the nifty little “Mass Update” panel as the way to victory. I simply did a search to get myself the list of bugs that I’d be assigning to me, mark them all, then in the ‘Mass Update’ panel put the ‘Assigned To’ to me and click ‘Submit’. Oddly this took a while, which seemed a bit weird at the time but I figured that since it was in the morning US Eastern Time ( which meant very very early US Pacific Time ) perhaps the server was a bit slow and hadn’t woken up let. As it turned out, that wasn’t the case.

I had assigned every bug inside Sugar to myself ( thru no fault of my own, as it turns out it was a bug in our instance).

Thanks to MySQL query logging we were able to step back in time and pretend like this never happened, but within an hour IMs started coming to me like this:

“Hey John, this is XXX. I see you are working on all our bugs now :)”

While for each time I had to explain the curious series of events that lead to this, it was also an opportunity in disguise. Most often the conversation started with “the incident” but quickly moved to me learning more about them and vise-versa. I think that part of it was pretty cool, as within a morning I met a ton of people that I interact with even today on a regular basis.

Now I’m not saying that I recommend you and break something to help get everyone’s attention ( cause you’ll most likely gain the distain of your entire IT staff in one fell swoop ), I do think making yourself known when nobody sees your face is a big part of the remote worked job. Here’s a few ideas on “safe” ways to do this:

  • Promote some great work you’ve done or let everyone know a breakthrough you’ve made on a project you’ve worked on. Everyone likes to see shiny new things, and getting your visibility next to it is a great way to become known well in a company. If you a manager or mentor to remote team members, you may want to do this yourself, as sometimes an email from an unknown may get skipped over while an email from someone known in the company is more likely to be read.
  • Volunteer for a project. This is exactly how I got involved in the PHP project many years ago. I followed the internals list and saw a discussion come up about the current state of the Windows installer, and how the current maintainer didn’t have the time/interest in furthering it along. I decided to take up this project, and thru those efforts got myself better known in the community and part of a great open source project all at the same time. Do be careful here, as sometimes the urge to volunteer just to volunteer can also get you involved in a project you may want no part of.
  • Answer a question. Most teams have some sort of place where people can ask questions about a problem they are running into ( perhaps via an email list, forums, or chat room ). If you know an answer to a question, jump in and answer it.

The key with being remote is to establish yourself as a team player, even though it’s tough to see when you are not there. So look for opportunities where you can use you talents to make an impact, and then don’t be shy; reach out and let people know.

The basics of having successful remote team members

“So how did you find a job with Sugar?”

This is one of the first set of questions that always comes out when people ask me about what I do ( alongside “What’s SugarCRM?”, “What is CRM?”, and “Where’s Ohio?” ). I can actually see how this is a pretty relevant question; SugarCRM has no presence in Ohio other than me ( although now just recently another fellow just joined us ). And it’s not like SugarCRM was doing some sort of hiring campaign in Ohio at the time; heck, Northeast Ohio isn’t exactly what I’d call a “tech hotbed”. So how did I end up here. Let me tell a bit of the story.

It was the fall of 2007, right before gas prices shot up and the economy tanked. I had been working for a small, financial services company for a number of years, looking for something new to do. Becoming more involved with the PHP community, I saw a post by Travis Swicegood that SugarCRM was hiring Engineers. I sent him over a resume that day, and within a few days my interview parade began.

When I say interview parade, I do mean parade. Lots of phone interviews, two coding assignments, and a trip out to the SugarCRM HQ with a day full of interviews with even more people, all over the course of 3 months. While many people gasp at the lengthly interview process, I look back at it and realize to an extent it made sense. Hiring someone that won’t be working in the same physical space as you can seem like a bit of risk if you aren’t used to doing so. While many parts of the organization had remote employees or were completely virtualized, it was somewhat new to this team with at the time just two remote team members ( one of which was originally non-remote for quite sometime ). But ideally hiring remote shouldn’t be a risk, provided you have the infrastructure to support it.

So what is that infrastructure? Here’s a few things I find to be essential parts of it:

  • Excellent communication channels. Having everyone on instant messaging is becoming more and more common these days as a replacement for the desk phone. If you are supporting remote team members this becomes a requirement, as it is really the primary way to keep in touch with your teammates. It’s also helpful for remote team members to help establish “available” and “not available” times, as you can indicate an unavailable status when you are in a meeting, getting some “heads down” work done, eating dinner, having family time, or sleeping. However, don’t restrict yourself to just IM, as being able to talk to people is also a necessity ( if for nothing else but your own sanity, as being remote can get lonely and sometimes you need to talk to someone ). Make sure everyone has access to each other Skype or some other VOIP tool for team meetings or if you just need to talk something out.
  • Collaboration tools. This extends the communication channels above, but give you a better way to have planning and brainstorming sessions. Think WebEx or Gotomeeting here as starters, but even more specialized group whiteboard or pair programming tools could also prove valuable.
  • Mentorship program. While this may be consider more of a “nice to have” for organizations where everyone is under one roof, it is absolutely essential to have if you have remote team members. Remote folks are expected to be self starters and not need much handholding in general, but they need that person they can plug into to help learn the ropes of the organization. I’m thinking this doesn’t necessarily need to be a manager, but perhaps a team lead or another senior team member. And this mentorship program shouldn’t have a finite end, but at the same time shouldn’t be the only way a remote team member interacts with an organization. There should a bond between the mentor and the “mentee” that is continous, with the goal to foster the growth of more bonds into the organization. And this should be just as much for professional and well as social reasons; if the folks in the office are having a team lunch, the remote folks should be able to go have a “lunch on the company” for example. This where the mentor should stay on top of to make sure that even though the remote team member may be 1000 or more miles away, they feel like they are sitting in the next desk over
  • Regular Face to Face time. The whole team should schedule regular times where everyone can get together, on whatever interval makes sense. I think once a quarter is a pretty good sweet spot, as it’s not too often to be burdensome, but not too infrequent as to make the team feel disconnected. This is a great time for long-term planning meetings, code sprints, and lots of social activity. These are the times where your team will bond together, and these bonds will help make the physical distances between team members become less significant. This will cost money ( hey, plane travel ain’t cheap ) but it will pay dividends over time.
As you look at those items, there’s one thing that stands out to me. They not only are requirements for having successful remote employees, but also for successful employees in general. What organization can survive without any of those four items in place?
So reflecting on what it takes to have successful remote team members, it ends up being a reflection of being able to support your team members in general. If you struggle with on-boarding new team members, keeping communication open, and collaborating with others, it’s only going to be worse with remote team members in the mix. But, if you have that strong mentorship program, great communication channels, and a healthy bond within your team, adding someone 5000 miles away will be a piece of cake. And at the same time putting these things in place strengthens your local team members as well, which over the long term makes your team as a whole stronger and more tightly connected.