Hello everyone. Thank you for tuning in again to another episode of Teams
Superheroes. If you haven't watched many of these videos, the whole premise of
them was, as I was speaking to a bunch of customers around the globe as part of my
role in Microsoft's customer success group, I heard a lot of similar questions,
challenges, concerns, and opportunities when it came to Teams and the platform
component of Teams, the business I look after, and the whole premise here again
is I wanted to start addressing those questions from our Team's engineering
PM's and also from your peers around the world and the one you're about to hear
is addressing one of the most common questions I get all the time around
centers of excellence or how do we manage this concept of citizen
development in our organization? Because yes, Microsoft, it's great that you want
to allow everybody to use power platform but who's gonna manage that? Who's gonna
support it? How do we enable different business groups within our organization
to align with IT and create these incredibly powerful solutions that help
them innovate at work and make their lives easier? And so I want you to hear
this very refreshing perspective and honest perspective from Tom and Ron over
at Wiley - John Wiley publishing in New York. Fantastic couple of gents and
they'll walk you through their experience creating their center of
excellence inside Wiley. The reason why we got to doing what we do started
with the intranet, started with a terrible intranet. Yeah. It all starts with a
terrible intranet. And we were all in different departments, so like, at the time, it's not the case now, but at the time internal
internal communications was within human resources and technology communications
was within IT. The other key people on the team were from application
management in IT and from communications within product technology which was another
group entirely. So from day one we were a distributed team with no formal
reporting structure and fast-forward to three years later
today a lot of people have moved around Tom and I have continued to work
together specifically around Office 365 and that's been the working model that
was almost like randomly created but because it was successful, there
were times over the years because that model was successful, the head of HR,
once we were toward the end of wrapping up the launch of the intranet,
she sort of plucked, I was still within HR and still within communications on
paper as a formal reporting structure but she plucked me out of that group and
had meetings with Tom and I to say like this works, this non reporting structure,
non hierarchical problem-solving team works, so just continue to do that. We
don't work within IT. We kind of, and with Tom and I aren't currently even in the
same department. I'm in the communications and branding group and Tom's in more of
like the operation side. [Off camera] Is it just you two by the way or are there other resources there? We're the only two that are, I guess full-time, toward
this problem. [Off camera] So you kind of pull in resources? And we pull in people. There's
a couple people that are constantly being pulled in but like Rebecca's
constantly pulled in but she's not literally on it every day. So usually
what we'll do is someone will have a problem and they'll almost by word of
mouth, will reach out to Tom or I, because they've been exposed to a
prior project or because they've read about something on Yammer or something to that
effect and they'll reach out and start with a question okay I have this
problem, you know, what can I do? How do we fix this? Yeah or
I need help with this process, or is there an application that does this? Or
something like that. It is just a question and then pretty quickly we'll
loop in the other person and put a team together that's usually about 50%
their department right? So if it's HR, like half the people in the room are HR
people that are on this project or this problem and 50% me, Tom and
whomever else we think you know could contribute to a solution. [Off camera] So what does
that look like? So they come to the problem, you've got now your project team
so to speak essentially set up to solve the issue. What does that process
look like from there? So it's evolved. It has evolved for the better because there was
a meeting very early on and it was Ron and I and someone from HR and she's like
these are the requirements, if anyone tells you differently tell them they're
wrong because this is it, this is what you have to build and this is what
you have to deliver. Yeah like, ok so we did that, and then it was back to well we
need to do a few more things and we needed to do this and and it just and it
was just a chaotic mess, yeah, until one day. One day we were like ok, there's got
to be a better way of working, and so we met with some of the people in IT about
different developmental or development methodologies and we sort of
took a crash course in agile development and then we modified that we're like ok well
we don't have all of these different pieces to do this the same way that IT
is doing it for major application development, but we have things that we
can use to simulate that and what we shed in manpower we can make up for in
flexibility. So we started to use Planner as an agile Kanban board and we just set
up the buckets as feature requests, in development, backlog, and you
know and then we added everyone from the HR team that was on this
particular project or the people that we brought in like the designer and the
user testing guy we'd add them all to the same plan
and then we change the structure of our meetings to be like okay this meeting is
going to be about what features we need and we're gonna document that and we're
gonna record all those features and put them in the backlog and put them in the
backlog and then this meeting, then after that, everybody that's tagged to a
feature [Off camera] the feature meeting was the first meeting is that right? That'll be like the very first meeting
yeah we're like let's talk about the features that we need and let's debate
that right? As opposed to like you're telling me you need this feature and
then the next meeting you're telling me we don't need this feature, right, like we'll
get everybody there for this feature meeting yeah and then is this feature
what you really want? Right. Like is this what really needs to
be in the application or is just what you think? So, and are you, is everyone
on the same page that this is a valuable feature? That level of communication was
important. So it put some structure to it that everybody was immediately able to
see and the meetings after that and the progress after that just went, it like
changed night and day. It was suddenly everybody was not only aware of it but
they were invested in it because they had a part in the planning they the HR
people were suddenly invested in the success of the project and understood
what happened you know when something went wrong who needed help at a certain phase
and it was too, from a development point of view, you knew that the feature that you were
working on that was requested because there was discussion around it wasn't
just like you knew that you're putting something in there that had value rather
than something that in the next go-around
oh you know what we didn't want that anyway or oh you know we thought about it and
really needed to be this instead of what we told you to build. Like you knew that
those are vetted, discussed, and ready to go and so it wasn't like as you as I was
building it into PowerApp, like I know this is just gonna go
away next week. Which is what was how it was in the beginning which is, yeah, why
we were hating life. So the amount of work that was where it used to
be done and undone and redone like disappeared, yeah, almost overnight and now
all the work was valuable from that point on. [Off camera] Do you guys worry that if you ever, and I'm asking you this because I
know this is what a customer be thinking who works for particularly a larger
organization right, is you know you get to a point where your team has been so
successful on your creating I don't know 50, hundred plus solutions for various
departments around the company, what if some of them start breaking right?
Or needs some fixing right? Does it, you know, initially that's probably easy to do but what happens when
you've got hundreds or tons of users? You're gonna have to know what you're
getting into you know and I think that's the same thing with the entire Microsoft 365
suite. It is there for you to use and you are capable of using it so if you don't
if you look at this with an older world view of like application
development or of technology where you would go to the IT department or you
would go to a development group and they would build you a thing and then you
would use that thing like that's one way you can look at it and in that view of
things you don't really have any responsibility for the product you are
a user of the product, you are not invested in the construction and maintenance of
the product. You use it, it if it breaks, you send it back. In a newer way of looking
at it where every user has access to these
tools to do like whatever they want at any time you know they don't need to
come to us to build a PowerApp or to build a form or to help them build a SharePoint list.
But we're there to help them do these things but the responsibility is
still the same. It is your tool. We've helped you build it. We've helped you
get there, but it is still your tool you do have the responsibility of ownership
of this tool and as long as we've done our job in helping you get to the
solution then, you know, then we've done our job.
Not that we're abdicating responsibility for the future of this thing because we
will always be there to continue to help whether it's something that needs to be
created new or something that needs to be maintained ongoing but it is not that
old model of we built it you use it. It's we, we all built this thing and
you have full capability to help maintain it. [Off camera] If you recreated your group from the beginning, is there any advice you'd give your peers as they start thinking about creating a team like yours?
Well first, I mean, don't take yourself very serious yeah no definitely do not take yourself seriously.
[Off camera] I think that's just a life motto right there.
The other thing I mean from the get-go we when we knew we were launching the
intranet we knew it was gonna be in Office 365 like we were like we have to
use these tools because we're gonna be telling people to use the tools so like
we have to walk the walk, talk the talk, that's true, and just you
know jump in there and you know look look across the entire universe of
what's there and use it. You know become really familiar with it and and that was
really what started us off was like well we're gonna be telling everyone to
use Office 365 so we really need to use these tools yeah and we need to use them
in the way that we're telling people they will use them in the future not the
way they're using them currently. So in in the case where we launched the new
intranet we stopped using email entirely and we switched everything to Teams.
We made a team for the core product team which was us and then additional
stakeholders they were in the team, we had channels set up for each aspect of
it whether it was you know feature development or
content or whatever it was so the project itself became education about
the product. Like if you wanted to replicate this group or in your own
company, I would say probably look for people, and I can't underscore this
enough, and I think that's where you and I do really well, it's forget the
technologies, forget the tools that are there, its basic problem
solving. This is such a great point. And that is really where it comes
down to because at the end of the day the tools that are there are to solve
problems, are a means to an end, but you have to think about like when you are
listening to someone, that's also important just listen when some comes and really
listen to what they're really trying to get at but you know what is
the problem that we're trying to solve? It's not like oh we can use all this cool technology
and try and solution it right away but just yeah
what are we really trying to get at? And I think all too often we forget that
skill and really it's problem-solving like if you can get, put together a team
where you've got some people that can just listen and think critically and
you know envision a solution and then try and think okay like this is how I
think the problem should be and I know at my disposal I have all these tools
like I look at I've looked across the 365 universe I know I've got Power Automate,
and I know that I have SharePoint and I know we've got all these other things I can use how can
I use these features to pull it in? And just yeah problem solving and I think
we don't have enough of that.