Adding an item for complex architecture
Closed this issue · 15 comments
We talk about architecture as a skill for SCs, but it's generally constrained (in my mind) to the architecture needed for an application of moderate complexity, as that is what would be expected for a team of 2-3 people.
I'd like to add an item in the LC description for architectural skills related to enterprise/complex architecture but I'm wondering what the best way to word that might be.
What would you expect from an LC in terms of architecture, that is too much to expect from an SC? And do some of those things drift into PC territory?
Suggestions?
So our SC description currently states
I am confident making architectural decisions taking concerns like infrastructure, identity management, security, scalability, concurrency and maintainability into consideration.
I think what is being targeted here is 'single system' architecture, and this overview covers it pretty well.
It would be nice to have another similar item in the LC description that covers some of the following, more complex architectural topics:
- Distributed Systems (a very broad topic)
- Compliance (Industry regulation, PCI, etc)
- Integration
- Instrumentation
- ???
If you think that you have a number of items at PC @rbanks54 that are above and beyond what an LC should be expected to know, throw them in :) I suspect the differentiation between LC and PC may be in combining architecture and strategy for medium / long term planning.
@andrewabest Looks like a good start in terms of topic areas, but I'm deliberately trying to avoid leading the conversation in a certain direction at the moment :-) I want to see what everyone else thinks about the SC/LC/PC split re architecture skills first.
@rbanks54 so at a high level, would the split look like:
- SC: Single systems architecture
- LC: Multiple / 'System of systems' / distributed systems architecture
- PC: Strategic architecture
'Strategic architecture' sounds a little hyperbolic, a better term would be appreciated :)
?
Would you say...
Strategic architecture == Strategic technology & architectural roadmap, aligned with longer term business goals
Includes things like
- ability to find and retain the right skills in the business
- long term confidence in technology vendors
- perspective on industry trends and how they might influence the roadmap
- ROI and TCO considerations
- <insert more here />
?
Exactly, designing architectural recommendations that consider risk, productivity, profitability, potential, longevity, agility etc, along with the sound technical recommendations that are expected from SC and LC tiers.
As an aside I'd expect these things to be on the radar for most LC's too, but they would be on the journey to mastering this sort of thinking, whereas PC's would be expected to own it.
@andrewabest I thought that SC/LC should be focused on soft skills and we should save "distributed systems, instrumentation, etc" for engineers?
Hi @halkar - I see you are one of our Senior Engineers, so you probably have some strong opinions about how your role fits in Readify along with the existing 'consulting' stream :)
The bottom line from my perspective is our consultants need to be equipped with the necessary technical and non-technical skills required to build a relationship with our clients that allows us to deliver fantastic software and experiences for them. This relationship is primarily built on trust, and results.
Now imagine if I am an SC in charge of a team, which doesn't include a Senior Engineer. I'm asked whether SAML, OAuth 2.0 or OpenID Connect is a more appropriate solution for a mobile application. Now if I'm primarily focused on the soft skills, I may not have the in depth knowledge on hand to answer this in a conversation, and I may not have the skills on hand to discover the answer in a quick enough timeframe after the conversation to satisfy the client. The client is left dissatisfied, questions their investment in our premium service, and does not trust our capability - regardless of how smoothly the consultant handled the situation by exercising their soft skills. This is a slippery slope towards a failed engagement.
The successful delivery essentially lays on the shoulders of the team lead - be that an aspiring SD or an SC. They are responsible at the end of the day for making the final call on technical choices, and are responsible for backing those choices and owning them. The PC is there to provide advice, an experienced sounding board, and can rescue engagements if required - but this shouldn't be necessary if our team leads have the capacity to deliver them in the first place - solid technical skills.
The above situation worsens in larger engagements with more complex software and more hostile risk profiles. Questions get asked about distributed systems, load capability, compliance, estimating cloud deployment costs, etc. Larger teams are involved. More people. More balls to juggle! This is where the LC comes in, naturally growing from the SC role.
Now I see the Senior Engineer role complimenting the SC and LC roles - the SC's and LC's are 'brilliant generalists' - they can go deep, but also handle the interpersonal, 'people' side of the engagement. They may have reasonably deep knowledge in one or a few focused areas - this comes with experience on the job.
Senior Engineers however have extremely deep knowledge in a broad field - this could be Web, Distributed Systems, Data etc. They can be brought onto challenging engagements with very complex technical requirements to reduce the risk of delivering those requirements just by being there - taking the pressure off of the team lead to focus on the personal and political side of the delivery. Being team lead on a large engagement leaves you juggling so many things that are your responsibility to deliver that it can be somewhat overwhelming - having a Senior Engineer on hand to effectively deal with a set of those things, a trusted person who is absolutely trusted to deliver in that area - is a massive win for Readify.
What are your thoughts on how the SE role fits with the existing consulting stream?
@halkar we explicitly are not removing or lessening the technical skill requirements of the *C roles.
@liammclennan no-no, nothing about removing tech skills from *C roles. I just think that they shouldn't become more technical that *E role(s).
@andrewabest tl;dr I don't know.
I believe that engineer role is created for people who want to focus on their technical skills not on the soft skills. This doesn't mean that *E can't be a scrum master or a team lead. Neither this means that *C can't be a technical specialist. But in the existing consultant madskillz you will find a number soft skills requirements so many people wanted to have an option.
And coming back to your question - yes, LC can answer client's question about some particular technologies but this is not his main purpose. He should rely on his dev team's knowledge even if he is a Jack of all trades.
LC can answer client's question about some particular technologies but this is not his main purpose. He should rely on his dev team's knowledge even if he is a Jack of all trades.
This isn't how our team lead roles work. Our leads (SC onwards) own the engagement - the technology, the team, the customer, the communication. This isn't just my opinion, it is my experience. While this is now diversifying a bit on larger projects, it remains true for the bulk of the work we do.
Our leads need to be technically excellent - they may leverage their team to compliment and supplement their own skills - but at the end of the day if the wrong technology choice is made, and this causes an engagement to fail, it is on the leads head.
So to wind this conversation back - I think @rbanks54's suggestion about including architectural requirements for SC's and LC's is spot on - we do require these things from these positions. I know, because I have exercised these skills in these positions. If I did not have these skills, I would not have been able to lead the engagements I have.
I think perhaps we can move the *C and *E differentiation topic to another thread or forum :)
Also, finally found time to read through. +1 to what Richard and Andrew said.
Probably need to push these into the Managed Services - Technical Lead roles as well.
From experience TLs need to be very well aware of the architecture all (multiple in some cases) of the clients systems that are supported by Readify.
As for myself, I am also performing a significant amount of the strategic architecture work along with Tatham. Whilst it might not be an expectation of other TLs, this may occur on a case by case, client by client basis.
As per #105, I'm closing this due to inactivity to reduce the signal-to-noise ratio on the madskillz repo. If you'd like to reopen it in the future, please start a new issue and reference this one to pick it up where it left off.