Integrating Trello with Confluence Cloud

Photo by rawpixel on Unsplash

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.

The curse some non-technical people place on themselves unnecessarily

Photo by Natalie Jeffcott on Unsplash

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.

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.

Dropbox Paper and the art of the project plan template


I’ve been a fan of Dropbox Paper and minimalist word processors for a while now. In fact, I use Dropbox Paper for many of my personal writing projects. Recently, the Paper team added a Project Plan as a document option.

Dropbox Paper excels at taking a minimalist word processor that’s ideal for non-writers. For example, I’d love to use Dropbox Paper for collaboration among a project team. It’s easy enough for a solution architect or other technical staff to handle, in progress documents could be open to the entire team for comments and revisions. Then a technical writer like me can export the documents into a more palatable format to use in final documents.

Now when it comes to project plans, I was a wee bit skeptical that Dropbox Paper could get my attention. Tools such as Microsoft Planner, Trello, and Asana are at the top of my mind when it comes to project management tools. Well, I don’t see Dropbox Paper’s Project Plan competing with those tools, but I do see it as another ally in the war against spreadsheet project management. The Paper team takes their same minimalist approach to a clean, neat Project Plan template as they do with the rest of the application. Using the Dropbox Paper Project Plan template can also remove the temptations of overly complicated Word or Excel templates or just using email to manage projects.

You share a Project Plan just like you would any other document. It’s simple and easy to move and edit tasks around on the interactive project plan. You can just click inside the project plan to add a new task item and assign it to yourself or a team member. There’s also the option to add a description. So simple, a project lead could put the project plan on a conference room wall screen or share it during a web conference and make changes on the fly without stumbling over menus and commands.


Below the interactive Project Plan, the template includes an area where you can put more project details by inserting Dropbox files, media, tables, another timeline, and lists. There’s also a to-dos list where you can @ team members to let them know what tasks you assigned to them.

Final thoughts

Brushing aside my sheer joy over the minimalism of this project template, I have to say that it would work best with team buy-in. After coming of age using Microsoft Project because nobody on the team wanted to learn the application and Gantt charts in general, I began to see that project management is often best handled at the team level. Training on using the Project Plan would be minimal — a demo at a team meeting — but it means the whole team has to be up and running on Dropbox Paper.

I’m still waiting to hear more stories about Dropbox Paper in the enterprise. In a job like mine, Paper — not just the Project Plan — could serve as a valuable tool for getting information from busy content contributors who don’t want to trouble themselves with Microsoft Word.


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.

Avoiding Mission Impossible technical writing projects

Photo by Aaron Mello on Unsplash

I’ve had the great fortune in my career to work on some very tough projects — in what I like to call documentation unfriendly environments — and won some and lost others but learned so much about technology and how to work independently as a technical writer.

Before I accepted my current position, I had the opportunity to speak to an organization which has what I quickly came to ascertain what could be a “Mission Impossible” documentation project where there would be more chances for things to go wrong than there was to go right.

After speaking to the recruiter who set up the meeting for me, I began to think how had I won the mission impossible projects versus being “the previous technical writer.” Keys to success include:

Strong technical team

A strong technical team — not to write the documents mind you — but like it or not the IT industry is peppered by a lot of smart people and a lot more people who think they are smarter than they are. If you have genuinely knowledgeable and capable people in the critical technical roles, then half your battle for extracting technical information is won in my experience. If the wrong people are in critical roles, the holes and gaps that sometimes happen in technical documentation can expose the shortcomings.

Proper technical writer/developer relationships

Relationship with the technical team where you as the technical writer isn’t an unnecessary drag on personnel or other resources. Technical writers who need their hand held or can’t work independently are only going to be set up to fail when it comes to a mission impossible project.

Product management and developer collaboration

Strong product management and technical team cooperation and communications. If Product Requirements Documents (PRDs) or stories are just being thrown over the transit without much dialog between product management and the senior members of the technical team, then the hijinks can ensue.

Access to test environments

Access to test systems and the bug tracking system because reverse engineering of technical documentation does often occur especially if the document efforts begin well into the development lifecycle.
Reality vs. vaporware can also come into play on such document projects. If for some reason, you are continually denied access to the system, don’t take it personally, but be on guard that the product may in whole or part not exist except for visions in an executive’s mind.

What are your keys to success on “mission impossible” documentation projects?


My name is Will Kelly. I’m a technical writer and content strategist living and working in the Washington, DC area. My current focus is thought leadership and technical marketing content. I got my start writing user guides, administrator documentation, online help, and later moved into SDLC documentation. My articles about enterprise mobility, BYOD, and other technology topics have been published by IBM Mobile Business Insights, Samsung Business Insights, TechBeacon, CNET TechRepublic, and others. Follow me on Twitter: @willkelly.