This discussion is locked.
You cannot post a reply to this discussion. If you have a question start a new discussion

'Leadership' vs 'Management' or 'how I became disillusioned with my CEng application'

Former Community Member
Former Community Member
Hi,


I am currently in the process of applying for CEng accreditation, I've got 10 years of experience as a Senior Software Engineer, and having put together my application, worked with my mentor and following the UK Spec closely, I find myself in difficulty.


tl;dr, I think I've demonstrated technical leadership on my application, as does my mentor, but my PRA disagrees because I don't manage people or money; this feedback is contrary to the myth buster section about managing people and money being a requirement for ceng. Is anybody here willing to take a look at my application as a second opinion and suggest what they think is best to do next?


---


This topic is important to me, and I have a serious question to ask here. While I don't wish to court controversy and this post is meant in good spirit, I am going to use a bit of humour/hyperbole in this post to illustrate my point and express my deep frustration with what the IET appears to claim, vs the reality of PRA assessments.

 



Background:


I refer to myth 6 and 7 on the registration help page

 

Myth 6 - You must line manage people to become IEng/CEng


You don’t have to be managing people, you could be demonstrating strong technical leadership or controlling other aspects of projects.


Myth 7 – You must manage a budget to become IEng/CEng


Managing a budget isn’t the only way of showing that you’ve had financial responsibilities. Experience with mergers and acquisitions, contracts, tenders, legacy and end of life parts replacement and experience from running your own business counts.


 

The gist of this I took to mean 'Technical Leadership' comes in many forms, and there are a lot of talented people out there that may not have the power to hire and fire people and receive notifications for how much the team spent on AWS this month, but they do other useful things like lead the design of technical software, imagine what new products would look like for users, innovate, provide guidance to their more junior colleagues, and be the go-to person when somebody has a problem because they're seen as an expert in their field, and the list goes on.


This is not to belittle the work of being a line-manager, but it seems to me that there are plenty more interesting examples of technical leadership. Contrary to the myth-buster section, when it comes down to it in practice, the IET seems to be obsessed with leadership in the strictest sense - i.e. "is there a line from 1 or more people on an organisational chart, and are you responsible for the cost associated with this?".


A 'Manager' in my company is somebody in charge of a team with the power to hire and fire. with this in mind, I am not a 'Manager', that is to say, that while I interview people of all technical abilities, and my manager asks me "should we hire them", ultimately it's my manager that actually signs the document. I have even been asked "how much should we pay them" in regards to interns, and when I saw the proposed amount was not in line with the London Living wage, I fed a better figure back. That figure is on the contract but I did not technically have the final say in the renumeration, but there's clearly leadership in spotting this, and successfully influencing those that do write the contracts to change the renumeration.


As another example, I have mentored multiple interns/graduate developers, and supervised them on their projects and been responsible for their project delivery, though again, while I have performed the responsibilities of a manager in relation to supervision, guidance, mentorship, career guidance, my job title is not 'Manager' and the organisational chart shows them reporting to somebody else, even if they never speak to this person more than once every month. This is just reflective of an HR department that wants to keep things simple and a flat organisation. Additionally we practice pair programming, and I frequently pair with junior developers almost every day to raise their technical abilities.


I've been on steering committees for code standards across the firm, I've been a 'patent lead' being one of the first to submit a patent in my practice area, and then assessing other people's patents and making go/no go decisions. Each decision is a commitment to invest £20,000 or so, or otherwise a statement that the invention is not worth patenting and that our competitors will see it that way too - but again these are joint decisions with 1 or 2 others; they have to be joint decisions because it would be irresponsible to put that kind of decision making into one person.


I've been the lead developer of a greenfield project where we were looking to hire a team after a 6 month initial development and design period. A lead developer is somebody who not only codes, but makes the technical decisions, who gets the right people in the room to reach a consensus, work with the business to understand the requirements, who draws, designs, and is technically competent that they can do some seriously heaving lifting in terms of large contributions to the product's codebase, either in terms of number of features implemented, or guiding others in implementation approach. But a Lead Developer is not a Manager. It is a role, my title is still 'Senior Software Engineer' not 'Engineering Manager', and I am taking on the functional role of 'Lead Developer'.


On top of this I've put together specifications for work we needed carrying out, looked at the viability and costs of hiring externally, internal secondments, interns, outsourced contracting in cheaper regions etc... Again the 'we' here is myself as the lead, my manager, a business representative such is the nature of project teams at inception - they're small and lean. This project was undertaken with me in a secondment position, I was approached by my manager one day and the discussion went something like "hey, there's mutterings about building a thing that solves problem x, we need somebody to lead the development and take technical charge, not just building it, it's a good opportunity for you to build a team around you". Unfortunately my project was put on hold due to a combination of covid, a cyber attack, and a significant loss of technical staff in the team I originally came from - when my manager asked if I could help, I volunteered to go back and support my original team, so the project was on hold and I never got round to actually hiring these people, but I still went through the preparation to do so. I produced contracts for tenure, looked at the cost-effectiveness of hiring in different locations, engaged 3rd parties with formal specifications for the product they would be contracted to deliver, I submitted a patent, worked with 3rd party lawyers and other external parties.


The reality of budgetary reviews is that sometimes you review the budget and the outcome is "no, let's not do it", or "it's not worth it", that's why it's a budgetary assessment! Like a maths exam where the working is more important than the final answer, surely the process of performing this review is more important than the outcome for CEng application purposes. Sometimes great projects come to a halt because there's suddenly no more money due to external factors, and the focus (especially in a pandemic) turns to ensuring people can keep their jobs - hiring freezes, spending freezes, budget reviews etc.


These are a few examples, not to toot my own trumpet, but this and more is covered in my application in a much more formal way, my mentor has stated that I have "sufficient evidence for a CEng application" and so the focus has turned to my verbal presentation.

 

The problem:


Contrary to my mentor's advice, my PRA has reviewed my application and returned with "Talk about planning and responsibility for management of people and money. I do not see these responsibilities." even though talk of evaluating costs for hiring are on my application explicitly. They have promised to provide more detail, but the remark is sufficient to know this isn't going to be a simple case of rephrasing things.


Perhaps they're mistaken, but I trust the PRA to be right, I'm assuming they know their stuff, and that their advice is correct and representative of what the IET assessors will say, and if they're looking for 'people and budget' then they can't possibly think i've demonstrated technical leadership anywhere else.


I realise this is hyperbole, but in my mind based on the above feedback, to get CEng it would be far easier for a low level manager who happens to work in an IT organisation and enjoys coding in the evenings on personal projects, to gain CEng accreditation than it is for an actual engineer with a genuine passion for software craftsmanship who can demonstrate technical leadership who just happens to not be strictly in charge of the team and budget on an organisational chart. Clearly this is not desirable and shouldn't be the case in practice, but the obsession with management of people and budget does make one wonder.


To this end, it would be good if somebody could clarify officially.
  • Do you need to be a manager or not?

  • Do you need to manage a budget or not?

  • Did I demonstrate sufficient technical leadership in my application or not (one would of course have to see my application to do this, which I am happy to send across)


It seems to me that technical leadership comes in many forms, and while the IET may have a myth buster page, this really is not translating into reality, and even if my PRAs is mistaken about this (which seems unlikely as I assume they are an expert in these matters), my concern is I'm going to stand in front of a panel of interviewers who are going to draw the same conclusion with the same preconceptions of what technical leadership actually is.


A significant chunk of my application has been dedicated to trying to demonstrate the leadership (C) competencies in the absence of being a 'boss', and much of it could probably have been cut if I just got a job where I manage technical people and money - and this seems rather unfair.


If anybody would like to see my application for better context to offer their opinion, I would be most grateful, as after 10 years of collecting evidence, to be told 'you don't manage people and a budget' has left me very disappointed. It is a fact that not everyone can be 'the boss', and this is extremely true in Software Engineering teams where structures are flat with large manager ratios 1:15 being considered normal, because companies want products developed rather than layers of management. If the IET don't understand this fact then I am reconsidering if the IET as a multi-disciplined engineering institution is appropriate for a software engineering CEng application.


It is after all Chartered Engineer, not Chartered People Manager, Chartered Accountant, or Chartered Chief Technology Officer.


Kind regards


Dan B
  • Chris,

    I mentioned in my earlier post, how UK-SPEC and its interpretation by the IET has evolved. So, your statement below, could be seen as a little “dated”?

    Therefore, even though these days the job I do brings with it significant authority, it has pretty much always been in the domain of solving problems using well-proven techniques rather than by developing new ones.

    There is now an increased emphasis on responsibility for complex technical issues with significant risk.

    We could create a long list of sectors where most Chartered Engineers have little if any opportunity to develop concepts from “first principles”, or by using much “theory”. I would even argue that outside R&D, most Chartered Engineers are only using “well-proven techniques” or “deploying existing technology” such as “standard products”.

    However, we should reasonably expect them to be able to research, understand and critically evaluate a range of options. To explain, to argue with other experts, to justify and to take personal responsibility for decisions, within a significant engineering context.  It isn’t a coincidence that these are similar to the types of attributes that might characterise a Masters graduate, which is the CEng “benchmark” qualification.

    Andy, touched on the difficulties of comparing more specialist expert engineers, with engineering managers.

    I’m glad that you have found IEng sufficient for your needs and I hope that it never becomes a disadvantage, which it only tends to be in certain situations, by comparison with CEng.    

    In the context of this discussion the extract below is from Engineering Council “Summary of key changes to UK-SPEC 4th Edition” on their website. IET has to interpret this.    

    Greater clarity between IEng and CEng. The requirements for IEng and CEng have been clarified, specifically:
    • Differentiation between IEng and CEng, principally at competences A and B. For example, A2 (CEng) emphasises technical complexity and level of risk.

    • Closer alignment between the requirements for competence C, recognising that the management/leadership requirements are more similar than they are different.

      

  • Roy Bowdler:
    ...It isn’t a coincidence that these are similar to the types of attributes that might characterise a Masters graduate, which is the CEng “benchmark” qualification...


    That's an interesting point, as I'm sufficiently old that my BEng meets the academic qualification requirements for CEng without the extra year and the dissertation, however prior to applying I had a research paper published which I also presented at an engineering conference.  I'd like to think that would have been a decent enough substitute for the extra study and the dissertation and therefore would have filled that "gap" but these are more observations than complaints and I've already stolen enough of this thread from the original poster!  If I ever find myself in a situation where "only" being IEng is holding me back then maybe I'll look again...


  • Hi Chris,

    Your posts have been really useful, you've highlighted some of the most common myths which not only hold back potential applicants, but even worse I regularly see applicants line managers etc giving misleading or downright incorrect advice of "you need to do xyz before CEng". So a really good hijack!

    The Roy's posts above cover most of the points extremely well (Roy P that is a superb post!!), just to add:
    1. Although my background is in innovation, I now work in safety assurance in the rail industry. You can't get much more tightly regulated and cautious than that. We regularly get our staff (and I sometimes help our clients' staff) through CEng, and indeed we have it as a requirement for senior roles to have CEng. As Roy B says, innovation is only one way to achieve CEng, significant technical responsibility for risk is another. The way I put it is that where we need CEngs is for signing off, i.e. taking responsibility for high risk projects - which may be innovative or may be technically complex. You'd expect the final signatory for the technical safety and reliability of a new power station to be CEng, they personally are unlikely to be carrying out innovation, but they do need to have a judgement that can be relied on.

    • Re your last post, just to emphasise again there are no (0, zero) educational qualification requirements for CEng. Theoretically your highest paper qualification could be a cycling proficiency test (is there still such a thing?). The words "or equivalent" are hugely important, most applicants we see have actually learned their "Masters level" approach to engineering through their work experience.


    Thanks,

    Andy
  • I'm completely with you Chris.  The same applies to me,  I work in rail and it is renowned for its resistance to innovation, new and novel solutions or anything else that takes you outside the box.  

    There are two ways that you may still have to demonstrate innovation, the first one being the use of an existing product in a new application,  the second being to challenge standards or approved products, presenting a well reasoned argument,  including risk assessment,  for why,  in a particular circumstance,  the non- approved solution would be better.  Sometimes,  just sometimes,  you succeed in obtaining a derogation. 

    But,  apart from that,  there is another,  (not always obvious in the current (3rd) edition of UK-SPEC, but it is in there all the same), get- out. This  is managing technically  complex issues with significant risk. The chances are that this will be the case for you as,  in my experience,  most highly regulated industries are so regulated because there is significant risk.   In interviewer (PRI) training this is particularly emphasised to us as an alternative way to satisfy the specification.

    In the forthcoming 4th edition this has been brought out more clearly.
  • Chris,  you're last post raises two more interesting points that lead to a (hopefully brief) history lesson.  The ability to satisfy the M.Eng or equivalent requirement with a research paper has long been available even before UK SPEC was introduced and the removal of specific educational requirements allowed.  

    I obtained my C.Eng before UK SPEC and I followed the mature candidate route which allowed the submission of a technical paper that demonstrated academic ability as an alternative to a degree (the degree that had to be matched was then a BSc as B.Eng and M. Eng hadn't been introduced).

    The big difference introduced by UK SPEC was the removal of the age qualifier to allow that approach plus widening it out to not even stipulate a technical paper,  but to state simply that, providing evidence of knowledge and understanding by any means at all is acceptable regardless of how that k&u was obtained. So it could be an accredited degree,  which is of course a simpler way to get there for anybody who holds one,  it could be by a technical paper or it could be a whole host of other possible ways to demonstrate k&u and it could be gained by a degree,  an apprenticeship or just on the job training, self study, lots of reading up or indeed any other method whatsoever (anybody ever tried learning under hypnosis, subliminal learning or psychic premonition ?!!) ;)