Separate consulting from development

[leftclickben]

Create a Consulting.md file with the SC, LC and PC roles, separate from Development.md which now has only GD, D and SD roles.

This doesn't change much of the actual content, except some high-level explanatory text and the list of links on the main README.md page, which is now organised under subheadings for each of the practices.

[andrewabest]

I'm not a fan of the separation implied here between the development path and consultancy. The path from D to PC has always been a continuum, with skills built in the previous roles accumulating, extending, and supporting our consultants capabilities in their future roles. Being able to view this continuum 'on one page' always had a lot of value, as you could got a good view from start to end.

as a more client-focused career path
Absolutely all of our roles are client focused.

Being a consultant, you will be working with clients and dealing with people a lot, however you will still be expected to produce technically excellent solutions.

This is something that absolutely would never have to have been stipulated / written down previously - why do we have to now?

There is also a terminology issue we need to address - our engineers are still consultants - just more technically focused.

[bplowry]

FYI Development.md was recently renamed from Consulting.md (#91). The reasoning was that we have consultants in a number of practices. Maybe a different name would be more appropriate if the change goes ahead

[random82]

Agree with @andrewabest,

I'd go back to consulting.md though, especially at LC and PC level I think there is a cross practice flexibility expected, at least in terms of non-technical skills. Even for technical skills, description was open enough to contain different types of skills and experience so I'd rather look for a more effective generalisation rather that splitting definitions.

[leftclickben]

Thanks for the feedback.

I'm not a fan of the separation implied here between the development path and consultancy.

I guess that's exactly where I'm coming from with this. There is now an Engineering path, which also follows on from Development, so in my view having Development and Consulting together makes it the "main path" and Engineering "secondary" (because it is more "separate"). Perhaps this is consistent with the current view of things, in which case let's close this PR.

But I think it's worth the discussion. Do we want Consulting to be (seen as) the "default" or "main path" after Development roles, and Engineering as a "side path" that gives people options outside of Consulting? Or do we want the two to be seen somewhat equally?

I've only started at Readify recently, and as an outsider the current arrangement didn't really make sense. If anything, I thought that "engineering" would actually be more closely related to "development" than "consulting" is. Now that I understand the history, I can see why it is the way it is, but another outsider will not know the history.

This is something that absolutely would never have to have been stipulated / written down previously - why do we have to now?

Fair enough, I only added that sentence as the counterpoint to the sentence in Engineering.md in the corresponding place. Happy to remove or change it.

OOC, though, are you saying that we don't expect our consultants to produce technically excellent solutions? Or are you saying it's implied enough elsewhere?

There is also a terminology issue we need to address - our engineers are still consultants - just more technically focused.

Agreed. That could be added here or done separately to this.

[andrewabest]

@random82 I'd like to do this, but I get @tathamoddie's rationale in splitting them - we have a number of practices now, which consult. Development is one of those practices.

The interesting part here is that we have re-introduced it, once again adding the ambiguity that #91 seeked to remove.

@leftclickben that is a big question, and a very good one to ask 👍 a lot of it comes down to our commercial model, and our goals as a practice. I think our capacity for each role in each state may turn out not to be a true 50 50 split, but at the end of the day they should have equal merit and recognition.

I suspect the markdown format / 3NF going on here is doing us a disservice - ideally I'd like to see the Development.md and Engineering.md, and have both of them contain GD/D/SD - I don't think a little redundancy will kill us given the amount MadSkillz changes. As a bonus it will likely simplify ReadiMe.

OOC, though, are you saying that we don't expect our consultants to produce technically excellent solutions? Or are you saying it's implied enough elsewhere?

Not sure if , but I'll give you the benefit of the doubt here ;) absolutely we expect our consultants to produce technically excellent solutions - just as they always have. The introduction of the new roles in no way diminishes the expectations or capabilities of the existing roles.