Remove development references from SE

[kjacobsen]

As part of work on #50, modifying Senior Engineer to reduce development references. I have removed the agile reference, this can be reintroduced once change management wording is agreed upon.

[liammclennan]

Why do we want to "modifying Senior Engineer to reduce development references"? It's a development role.

[kjacobsen]

As the Managed Services roles are aligned, people like myself may end up with this title, hence the more generalised approach.

[andrewabest]

@kjacobsen what is happening with Managed Services roles? Is there any public visibility on this activity (Yammer etc)?

My initial reaction is to push back on generalizing Madskillz into something that people cannot connect with any more. One of the problems with the existing system (The skills and behaviours matrix) was that its content was way too ambiguous and up for interpretation, meaning it was hard to use.

[kjacobsen]

I don't believe there have been, however this ties into YourVoice and the Development practice announcements. Alignment of roles has been simmering on the backlog for a while from my understanding.

I have spent a few hours getting my head around the Consulting Madskillz as part of it (hence the other pull requests).

[andrewabest]

I feel for instance that "agile" is hard for someone in a role like me to demonstrate that I am "proficient".

@kjacobsen just adding to my feeling that I feel like we shouldn't be genericizing the existing set of characteristics and behaviors, but instead should fork them once we have a clearer view of who is going to be doing what within the 'same' role.

We should absolutely expect our 'software developer' engineers to be able to demonstrate that they can deliver using agile principles and practices.

Just feel like this PR is putting the cart before the horse a bit. Thoughts?

[kjacobsen]

I am completely torn with most of this. I agree, and also disagree. I love what we have done with the engineering stream, creating a highly technical focused stream.

I was going to write more, but there is a simple thing to highlight. The reason Managed Services is heading to alignment and using the same titles and MadSkillz is to simplify things, allowing for easier hiring, promotion and movement within Readify. Alignment improves many things for Managed Services and Consulting. I believe this pull request allows for this to be accomplished.

[liammclennan]

We need to have a conversation about role alignment and what we are trying to accomplish before merging a pull request that redefines our roles.

[todthomson]

@kjacobsen can you give us the list of "Senior Engineer X" roles you're targeting?

[kjacobsen]

@liammclennan That has happened within Managed Services, and our last 2 hires have been hired based upon Consulting titles (Developer).

@todthomson Not exactly sure what you mean here. If you mean different variations, I could see possibly two to begin with if we can't sort out the PD. I see a Senior Engineer Software Development and Senior Engineer Infrastructure. Of course, we might not end up with any people opting for the engineering stream.

[todthomson]

If you mean different variations

@kjacobsen This is my thinking... Here are some examples:

1. Senior Engineer (Software Development)
2. Senior Engineer (Managed Services)
3. Senior Engineer (Infrastructure & Operations)
4. Senior Engineer (User Experience)
5. Senior Engineer (Data Analytics)

I've "invented" these as I don't know the particulars of all the roles, these are just examples.

Once we have the senior engineer role types then we could extract the common base Mad Skillz and then customise a list of specialty skills or parametrised skill versions for each role where the aim is to have most of the skills common to all, but catering for where we have skill variant or unique skills per role.

Trying to lowest common denominator or genericise the Mad Skillz seems "fraught with danger" to me as it runs the risk of taking us back in the direction of the pre-Mad-Skillz-days.

[todthomson]

our last 2 hires have been hired based upon Consulting titles

I have no issue with this myself => Getting great Readify developers into Managed Services is the goal.

I'm just thinking that the progression could be from D => SD => SC (?) or SE (?) whether you're coming from a Managed Services background or Consulting background i.e. if you can and want to do the job "come on over, we want you here".

The bit in the brackets after SE is just there to help our clients understand where your expertise lies and where you are currently focusing your attention, Mad Skillz or otherwise...

These are just my thoughts...

[kjacobsen]

Your examples are along my lines of thinking.I could see us having 1/3/4/5. I don't see there being much difference between 1 and 2.

Only issue I can highlight with the format of SE (*****) title structure is that it could impact people in the future if looking for work on the outside. Quite a lot of recruiters will look at a title like SE and assume it is infrastructure focused. Just something to be aware of.

If we are looking for a common criteria, then that seems like more reasoning to move agile into the Software Development focused role and out of the common section. Agile isn't something that someone moving from a traditional infrastructure org is likely to have, and it is easier to teach than say, the experience of working and deploying something like AD. If I was looking at a strong infrastructure candidate, and Agile wasn't listed, I wouldn't be stopping the hiring just for that.

I am not trying to lower the common denominator, just trying to start levelling the playing field and prepare it for more diversity of skills.

[liammclennan]

Why add these on to SE only? Wouldn't the same thing apply for D and SD?

[todthomson]

I am not trying to lower the common denominator, just trying to start levelling the playing field and prepare it for more diversity of skills.

@kjacobsen totally :+1: we're just working out how to do that without "genericising" :sunglasses:

Why add these on to SE only? Wouldn't the same thing apply for D and SD?

I don't see why not? :wink: I'm just focusing on SE here. My feeling is that the role (and expectation level) is Developer => Senior Developer => Senior Engineer => (?) and the bit in brackets is specialty.

The low water mark (across the board) is role => the high water mark (current focus) is specialty.

[kjacobsen]

@liammclennan: There is most definitely the chance for that. Those to are hard due to developer being in the title. :-) I also suspect that these more specialised roles will not have people being hired in at the lower levels.

[liammclennan]

@kjacobsen if we change one we must change them all. Re " I also suspect that these more specialised roles will not have people being hired in at the lower levels." I disagree. SD is a senior role that requires candidates to demonstrate advanced technical skills. It is a great level to hire because we can easily test for those skills in an interview. It is very difficult to ascertain the SC skills in an interview so we tend to require people to demonstrate those skills on the job.

[todthomson]

SD is a senior role that requires candidates to demonstrate advanced technical skills. It is a great level to hire because we can easily test for those skills in an interview. It is very difficult to ascertain the SC skills in an interview so we tend to require people to demonstrate those skills on the job.

@liammclennan Agreed (and this has been my experience). I note that this approach is pervasive here in QLD (I can't speak for the other states but I presume it's much the same).

I also suspect that these more specialised roles will not have people being hired in at the lower levels.

@kjacobsen I'm presuming you're referring to "generally not hiring in at SE" much in the same way as "generally not hiring in at SC" (above) so it sounds like we're all in agreement.

Checkpoint: Are we planning to "hire in" at SE? I have been presuming this to be in most cases a "promote to" role rather than a "hire in at role" much the same as SC (could be wrong).

[kjacobsen]

Just to clarify things.

I do not think that we would be hiring our more specialist people, eg Infrastructure in at D or SD level. I suspect that in most cases if we were to do so, they wouldn't have the technical maturity to thrive in the roles. There is one exception to this.

Considering the skill set required for the infrastructure role I am in, I think it would be quite hard to hire this as a D or SD role (excluding the title issues), my role isn't really someone in a D or SD role could easily grow into (however we could with work + company growth change this).

[kjacobsen]

It is also worth noting that some of the areas we are looking to move into may require direct hire of senior staff who are subject matter experts, where we do not have the time, inclination or training to bring up a more junior person.

Example, if we wanted to support Oracle customers, we might need to hire in an person with Oracle sysadmin experience. We probably wouldn't aim for an SD in this case but want someone who can use to go straight to market.

[liammclennan]

"We probably wouldn't aim for an SD in this case but want someone who can use to go straight to market."

Being able to go straight to market and be useful by them self is precisely how we define SD. As @todthomson said, I am inclined to promote to SE rather than hire SE wherever possible.

[kjacobsen]

I suspect we would struggle to hire internally for an infrastructure role, those skills are not that common in the SD pool.

Looks like the next pull request is SD then if we want to hire into there.

[tathamoddie]

I'd like to weigh in on these discussions, and get the Managed Services role changes / alignment discussion out into a broader forum (Yammer).

I've been on leave last week, and trying to focus on a conference this week.

I'll be back on a regular cycle from 14th June, and will try to get the higher level thoughts down shortly thereafter.

In the mean time, I'd prefer to wait on any PRs that genericize our current 'consulting' stream away from the current software development focus, as it's described.

[tathamoddie]

I've shared the broader goals and some higher-level thoughts over here: https://www.yammer.com/readify.net/#/Threads/show?threadId=723632626

I've like to see us carry that discussion out, before we come back to the implementation detail in this repo.

[andrewabest]

Given we are pursuing this out of band, I'd suggest the PR that will eventuate from those discussions will be quite different from the one that is here today. Closing in anticipation of the future replacement.