Tag: Teamwork

5 things I believe about enterprise collaboration

Photo by Kaleidico on Unsplash

I follow enterprise collaboration both as a long time technical writer in the IT industry and as somebody who has written about collaboration platforms over the years for online publications.

It can be too easy to wreck collaboration in my mind. I’ve seen it many times happen during my career, giving me strong beliefs about collaborative cultures and technologies.

1. Collaboration takes at least 2

I’ve worked with people in the past who thought that collaboration was a coworker doing something for them. These people had a lot of dependencies on other team members. The team never seemed to depend on these sorts of people much.

It’s not to say you shouldn’t help your coworker. Working with this type of person made me remember my best collaborations. The common theme in those collaborations was a complementary exchange back and forth of information, input, and insights that benefited the project, team, and the collaborators themselves.

It’s not to say that non-technical people are at a disadvantage with collaboration inside technology organizations. They need to pony up from their own unique strengths.

In the past, I’ve said that collaboration can be transactional depending on the organizational culture. Take, for example, the time-strapped organization that’s not well organized. It’s easier to get help from somebody in such cultures if you can help them towards their project goals.

2. Collaboration platforms work for the team (not vice versa)

I’ve come across awful excuses for collaboration platforms and processes during my years as a technical writer. Sometimes, these collaboration tools were downright business prevention. Users kept using email for collaboration or resorted to sundry acts of Shadow IT to collaborate on files.

Microsoft SharePoint is a prime example where users sometimes have to work for the tool. Think of the times you’ve encountered sluggish performance, Draconian security policies, and poor user experience (UX) that added up to you and your team working around SharePoint to get your job done. No team should have to lose time due to SharePoint issues. For example, I can remember having to use my personal OneDrive account on a contract because of my client couldn’t get access to their SharePoint site for me as a contractor. There were other cases where I had to use my personal Dropbox to collaborate on files.

3. Collaboration at its best means a comfort zone

Looking at some of my best collaborations past and present, I see a comfort zone between coworkers and teams as integral to collaboration success. There needs to be a level of trust and respect amongst team members to make collaboration efforts fruitful.

Working a technical writer — an individual contributor at that — I have to find a comfort zone between me and the subject matter expert (SME) to get the information I need to write. Most often, this means writing a document draft using as many source materials as I can find. I then go to them to the SME to review the draft and patch any gaps.

For my article writing, it means having positive relationships with editors and PR people whom I’ve never met face-to-face or even over video chat. Such trust and a comfort zone come from responding to requests, clear and concise communications, and doing right by the article amongst other factors.

4. Collaboration is about culture before technology

I’ve written in the past about collaboration being about culture before technology. My recent writing about DevOps continues to drive home that point for me.

Full confession, I’m a total collaboration tool geek about SharePoint, Atlassian Confluence, Microsoft Teams, and other tools. Collaboration is a topic I miss writing about, yet I’m the first to admit that none of these technologies can fix a culture that isn’t collaborative.

5. Every employee needs to own collaboration

I often find that enterprises neglect that everybody needs to be an owner in collaborative environments. At a top-level, it means decentralizing the control of your internal collaboration sites to project teams. Major collaboration platforms have the rights settings that can enable you to open up privileges to users without harming overall compliance.

Managing collaboration platforms needs to become part of the team DNA and made easy so it works in the background. For example, a technical writer has a big role to play in SharePoint environments. They should know their document library. They can play that role at the team level. Business analysts can and should play a similar role. Project managers should be able to speak to their schedules and related project artifacts.

Final thoughts

The technologies and culture that power collaboration still fascinates me to this day. I’ve seen so many enterprise collaboration initiatives tank over my career. The initiatives I saw become successful were most often grassroots happening at the project team level.

My name is Will Kelly. I’m a technical writer and content strategist based in the Washington, DC area. I’ve written for corporations and technology publications about such topics as cloud computing, DevOps, and enterprise mobility. Follow me on Twitter: @willkelly

Avoiding the siren of too smart, too small for your team

Image by Henry McIntosh via Unsplash.com

One of the challenges of growing an organization in today’s technology industry is avoiding what I call being too smart, too small. It’s when a small company has a few alpha programmers and perhaps a dynamic manager who create such a tight-knit world for themselves that they lock out the rest of the company even the sales and marketing teams.

Here are five ways for avoiding the siren of too smart, too small:

1. Build a culture of openness

When you are too smart, too small, teams look inward as a matter of necessity and time. As a small team, it’s easy to Ironman through things. We all want smart people on our team but when you lose openness is when the trouble begins. Almost always, small teams don’t lose openness intentionally. Often it happens when the team is tired and understaffed. There’s never time to cross train, do proper retrospectives, and risk mitigation gets pushed off until after the next product release, and then the next release…

Build in openness from the beginning by at least trying to follow a proper Agile development process.

2. Use collaboration tools for question deflection

It’s not about choosing the right collaboration platform when you want to avoid being too smart, too small. Rather, it’s instituting a strategy to centralize product and project information, so it’s all searchable by anyone with the appropriate access privileges.

Modern SaaS collaboration platforms can serve as a repository for all the bits and bytes that project teams collect, but you need a simple question deflection strategy like this one:

  1. Use team scrums and retrospectives as an opportunity to encourage team members to file documents and other project artifacts into an agreed upon cloud repository
  2. Encourage team members to search first, question second when it comes to project questions
  3. Rinse, repeat

Moving to question deflection requires a cultural shift but also the commitment from the project manager, team members, and other departments in the organization to keep filing documents and project artifacts in an agreed upon location. Workers outside the project team also need to be reminded to go online for before they bother a team member with questions that have already been answered online.

3. Document systems

Major technology systems shouldn’t be a matter of oral history, you need documentation or important details that operations, sales, and marketing need to do their job remain locked away in the minds of the development team.

With small development teams, it’s nearly impossible to have programmers document their work in detail. There’s probably not even time for a technical writer to conduct substantive interviews with programmers and other subject matter experts.

Bake documentation into your processes and set expectations that documentation much like your product features will grow and evolve iteratively.

4. Record web conferences and use chat logs

Taking notes in a meeting is often a waste in the age of web conferencing. So turn on the recording features of your conferencing systems and use chat logs to ensure that any meetings and chats are archived for later reference just as a matter of record.5. Hire a technical product manager

Working with development teams in all sorts of organizations across business and government; I’m forever convinced about the value of a technical product manager and their role in product development. Without a technical product manager, you run the risk of developers, engineers, contractors, and the sales team diluting product features, roadmap, and other important product vision details.

How does your team avoid being too smart, too small?

Will Kelly is a technical writer and analyst based in the Washington, DC area. He has worked with commercial, federal, higher education, and publishing clients to develop technical and thought leadership content. His technology articles have been published by CNET TechRepublic, Government Computer News, Federal Computer Week, Toolbox.com, ZDNet.com and others. Follow Will on Twitter:@willkelly.

7 ways to wreck virtual team collaboration without really trying

by Mike Wilson via Unsplash.com

When I got my start as a technical writer, everybody worked in the same office, in the same building. Collaboration in those days was via shared network drives and eventually corporate email. I’ve been working remotely pretty much since 2012 with the exception of some on-site meetings and business trips. On a recent trip, I had a chance to speak with some other remote workers and the topic of collaboration came up. The consensus of the discussion that many organizations are still getting collaboration wrong with their virtual teams.

Here are seven ways that you are getting collaboration wrong with your project team:

1. Using email first communication

Email is the original collaboration tool making it a natural solution for virtual teams. Going email first for communication will catch up to virtual project teams eventually. Long email threads grow unwieldy. Likewise, forget document version control.

Email first communications also puts you at the mercy of the most disorganized person on the team. He or she is the person who always misses an email or asks other team members to resend their emails.

Email first communications invariably leads to follow up (even multiple follow ups) slowing down communications and collaboration.

2. Drowning out team member voices

Whether it’s differing personality types, micromanagement, or miscommunications there’s the potential to drown out team member voices. Virtual teams make it even easier by not centralizing communication, avoiding group level communications. Other ways you can drown out team member voices includes:

  • Delayed response to one-to-one online chats
  • Ignore one or more team members in chat rooms
  • Ignore real-time communications like video conferencing or the old fashioned phone call
  • No engagement with review comments in documents or presentations
  • No appreciation of team member’s preferred communication channels

Virtual teams also drown out team member voices when they don’t adjust after miscommunications.

3. Forgetting the art of the pitching new ideas to your team

New ideas for solutions, processes, and communications should be welcome on virtualteams. Team collaboration can break down when one or more members go around the team to sneak in a process or system change that may not fit the needs of every team member, or even cause more work unnecessarily.

4. Inflicting management by spreadsheet

Management by spreadsheet has been parodied by Dilbert and even has its own Urban Dictionary definition. Project tracking and reporting needs to be as effortless as possible for team members.

Even without agile development and DevOps, project reporting takes on a new importance with virtual project teams.

5. Using duplicate systems and tools

The mass proliferation of freemium cloud-based messaging and collaboration tools makes it easy for duplicate systems to crop up on a virtual team. Doubly so if the IT department back at the corporate mothership may not be attentive to the out of sight, out of mind employees and contractors.

6. Dodging questions and answers

Perhaps it’s because I’m a technical writer but I’ve become a student of how people answer questions. There’s what I call the dodge and denial method that can wreak havoc with virtual team collaboration. A team member dodges answering a question. The average corporate culture will excuse it as the person being too busy. Scratch beneath the surface, the person is often just disorganized or even dodging the question because they don’t know the answer and fear losing face to their fellow team members.

7. Distributing project documentation & @artifacts in the widest dispersal possible

If you or somebody on the team need to ask “where’s such and such document?” then you are doing something wrong. With the popularity of Google Apps for Work and Office 365, it’s possible for a team to have a wide dispersal of personal accounts and cloud space.

When a team doesn’t centralize project documentation and artifacts then virtual project teams may have members not using the more correct and up to date information.

Virtual team collaboration for the win

Industry trade publications are filled with stories about winning virtual project teams. Working on virtual teams on commercial and federal government projects, I’ve come to see that communications and collaboration can make or break such teams.

Will Kelly is a technical writer and analyst based in the Washington, DC area. He has worked with commercial, federal, higher education, and publishing clients to develop technical and thought leadership content. His technology articles have been published by CNET TechRepublic, Government Computer News, Federal Computer Week, Toolbox.com, ZDNet.com and others. Follow Will on Twitter:@willkelly.