So it’s midway through week 2 and the fun continues. I came to peace years ago that I have a very solitary job as a technical writer. Even when working on teams, I work as an individual contributor. I’ve even had long term writing clients to whom I’ve never spoken with over the phone much less face-to-face.
Here are some ways I’m amusing myself:
Made a resupply run to my local Whole Foods that was a win except for no chicken breasts
Doing my day job.
Washing my hands…a lot!
Cleaning my house a lot more than I regularly do so my kitchen is sparkling.
Working on some personal writing projects that I hope to publish in the next week.
Thinking more about how the rapid (let’s call it hasty) scaling up of remote work may have lasting effects on the enterprise collaboration marketplace.
I spoke to a friend yesterday on the phone who was pick up a laptop for his wife so she could work from home. He told me that the store he was running out of laptops. These are the times we live in!
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
I’m a big fan of Atlassian Trello for managing editorial projects so I was happy to find that Trello integration is now available for Microsoft Teams. These two applications are an ideal match — both popular with end users — plus making Trello available from inside Teams is another way to enable project teams to use the applications that make them productive.’
Go to the Microsoft Teams Store. Click on Trello. A descriptive dialog appears that’ll guide you through integrating Trello into Microsoft Teams.
Select a Team in which to add Trello. For purposes of this post, I chose a Team named Testing.
Click Install. Now Trello is available for the Team you specified in the installation. Next, specify a channel for Trello.
Click Set up beside each feature you want to set up. During the writing of this post, I set up all the features.
Click Log in with Trello. The Trello Login appears. Select a Trello board for collaboration. Click Save. The Trello board you select appears as a tab available to the Team
Once you login to Trello, the board you chose appears inside a Microsoft Team tab:
Trello inside a Microsoft Teams Tab
Final thoughts
We work in an era where work management tools need to be easy to use and accessible to project teams and the stakeholders they support. Trello and Microsoft Planner are direct competitors so the inclusion of Trello integration in the Microsoft Teams Store is yet another sign of the new Microsoft. While too often in my experience, organizations hold a tight rein on things such as the Microsoft Teams Store, more and more.
I’m a technical writer and content development manager living and working in Northern Virginia. Over my career, I’ve written bylined articles for ITSearchOperations, DevOps Agenda, Mobile Business Insights, CNET TechRepublic, and others. My areas of interest include cloud computing, DevOps, enterprise mobility, and collaboration tools. Follow me on Twitter: @willkelly.
Long ago I came to see people as the greater challenge to my work as a technical writer more so than the technology I was writing about. It’s not that I don’t like people. I just came to see people in technology organizations
Here are the five types of people you interview as a technical writer (in no particular order):
1. The poseur
Over my career as a technical writer and freelance technology writer, I’ve had the opportunity to interview a lot of whip-smart people — some brilliant — and I’ve learned a lot from them over the years. I’ve grown fascinated by people’s “tells” especially the one type of interviewee I call the Poseur. Here are some of their characteristics:
Beats their chest about being a technologist
Abides by the rule that he who talks the most must be smart
Dismisses questions they can’t answer by changing the subject or lame excuses
Now mind you there’s more than one type of poseur. You might get lucky and find one who defers technical writer interviews to their employees politely. There’s no harm in these people — they can be great connectors — for technical writers. It’s the ones who lack self-actualization that can cause problems on content development projects as they become a blocker to success to save face and fight politically to prove their own relevance.
2. The old school geek/true believer
While so many folks fall for the mythos of snake people as the be all end all technology experts, give me an old-school geek with gray hair any day as a subject matter expert. I’m talking about the person who has been there, seen it, and done it.
While interviewing some old school geeks/true believers can mean having to put up some guard rails for the interview because they do have their war stories. Old school geeks are often the ones who respect technical writers with some domain knowledge about what they are writing about versus a generalist who’s not really vested in technology.
3. The product person
In my travels as a technical writer, I’ve come to see that there are just product people. They may hold the formal title of product manager, sometimes they might just be an accidental product manager — a product-focused person sometimes a developer — who has a vision for the product they are developing.
My favorite type of product person to interview is somebody who’s had a lot of customer contact and are very aware of the competitive landscape. These people can be a treat to me as a technical writer. I especially enjoy interviewing product people for articles I’m writing.
4. The services person
A services person understands the delivery side of the business versus the product. They may or may not be technologists by trade. I commonly encounter the services person in industries such as financial services, government, and telecommunications where security, compliance, and dare I say bureaucracy is the order of the day.
My favorite way to interview a person is in front of a whiteboard where they can break processes and procedures down while they are telling they are dropping some knowledge on me.
5. The evangelist
While I usually don’t see too many of what I call the evangelist when I wrote technical documentation, I do see them when I write articles, blog posts, and white papers. While I like interviewing the evangelist, it can always be a balancing act in my experience. You can encounter a poseur trying to impersonate an evangelist.
Interviewing an evangelist can be challenging. Some come into a media interview with a definite corporate line they want to push even if you are writing a vendor agnostic thought leadership piece. On the bright side, their enthusiasm can be contagious, and that can shine through in their interview answers.
In my experience, natural evangelists are few and far between, but you can cultivate evangelists. I saw that done when I was freelancing for CNET TechRepublic, I saw a corporate CEO go from a very rough interview to one of my go-to sources on a subject in about two years.
Final thoughts
While my passion for technology keeps me going as a technical writer — on the good and bad days — people also keep my interest in projects. It could be the people and personalities I work with on a daily basis or the people I interview for articles.
I’m a technical writer and content development manager living and working in Northern Virginia. Over my career, I’ve written bylined articles for ITSearchOperations, DevOps Agenda, Mobile Business Insights, CNET TechRepublic, and others. My areas of interest include cloud computing, DevOps, enterprise mobility, and collaboration tools. Follow me on Twitter: @willkelly.
As a technical writer, I straddle two worlds. In one world, I have to collaborate with brilliant solution architects, programmers, and engineers. In the other world, I have to work with marketing, designers, and trainers.
Straddling that line so much I’ve heard “Well they’re not technical” whispered more than once or said behind closed doors. It’s a value statement. While it’s easy to call it an unfair categorization for some as an outsider to the tech industry I’m going to say that sometimes non-technical people place this curse on themselves.
Carrying the curse
The curse that non-technical people bring on themselves is the real or implied perception that they aren’t contributors to technology project efforts. Take the case of non-technical people that don’t do their homework about the technology. Nobody expects them to be an expert. However, busy people do appreciate somebody who’s at least trying. You don’t know what you don’t know, and smart people can sense that. But when you lumber into a room and demand time from busy developers and other project team members before spending some self-study time, you can become seen as a time leech.
During my first official job as a technical writer, the engineering manager and his team were frustrated with my manager. During one particular nerve-wracking meeting, my manager tried to distort technical facts to her misunderstanding frustrating us writers and the engineering team. She was either too dumb or too arrogant to admit she didn’t know what she was talking about when it came to technology. After that meeting, my manager left the room first, when I was getting up to go the engineering manager pulled me aside and told me that if I could understand 50–80% of the technology on my own, I would be an asset to any programmers and engineers I would work with during my career. That was advice I’ve carried with me to this day.
While keeping abreast of technology has become more challenging especially in today’s cloud computing era, we live in an age where’s there’s a bounty of technical information available.
I’ve seen this curse strike project managers, technical writers, and even some executives.
Lifting the curse
On a team and organization scale, a collaborative culture can help lift this curse yet that takes action from technical and non-technical staff. Collaboration isn’t about one party doing something for another party. Delegation isn’t collaboration either.
I had a brilliant manager once. She was non-technical, a minority, and female in the wrong company at the right time (the wrong time for her, unfortunately). She provided more leadership to us writers than any of her predecessors. As a manager, she didn’t understand the technology we were writing about in our documentation and was clear about it. In the end that didn’t matter because she never claimed to the understanding. She had an incredible talent to remove distractions from us. Not to mention, she was a superb administrator. Her contributions to the team rivaled any of our past managers. She applied her strengths to some of our weaknesses and made our jobs easier.
Subject matter experts we dealt with liked her too because she was professional, organized, and conscious of people’s time. She had a talent for getting project teams the things they needed to get their work done. I learned from her the value of threading the needle — something I mentioned in a recent IDG Techtalk Twitter chat about soft skills in IT.
a3) When I’ve hired technical writers in the past, I looked for signs of a natural curiosity, diplomacy, problem solving, and other skills that they can use to “thread the needle” to navigate through an organization to get info and reviews completed. #IDGTechTalk
A non-technical person who can thread the needle to get what they need is an incredible asset. The SMEs saw my manager as somebody who listened, could marshall resources, and get things for the project logistically.
Regarding a technical writer role, it’s about a writer who can make the best use of other team members’ time. It’s about marketing people that at least ask, what can I do to help? Or it’s the non-technical manager who asks the team what they can do to remove project blockers?
Lessons learned
There are lessons in how my old manager operated for all of us especially non-technical people who think they might be carrying the curse:
Acknowledge what you don’t know and don’t try to bend technical facts to your lack of understanding
Ask how you can help, you might be surprised how much a round of edits to a document, a spare piece of hardware you have lying around in your office, or your talent for logistics can be a help to a busy programmer or engineer
Respect the time of other people that you need information from by doing some upfront homework before you ask them questions
Remember that collaboration is a two-way street so coming with asks isn’t collaboration, it’s asking for help
Fortunately, this curse isn’t deadly. It doesn’t even strike everybody. We all need to see it as a call to collaborate better with each other and draw out the diverse talents of the teams in our organization.
Hey there! My name is Will Kelly. I’m a technical writer and content development manager living and working in the Washington, DC area. After spending years focusing on technical and SDLC documentation, much of my work now focuses on thought leadership content and marketing collateral. My articles have been published by DevOps Agenda, Mobile Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.
