Notes from Build: How can we help more non-developers write Microsoft Teams apps?

A few days ago, I hosted a Table Talk session titled “How can we help more non-developers write Microsoft Teams apps?”:

As you can see, this session wasn’t recorded and so the content isn’t available to anyone who wasn’t there. That’s a shame (in my opinion) because we had a really interesting and insightful conversation about the potential, the challenges and opportunities associated with helping those who wouldn’t naturally class themselves as developers to start building applications for Microsoft Teams using low-code and no-code tools.

So, I thought I’d write up my notes – partly as an aide-memoir, and also for anyone who wasn’t there.

This was where we started our conversations. Microsoft is a technology company first and foremost and it is stuffed with developers producing technical solutions. Our conclusion here was that, in general, the technology is good enough for non-developers to be able to create solutions using no-code and low-code tooling. There are some rough edges but mostly, it’s not a lack of technology which is the problem.

In fact, sometimes there is too much technology! There are multiple different ways to solve a problem, and overwhelm of choice can be a turn-off factor for people.

That view isn’t always shared by Execs though. Some participants in our discussion have had Exec pushback that the tools aren’t good enough, based on things they’ve heard or read. These same Execs are also sometimes of the opinion that building solutions to problems “isn’t the job” of non-developers and doesn’t justify the additional cost of licensing, training, support etc. There is a mindset to change here.

Looking at the list of tools above, PowerAutomate was the #1 choice for entry into this space (I asked people if they could just keep one, which one would it be).

When we talked about any potential tooling gaps in the list, there wasn’t anything which really jumped out, apart from possibly some more and better integration with Datavserse, or something to do ETL.

This generated a lot of discussion. Some of the answers included:

• Lack of time to learn something new
• Lack of awareness that these tools exist and could solve user problems
• Lack of “thinking like a developer” when it came to planning out a solution and how to go from idea to execution
• Knowledge (or lack thereof) of the licensing models involved
• Lack of inertia, “it’s not my role”
• A fear of breaking things or causing damage or data loss
• Lack of support (both internal support and Microsoft support)
• Not understanding any costs involved (similar to licensing)

It was really good to hear about some of the ways people are addressing these challenges. In general, it was felt that people needed examples in order to see how the technology could apply to them and their problems. Whilst technically-minded people can join the dots between a feature announcement and its application, others will need to be shown the technology being used in a typical scenario in order to understand how it can be applied to their problem domain.

Some people have implemented training and “cheat sheet” documentation to assist users building no-code and low-code applications. These cover some of the basics around security, governance and reporting and help the organization to keep tabs on what’s happening. We talked about these being a little like the guard rails at a bowling alley that are used for beginners – stopping you going too far off the edge.

Having a “Centre of Excellence” was another approach that has been successful – giving users a place to find best practice, examples and help.

The general feeling was the IT needs to play both a supporting/encouraging role, AND a protective/defensive role. IT knows the pitfalls and the dangers better than users, but needs to ensure it is not stifling productivity or being heavy-handed in its approach. The greatest challenge facing IT here was the cost and time of supporting low-code/no-code application development.

We were pretty much of out of time by this point, but touched very briefly on the idea of Fusion Development in solving some of the challenges around knowledge of the ALM cycle as well as some of the other challenges. Finding time to make this a reality remains a challenge to overcome though.

The conclusion was that there were many, many opportunities in the modern workplace where no-code and low-code tools could make a difference, and there are people out there who could really benefit from them. There are some challenges to overcome, but organizations are rising to these challenges and putting in place processes and best practices to address them.

A huge thank you to everyone who participated: thanks to your engagement and insightful thoughts the session could easily have been twice as long. I hope you took as much away from it as I did, and look forward to us being able to do it again sometime.