All the fun stuff happens with shiny new tech, right? Nah. You can get audiences excited about older tech if you serve them well.
Last updated
“Your developer advocacy might not look like anyone else’s, and that’s okay. Ours was messaging.” -- Olja
Their developer advocacy structure
Messaging
Enterprise design thinking
Developer essentials badge
Sample in five languages using 3 APIs
Loop
Restless Reinvention
Diverse Empowered Teams
Observe
Reflect
Make
Hills
Playbacks
Sponsor Users
We don’t look after just devs.
The way their product works, they have multiple users, they have application developers and administrators.
If developers came out of university or they were starting in the ’90s,
They were used to having to learn and spend a lot of time finding out about technology, and they had time and they were measured on how well the stuff that they created worked.
The developers that are coming out of universities are used to trying things out for a little while, and then things working.
They don’t want to spend three months learning about something and then building something.
They want to find it, try it, and it then works straight away. And they were having a few problems with this.
For existing developers who like their product, they would support them with new functions.
New developers, who needed a bit of help, needed to accelerate their progress.
Being measured on Time to working code, and so they felt quite sympathetic to their problems.
Your developer advocacy might not look like anyone else’s.
Messaging
Enterprise design thinking
Developer essentials badge
Sample in five languages using 3 APIs
What is MQ and how does it work?
Mainly, they have a server component that is installed and configured, and then they have applications that interact with the server.
And basically what this is for is moving data in messages between systems and applications; in a very low-level explanation.
Two types of users -- admins and developers.
The admins are looking after the server-side of things, and application developers are developing applications.
How they’re interacting, and how things have developed over the years that aren't quite working anymore.
In terms of what it does for business, it connects the pieces and makes everything work together.
Loop
Drive business by helping users achieve their goals.
Restless Reinvention
They observe, reflect, make.
They try to work with diverse teams because at that point -- get the best information and different points of view.
Diverse Empowered Teams
Move faster by empowering diverse teams to act.
Observe
Immerse yourself in the real world.
Reflect
Come together and look within.
Make
Give concrete form to abstract ideas.
Hills
Aligns teams in meaningful user outcomes to achieve.
Playbacks
Stay aligned by regularly exchanging feedback.
Sponsor Users
Invite Users into the work to stay true to real-world needs.
It is the first stage of design thinking.
Putting yourself in the shoes of your user.
Imagine how things work for them, and understand what their problems are.
They work with empathy maps. they try and figure out what their users say, think, do and feel.
Helps them understand when they start building solutions for their users, how best to go about it.
These are statements that they set to themselves after we’ve been through design thinking processes
Have shared understanding between different stakeholders so that everyone knows what it is that we’re working on, what we’re working towards, and what the mission is.
And so from the very starting point, when they were trying to figure out what they wanted to improve
They wanted a developer to be able to understand a little bit about MQ and start a sandbox environment and start a sample application.
They created a platform that wasn’t anything very complicated.
What did they help them to understand?
Just the very basics about what their message is, what MQ is.
How they can stand up and setup, without understanding everything that admins have to understand.
They gave it to them in Docker, with some default configuration in there so that they didn’t have to learn everything.
They were getting good feedback through the websites and through some events.
Admins -- they came in for a user-group meeting,
Try and tell them about everything new that’s happening.
Asked them some questions, what they thought problems were when developers deliver codes.
They tried to get them to empathize with developers.
Why would they deliver such bad codes, that they wouldn’t work? And they didn’t think they were going to engage with the process but they went all out.
They created a badge.
They didn’t start from scratch. They had some materials from the LearnMQ platform that I started with before.
They started really simply, which sounded quite weird. they started with questions, they went around their team and asked everyone what they thought the questions would be for developers to learn.
They created a challenge for developers to actually go and look at some codes. they did it in such a way that they would have some backup and troubleshooting.
They put those samples in GitHub in three ways, so that if they didn’t really want to get their hands dirty and code it from scratch, they could fix some bugs.
Quote - “People are taking this up, and they are now talking to students, taking it to universities, and possibly doing customer workshops.”
MQ Verbs tell you how to interact with the server. And they often say it’s a very elegant API.
Only has 26 verbs, and then you can do everything with those.
Behind each of those, there is a library of material that you have to go through, in order to understand what you need to do.
Admins, they understand all of this, they know how it works. But for developers, they see this, and they tend to move on to something else.
But they came up with all their samples and all the patterns, in different languages. And they’re consistent.
They picked some of the basic patterns, and obviously, they started with Java.
They wrote a lot of their initial material for JMS.
They also touched their MQI, which is the native API. And they have thin wrapper libraries for Go and Node.
They would start with Java, they thought we’d finished, test it, and put out Java.
They went and worked on Go and Node.
Their teams were surrounded by experts, and developers who developed MQ
They wanted to go through the pain that their developers go through, and not ask too many questions.
They tried to look for pointers and tried to solve their problem on their own
They wouldn’t actually ask for more help until they would spend two or three days not being able to do it.
