Keep On Roleing

Sometimes I don't really know what I'm doing.

Well, that's not true. I know what I'm doing, but I don't always understand what is expected of me.

From my experience, this is a common feeling, especially in a professional environment. It's not always obvious what a manager or company expects from you, or even worse, it might be obvious but misleading.

Having struggled through that sort of thing myself, it's the last thing that I want to afflict the people I'm responsible for.

So, one time, at band camp a company I worked for, I tried to change that.

This is that story.

Alright Partner, You Know What Time It Is

Let's start with titles. As in, job titles.

Titles are mostly meaningless, or so I used to think. I pictured them as arbitrary labels, so arbitrary that sometimes you were entirely free to make them up yourself. Code Monkey, Project Wizard, Customer Bulwark, stuff like that.

And maybe that helps, maybe you get joy and motivation out of that and it results in you doing a better job.

But if you're dealing with a large group of people, who all want to have a consistent idea about what is expected of them, trying to figure out if a Bit Shifter can be compared to a Programming God is pretty hard.

That's not to say you can't still have the cool, trendy titles. You just have to back them with meaningful roles. Sure, Bob might be a Software Slinger, but he is also a Senior Software Engineer, which comes with a set of common expectations.

So, tying it all back together, inconsistency of role identifiers was a problem that I identified and wanted to fix. We'd recently established a quarterly review process, so being able to get clarity on expectations across the board was important.

In fairness, it wasn't quite as bad as trying to compare a Delivery Dominatrix to a Meet Cuter, but it was still annoying.

And if it was hard for me, it must have been much harder for the people actually filling those roles. How would they know what is expected of them?

More importantly, how would they know what would be expected in order to progress their careers.

Move In, Move Out, Hands Up, Hands Down

So, with a problem in mind I had a project.

Step 1: name it.

Keep on Roleing obviously.

Step 2, find a group of people who I can bounce ideas off and who are willing to help me make this happen. A simple call for volunteers via various channels and I quickly had a bunch of comrades in arms.

Looking back, I think I already knew that I needed people around me when kicking off a project and yet I had to learn that lesson again fairly recently.

Step 3, set some success criteria. Brainstorming with my brand new posse resulted in something very much like this list:

• All technology team members have a role that is clearly and publicly documented
• All technology team members have approved of the definition of the role that they are being allocated
• Overall satisfaction with roles and responsibilities within the technology team is 90%
• All technology team members have identified the role that they aspire to and can clearly articulate the changes/improvements they would have to make to get there
• 5 promotions or salary changes happen by the end of FY21 as a result of this project

TL;DR we wanted to track progress on the documentation, ensure that satisfaction was increasing within the team and to try and get some actual position changes happening.

Those of you with keen eyes will recognise those success criteria from my final post in the Objectives and Key Results series.

With success criteria in hand, it was time to formulate a plan. Technically we already had a plan, because it had informed some of the success criteria, so this is less of what I would call a sequence and more of a back and forth that I've tried to summarise afterwards.

Anyway, the plan was simple enough: identify all of the roles that people were currently filling, consolidate and compress those roles into a smaller set, clearly explain each role via a Confluence page, review internally and then finally talk to literally every single person in the technology team and get them to approve.

Execution of the plan was enlightening!

But, laborious :(

Back Up, Back Up

Oh hey, it's the third section. Gee I wonder what I'm going to write about here...

Sarcasm aside, the first challenge with the project was engagement. The team of people that I gathered to help me execute the project were at least partially engaged, though I did have to hound them a lot when it came time to actually write things down and review them.

The further away I got from the project team, the harder it was to get good engagement, which was frustrating because I needed those people (especially people in leadership positions) to contribute and review in a timely fashion. After all, they were the ones who had the expectations sequestered in their heads.

Even within the technology team at large, from memory, the response rate for the satisfaction survey was less than 50% each time I did it, which was disappointing :(

I mitigated the engagement problem by literally booking 15-30 minute meetings with everyone to force the conversations, but that ended up being a lot of manual work for me, so maybe it wasn't best approach.

In fairness, everyone was busy with their own stuff and my pet project was not necessarily a priority for them, so I can't really hold it against them. It's also possible that the problem was more important to me than it was to anyone else, so I'm grateful that I got the participation that I did.

Speaking of the project being more important to me than anyone else and segueing flawlessly into my next point, I didn't really check my assumptions before deciding to go solve the perceived problem.

What I should have done was gather intelligence first, then direct the project based on that data. Instead, the first full technology team survey was like four weeks in, and while it did eventually prove my initial assumptions correct, it was a risk that could have been avoided.

At the time I think I avoided doing the survey because the technology team was already suffering somewhat from survey fatigue and I didn't want to add to it.

Other than those two challenges, the project went pretty well.

But did it actually make a difference?

Tell Me What You're Gonna Do Now

At the end of the day, I'm honestly not sure if the project solved the problem.

Going purely by the success criteria, we did pretty well, with everything being green across the board:

• We described the roles for 90% of the team
• 93% of the team approved of the roles
• We got to 73% satisfaction from 16%
• 77% of the team had identified an aspirational role
• 4 promotions happened

That last one is a bit iffy because I'm not sure the project actually caused those promotions. I think they just happened.

Beyond the metrics, I'm not sure if it the project actually established an ongoing organisational shift. I left before the roles pages were really embedded in any ongoing processes, like quarterly reviews or job postings, so I suspect they quickly fell out of favour.

Change is hard :(

On reflection, that might be another point in favour of me being the only one who really cared about it, because if it fell by the wayside without me driving, maybe it wasn't actually necessary?

But in thinking that I just hear Principal Skinner in my head and that soothes my fears.