Participant leadership
Thoughts on engineering leadership in software delivery projects
Aug/Sep 2026
Thoughts on engineering leadership in software delivery projects
Aug/Sep 2026
Here, I'm gathering my thoughts and making the case for a form of project leadership that is common in modern tech companies, but not yet common in much of the wider industry, including consultancy, in 2026.
This is a more technical, hands-on kind of leadership, in which 'engineering' is not treated as being separate from 'delivery'.
A closeness to engineering doesn't need to replace aspects of conventional delivery management that we value, rather it can complement and enhance them. Since engineering is so tightly woven into the dynamics of modern delivery (not least through DevOps), uniting the leadership of the two can be a welcome simplification. I may be slightly biased, as this style works well for me, but I am not alone in seeing the logic and value in it.
Since the agile movement sought to overhaul the industry 25+ years ago, the direction of travel has been to move software project leadership closer to the front line of product design, engineering and delivery. This is where the complexity, the uncertainty and the risk is. It's also where the real value is created.
Prinicple 4: 'Business people and developers must work together daily throughout the project.'
Principle 9: 'Continuous attention to technical excellence and good design enhances agility.'
Principle 11: 'The best architectures, requirements, and designs emerge from self-organizing teams.'
'Agile' thinking led us to break up the simplistic command-and-control hierarchies, which didn't work well for software engineering. In the place of old-school, arms-length project managers, new patterns emerged that redistributed aspects of leadership and management into roles within unified teams: product owners, scrum masters, tech leads, delivery managers and more.
We tend to consider three broad (somewhat overlapping) areas requiring leadership and governance: 'product', 'engineering' and 'delivery'. On the 'product' front, the PO/PM concept has stayed quite stable, but the approaches to in-team engineering and delivery leadership were more diverse and have evolved further. Many organisations have had hands-on, technical leaders running their teams for some time, often called 'engineering managers', or sometimes 'technical delivery managers' or 'engineering delivery managers'.
The various roles, old and new, have more in common than what divides them - the key responsibilities of project leadership exist, whatever the title. One important difference is that an 'engineering manager' is still an engineer. They have strong technical awareness and are likely to be a hands-on contributor to some extent. The technical side of their work does not replace the other aspects of leadership and management, rather it complements and enhances them.
One of the compelling explanations for the technical leadership shift is DevOps, which emerged and evolved after the initial 'agile' revolution. DevOps practices raise the bar dramatically for delivery pace, efficiency and quality, and so raise our bar for 'success'.
However, that success is now intricately coupled with technical matters, more than in the past, because DevOps wove engineering deeper into the dynamics of delivery.
Testing, deploying, monitoring, patching and more - things that were once rather slow, risky and manual are now engineered into the software system itself, having enormous impacts on costs, risks, timescales and the quality of the core product. Those impacts can be very positive, but this is not a given.
Many little implementation details, like how we design pipelines or tests or telemetry, can have surprisingly large consequences, either to accelerate and de-risk delivery, or to delay and endanger it. If a leader lacks understanding and influence over things on which their delivery project's success depends, then success is at risk. They might be great at managing the project (and there's plenty of management to do when projects don't go well) but they might struggle to actively steer it towards success, or they might lean more on others to do that for them.
This is not to say that all non-coding managers are unable to understand and influence engineering - that would obviously be untrue and an oversimplification. I think it's more of a sliding scale of 'closeness to engineering', where being closer is generally helpful, but being further away is generally limiting.
When I first started in consultancy (BJSS), it certainly felt like our job was to follow closely behind the cutting-edge pioneers, bringing the competitive advantages of modern software industry practice to our clients in other less techy sectors. It's not just about keeping up with tooling and system design trends, but also the new ideas around the orchestration of our projects and teams: their composition, their culture and their leadership.
However, many consultancies now seem to be a little bit behind the curve on project leadership.
Apart from personal experience and anecdotal evidence, this can be inferred by looking at the roles that are commonly advertised. With some exceptions, most consultancies are advertising for delivery managers, without the expectation for them to have (or have had) a hand in the engineering itself. This is not in line with many modern software product companies.
It is understandable, to an extent. Consultancies work in a different context, one of clients, contracts and varying projects, so the job specs need to reflect that. However, I also think that being open to a more engineering-led option is very much in their interests, even if that means a gradual, cautious diversification. It doesn't need to be a rushed, risky restructuring; evolution, not revolution. The risk that we already face is that of standing still and believing that any current way of working is as good as it gets, against the evidence that the industry's short history provides. Leadership and management are particularly risky areas to neglect, because of their inherent potential for broad knock-on effects.
Maybe there is actually a good opportunity here. While the frontier tech companies race ahead, we know that the mainstream clients we work with are often still missing out on some of the substantial gains that modern practice (basically DevOps) made possible 10 years ago. Those gains are in delivery costs, run costs, time-to-market, reliability, resilience, scalability and so on. We know it's common to inherit projects that dabble in DevOps but are nowhere near achieving top DORA scores and we know there is tangible, long-term value in increasing those scores. We also know that AI makes it possible to catch up fast, if wielded wisely - lean teams can tackle big refactors, rewrites and remediations that were previously unfeasible.
If there is abundant, low-hanging fruit, why doesn't consultancy tap into it more? Probably because super-efficient DevOps is a pretty difficult engineering challenge, particularly when you're not starting with a clean slate. Even if consultancies have good DevOps intentions, the execution isn't straightforward. Just having powerful AI tools isn't enough - you need to use them well. Answers may lie in looking at what modern tech companies, as well as some pockets of consultancy, are doing differently. One of those answers, I think, is mixing more engineering into our delivery leadership, so that we're better-placed to sell and deliver these complex, valuable modernisations.
It's worth recognising that technically-involved management and leadership already happens, even in organisations that don't specifically ask for it and label it. In consultancy, we probably feel very familiar with the idea of engineers helping with aspects of leadership, even if we have fewer examples of delivery managers helping with aspects of engineering. Either way, if we look around and see it already working, then encouraging a bit more of it shouldn't be daunting.
At BJSS, I was at the far technical end of the 'delivery manager' spectrum. The title 'engineering manager' might be more descriptive, but perhaps neglects the client-facing delivery consultancy aspect. 'Engineering delivery manager' might be about right, but I rarely see this term used in the software world, for now. After the acquisition by CGI, most DMs were automatically retitled to 'project manager' (to their displeasure), but I took the 'development manager' option, which seemed a closer fit for me, although not perfect.
BJSS always used the term 'delivery manager', reflecting something different and better than an old-fashioned project manager. Very few official DMs were technical contributors on their projects - many had a technical background of sorts, some amount of technical literacy and a good tendency towards agility, but most were more managerial than hands-on. Some projects, typically the small, well-running ones, with particularly good team composition, simply didn't need that much 'management', so had no official DM. Instead they had a designated team lead to be a responsible representative alongside their main role, like a team captain on the pitch - this is how I began. (The fact that successful teams could exist in this form tells us something quite important, I think.)
My title was later switched so that I became a proper, official DM, which came with higher expectations, but it didn't forbid hands-on, technical contributions. I saw active involvement as a critical part of my approach to the role, and that the 'participant leader' approach worked best, at least for me, in most situations. By staying close to the design and engineering, I could understand the team's challenges deeply, lead by example and become trusted by teammates as well as clients. Plus, I enjoy the design and engineering, so it would feel very odd to distance myself when I could be helping out.
It didn't matter that other DMs were doing things differently. BJSS had the forward-thinking attitude that if you wanted to try something new, you generally could. If it went well, you could keep doing it. My role would be a bit different on each project, but being close to the engineering always felt beneficial to whatever we were achieving.
On a particularly good project, where I was heavily hands-on for three years, we were able to run a lean, affordable team for the client, while still being highly productive thanks to the efficiencies and positive team culture that we easily fostered as a small, close-knit group. It was demanding and each of us wore many hats, but that's no bad thing. It was good fun and we learned a lot in the process. Later, I found myself on a big, challenging, multi-supplier programme with less time for code and more of a need to initiate structural, procedural and cultural change, which I'm sure was helped by being in touch with the situation on the ground and by deeply understanding what 'good' looks like. Whether the initiatives involved high-level restructuring across the programme or fixing low-level engineering fundamentals (like using Git properly!), knowing exactly how the sausages are made was a shortcut to getting some impactful things done, probably more quickly and easily than my fellow DMs could, without leaning so hard on our already overwhelmed engineers. The other DMs involved brought other strengths to the table of course, which I greatly appreciated, and they too appreciated what I added. A mixture of leader types can work.
On both of the projects that I mention, both in the 2020s, we saw inherited problems as opportunities to improve quality and efficiency by catching up on modern practices that were lacking, including the classic DevOps practices like workflow automation, test automation, observability and usage of modern cloud capabilities. I found myself initiating and actively helping to execute the modernisations on both projects, selling the benefits to client stakeholders along the way. In neither case did our client POs know that these solutions were needed, but in both cases they were pleased by the outcomes and it benefitted our reputation, helping to reinforce or initiate long-lasting business relationships. This was good consultancy, which set us apart from the suppliers who preceded us.
Engineering greatly affects delivery.
As discussed in the section on DevOps, successful delivery by modern standards requires a great deal of engineering beyond the core product. The part of the product that customers see is only the tip of the iceberg. Underneath, we have deployment mechanisms, monitoring capabilities, automated tests, security checks, AI agents, cloud infra, source control, test environments, local dev environments and a whole host of developer tooling.
Orchestrating a well-oiled project machine is more of an engineering task than it was in the past, when more aspects of work were manual. If we accept that engineering and delivery are tightly intertwined, then merging the leadership of those areas becomes rational and a welcome simplification.
Team composition is easy to get wrong, without insights into the dynamics.
When there's a lot of work to do and a desire to do it faster, a classic management mistake is to allocate a lot of people to it. Unfortunately, that intuition just doesn't apply in software engineering, at least in the context of one team working on one indivisible product or service. The root causes of slow delivery are usually inefficiency and disruption, coming from things like tech debt, poor workflows and gaps in assurance, not insufficient people. Plus, there are many inefficiency factors that work against us as team size grows, such as the cost of meetings, queues for shared resources, queues for input from leading figures, coordination complexity between parallel work, feasibility of oversight, risk of bugs, etc, etc.
It's frustrating, but not uncommon, to hear stories of management figures trying to help a struggling project by giving it more hands, only to prolong its pain or even make it worse. An unfortunate consequence of an overloaded team is that the best few engineers on the team, most capable of doing high-value work quickly, stop being able to do that work because they spend so much time directing, coordinating and fire-fighting. The fix for a slow-running project is probably to strip it down to a few very strong engineers, allow them to fix the tech debt without distraction and put in place the DevOps enablers that will make the path to live much smoother, then carefully introduce a few more engineers (but not too many) to help rattle through the backlog unimpeded. Ideally, of course, a well-composed and well-led team would have avoided the problems in the first place.
We don't only need to consider team size, but also the abilities, attitudes and experience levels of prospective team members. It's tempting to take a unnuanced, tick-box approach, like searching for an engineer with x years of experience in the language of your core app, but that narrow focus risks creating inflexibity, or might simply screen out talented all-rounders. Will they be willing to dabble in the IaC, the tests, the pipeline and the database? What if we need to extend the stack or migrate it entirely? Do we really need a specialist, or do we need a versatile generalist? Do we just need a quick learner, and does a keen junior offer a good-value option? Or do we need some senior wisdom and soft skills to help in coaching our existing juniors? Or some gravitas in client meetings? Technical specialisms do have value, but the nuanced topics of ability and attitude often have even more value and are much more tricky to identify in the team-building process. As before, any insights into the engineering work and the team dynamics are likely to benefit our judgement.
Team frustrations can be avoided.
One key point is where the boundary lies between engineering and non-technical management*. It's better, I find, if that boundary is not within the team. This is partly emotional, in that engineers tend to appreciate a leader who is sympathetic and shares their experiences. It's also a somewhat practical consideration, in terms of the technical language barrier.
To be clear, I do see good, technically-minded delivery managers who avoid the problem I describe here and who are greatly appreciated by their teams, without being quite as hands-on as I might personally prefer to be. As mentioned, 'closeness to engineering' is a sliding scale, not binary.
If a team manager is too far removed from the technical work, it can be frustrating for engineers to be constantly translating into non-tech-speak for them, in every team meeting. They might be perceived as a 'boss', but unfortunately they might not feel like a real 'leader' to the team. The perception might be unfair, but they can seem like an administrative intermediary, passing messages and holding certain levers of power, while leaning hard on their engineering team members to provide or interpret those messages and to advise on the pulling of those levers. Some engineers won't like the feeling that they are picking up slack in someone else's job - a distraction from their own complex work. Some engineers, however, will happily step up to become an informed voice for stakeholders and a trusted advisor among teammates, which is fantastic, but it brings into question the need for a non-technical manager within the team at all. Some managers will feel this doesn't apply to their team, and some will be right - every team and manager is different - but the frustrations I describe are not uncommon.
*I'm not counting POs, designers, user researchers and other less technical specialists here. We love having them in the team. The point is just about the primary leader or manager of a team that is largely engineers.
Trust is easier to earn.
It's intuitive that engineering team members will build trust quickly with someone who understands their engineering work and actively helps in it (by empowering, not micro-managing, of course).
Managerial matters have value too, but they are often somewhat abstract and obscure to team members. You're really speaking their language when you raise a PR that makes their pipeline faster, or gives them a handy monitoring dashboard, or makes a flakey test more reliable. It doesn't really matter which area of engineering your contributions are in, but I choose these examples because they play to my existing strengths and they're little investments in delivery efficiency, which is bonus. In my experience, these DevOpsy areas are quite often where teams have gaps (whereas developers have usually got the core application covered). Also, these things would be quite quick and easy, detached from the critical delivery path, so it's a low price to pay in terms of my time. There's a risk of becoming distracted from higher-level duties, or making ourselves a delivery bottleneck, so there are some types of work we might avoid, like being the primary author of a major feature, for example. Every project will be different, however.
With stakeholders, who may be internal or client-side, technical or not, I still find that this is a route to trust. Firstly, the fact that you are actively helping to deliver a thing in which they have a stake can give a good impression and earn you a few brownie points early on. It could help to allay any scepticism by setting you apart from more passive managers they've met in the past. Secondly, being close to the detail helps you to report accurately and honestly, which people like. People can tell when a manager tries to explain something second hand, which they don't really understand - it sometimes emerges as an incoherent word salad. Sometimes, we need to bring another engineer to a stakeholder meeting to explain something better than we can, which is fine, but it's more impressive (and more efficient) when we don't need to.
That being said, we sometimes encounter clients and colleagues who are worried by unfamiliar ways of working, which is understandable. If they have preconceptions about what managers and engineers should be, they might see a hybrid role as all risk, rather than opportunity. Scepticism of change is just something we always need to work through, and not only on this topic. I've found that getting results usually wins people over, including on this topic.
Decisions can be better informed.
A team leader has to make judgement calls about when and whether to seek a collective team decision, whether to influence that collective decision, whether to leave a decision in a team member's hands or whether to make an executive decision themselves. The more context a leader has, including technical context (which I argue is highly important on a software project), the better that judgement can be made.
If a leader has limited context, then they have fewer good options. Making an executive decision without a solid basis of understanding could be risky. Collective decisions are very often a good thing, but the leader should still understand the consequences of the decision, so they can be accountable for it. Offloading too much decision making onto team members isn't always very fair on them, in fact it's something they may expect to be shielded from, to an appropriate extent. They might not be well-placed to make tricky, big-picture judgement calls that consider the long and short-term interests of the project, the team, the company, the client and the users. Sometimes, the big calls are exactly what an accountable team leader is for.
Some typical delivery management decisions might apply to team composition, recruitment, prioritisations, scope trade-offs, tech debt acceptance, etc. Yes, one can make these decisions without being highly technical and taking input from the team would be wise either way. I would suggest, however, that the leader's closeness to the engineering would be a strong benefit, both in being confident in the answer and in being able to explain it to any stakeholders.
Some decisions simply can't be made well, and confidently owned, without good technical insights. As mentioned, even little implementation details (e.g. in test design, pipeline design) can have big consequences for a team's efficiency and the quality of the end product. Obviously, bigger technical topics like system architecture are impactful too - head in the wrong direction and you set up problems for the project's future. To me, it seems reasonable to expect the delivery leader to hold accountability for things that determine the project's success, many of which are inherently technical.
Importantly, however, this is not a case for dictatorial leadership by an engineering mastermind, which would be absurd. A team's collective experience and knowledge will almost always exceed that of the team leader (by a long way), so we empower the team, leverage their expertise and share accountability where appropriate, as long as we don't offload it entirely. Anyone can make mistakes or have awareness gaps, so a leader needs to be able to spot that. It's good if the leader can at least follow the engineering decisions, consider the broad implications and know when to challenge, or seek a second opinion. It's a further benefit if they are close enough to be able to actively guide impactful decisions when needed.
Problems can be identified, raised and solved more easily. (Or avoided.)
Classic problems, like painful process, pipeline inefficiency or inadequate tooling shouldn't have to wait two weeks until a retro to be surfaced. If a leader is making hands-on contributions, they are more likely to experience the problems themself and intuitively see value in solving them, or avoid them in the first place. Even if another team member does raise the problem first, there's an efficiency and morale gain if the leader gets it straight away, rather than needing to be educated and persuaded. The less friction in the way of a solution, the better. Sometimes, however, the answer is 'yes I see that problem, but there's something more important to do first', which asks the team to trust that the leader is sympathetic and that their judgement is technically informed.
An example of engineering involvement avoiding management problems is in meeting schedules. Scheduling a meeting is an easy lever for a manager to pull, when they see risk or uncertainty and want to do something about it, but it can be costly and counter-productive. On quite a few teams that I've joined as a DM, an early efficiency fix has been to give engineers more unbroken focus time with some simple rearrangement and condensement of scheduled meetings. When you know the experience of engineering, you know that context-switching is a real productivity killer. You also get a feel for when risk and uncertainty need to be resolved by some hands-on work, not by a drawn-out discussion of assumptions and hypotheticals. You feel comfortable having ad hoc calls when actually needed, rather than trying to anticipate and schedule them.
Leading by example is easier than by diktat.
There are all sorts of behaviours and practices that team members might need some guidance on, particularly those less experienced. Any manager can set an example of how to participate in a meeting, how to talk to clients or how to present to a group. But what about the many steps involved in taking a code change from idea to production? Every project is different of course, but there are some common things that new engineers may need to learn to do in a professional context, such as:
Leave a concise but helpful audit trail (e.g. on a ticket), so that others can follow the work, pick it up in the event of your absence, or look back on it in future and find answers, not mysteries. The context may be helpful to your AI tools too.
Produce clear code that is easy for teammates to review and maintain in future, with comments around anything that isn't immediately intuitive.
When requesting a PR approval, anticipate scrutiny and save your teammates some effort. Point to the rationale behind the implementation, any test evidence and a working build, for example.
Leave a neat Git history with useful branch names, commit messages and PR titles and make sure they link back to your ticket. Avoid classic Git messes.
Even in the absence of formal TDD, think about testing upfront, if feasible, and write a few notes. The test thinking has to happen at some point anyway, but starting it early is more efficient than discovering problems later.
Write useful documentation, but only as much needed. Make it low-maintenance by linking to useful, dynamic sources of truth where possible (code, PRs, tickets) and try not to write things that will quickly become stale.
Keep teammates in the loop about your work in progress, anticipating coordination around parallel work or input from others.
Get in the habit of thinking about performance, security, testability, scalability, accessibility, maintainability, etc. Even tiny changes could have broader implications.
Things like these seem like a faff in the immediate term, but make our lives easier in the long run. Some people might not see the point in such things though, if they lack the big-picture view. Engineers appreciate agency and efficiency; they don't like taking orders before understanding the reasoning, myself included. However, if a hands-on leader can demonstrate a behaviour and allow its value to surface, teammates will gladly start to copy it, without feeling bossed about. Even if a team member does need an extra nudge, it's still better to show them that you're only asking them to do something you're prepared to do yourself, nothing more.
Efficient process needs to be flexible too - you don't want one-size-fits-all rules, but putting the nuance into writing is difficult, and is rarely read anyway. For example, the appropriate thoroughness of the audit trail or test evidence for a code change will depend on its risks and complexity. Again, if some team members aren't quite getting it right, it's easier to show than tell. The team leader might only have capacity to demonstrate the smaller pieces of work, not the big, complex ones, but a good solution there is to guide receptive senior engineers on the team to set good examples in those cases, and to help publicise them.
I would also note that when team members don't see value in adopting an idea, they might be right. The gentle, experimental approach makes it easy to back-track! Team members will surface their own ideas for process and practice improvement too, which might be even better. Show them that demonstration, rather than direction, is a good way to test and share their proposals. Show them you can be humble when your own ideas don't work out, so they too feel confident to contribute.
Advocacy on the team's behalf can be smoother.
Sometimes, the leader needs to raise something with stakeholders on the team's behalf: a concern, a suggestion, a request. These can tricky situations, like pushing back on questionable requirements or seeking to change processes that are outside the team's direct control. Even if the issue isn't technical on the surface, there are often technical delivery considerations or implications. This is delivery management bread and butter, but the hands-on leader might have the odds more in their favour, for reasons that include some of the points already made about about trust and judgement.
A deep understanding of the issue being raised may help the leader's argument to carry weight and to survive scrutiny, hopefully leading to a good outcome, efficiently. On the other hand, someone without such a deep understanding might be able to raise the initial point, but then get stuck on follow-up questions, either ending up with a bad outcome or needing more input from their team. This touches on the point about team frustrations.
We can retain and leverage talent and enthusiam.
The motivation to lead a project team can be driven by an enthusiam for the act of creating great software products, which is a very healthy direction to come from (as opposed to seeking leadership only for status, for example). However, if the options for career progression force people to choose between the either leadership or direct contribution, they'll probably feel frustrated and underutilised, or will simply move to a different company that values their full skillset. If, however, they can be retained, supported and well-utilised, then that's a great outcome for everyone. The very enthusiasm that drove them towards leadership is a valuable attribute in itself, which will be felt by the teams they work with.
There is often an important layer of management that facilitates business and commercial matters across multiple projects. Some would say it's 'above' projects and 'above' whoever leads a project, but I think there's a different way of looking it.
At BJSS, these people were often (but not always) called 'delivery leads', a title that I found misleading. Rather than leading the delivery of software, I'd say these people managed the business concerns that surround multiple projects, which is a critical function, but quite different. Different companies will have different terms, but I'll use 'portfolio manager' for simplicity.
In my view, they are a key contact at the centre of a web of multiple parallel projects, internal business functions (HR, finance, sales, senior leadership) and senior client contacts. When those parties need to interact, they can make it happen. Their place in the web makes them a logical overseer of client contracts and project finances. For the leader of a project team, the portfolio manager can be an empowering figure and their primary internal business stakeholder. They can be a source of advice, oversight, business context and practical support. In return, the project leader feeds them intel from the front line, sharing success stories and escalating problems that the project can't fix internally. These two big roles work together at an important interface in the business.
I saw this pattern work well, complimenting my approach to project leadership, but perhaps I was lucky, as the pattern wasn't universal.
We should bear in mind that an actively-involved leader on a delivery team has a lot on their plate, being responsible for the complex, client-facing software delivery work that actually brings in the money. And, as I have set out, having the capacity to stay close to that technical work is highly desirable. We don't want to overload this big role with unnecessary overhead. There are certain aspects of general commercial management that a 'portfolio manager', or similar, can easily facilitate or even take off their plate - this was my general experience at BJSS.
For example, the portfolio manager might lead on contract negotiations and determine project budgets, taking into account a big-picture business context. That doesn't mean the project leader (delivery manager) is uninvolved in commercial matters - they absolutely need to be involved - it just means these things are streamlined and derisked for them. As a project delivery manager, my input was certainly needed, being the expert in the realities on the ground, and I would ultimately need to know my contractual and budgetary constraints. However, the administration needn't take a lot of my time, which was demanded by the delivery project itself. The portfolio manager's oversight didn't prevent me acting with reasonable autonomy, rather it was a sensible guardrail.
On paper, however, the portfolio manager role ('delivery lead') was directly above the project leader role ('delivery manager') on the same career track, despite these roles being quite different when done well, in my view. There was more blurriness in the distinctions between the official role expectations than I think was optimal. There was quite a lot of variation in the strengths of DMs, the parts of the role they focused on and the amount of support they received from someone like a 'portfolio manager'. Anecdotally, there were occasional problems where a ball was dropped, like a team not being sufficiently productive, or a contract not being well-conceived, or a budget being exceeded. Perhaps a clearer separation of concerns, with the right people in the distinct roles that best suit them, would help to avoid such problems, as it appears to have done on my projects.
If a consultancy were to more formally merge engineering and delivery leadership of their projects, then existing delivery managers would have the chance to lean more towards their strengths. Perhaps those who see themselves as non-technical managers could thrive in the 'portfolio manager' role, while those with more of a technical background could be supported in rediscovering it, to the benefit of the projects they lead. (And they needn't be intimidated, as AI is a patient tutor that makes it easier to catch up and get involved.) We don't need to see one role as sitting above the other - they are different and both important.
A valid concern would be whether there is sufficient supply of people with the desire and aptitude to fill new 'engineering delivery management' roles. I think the people do exist, but are driven in different directions by the career tracks that are available. One direction they can go is to software product companies, where the 'engineering manager' track is waiting for them. I suspect the consultancies that don't offer a similar track are losing or suppressing talent that they could be leveraging.
Broadly speaking, in modern tech companies, there tend to be two major areas of career progression, one on the product management side (more business-focused) and one on the engineering side. On the engineering side, there are two tracks, one of which is a management track and includes 'engineering managers', who lead teams. The other is the 'individual contributor' track for engineering specialists who don't manage.
Consultancy can be similar, I think, but a few differences are to be expected. One is that our main family of non-technical roles is more about clients and contracts than users and products. It involves business development and other aspects of commercial leadership and management. We may well have product design and user research specialists, but clients usually lead their own product management in my experience. At BJSS, we also had technical tracks, one of which was essentially an 'individual contributor' track. The other was a 'capability lead' track, where capabilities included development, assurance, platform engineering, business analysis, data, etc. I think this concept was on the right lines, but was somewhat undermined and diluted by its separation from 'delivery' and by the arbitrary segregation of aspects of engineering that were increasingly overlapping over time. The influence of 'capability' structures was limited in the first place and seemed to wane. If we could reshape them now, perhaps broader categories would work better, like 'software engineering and delivery' and 'data engineering and AI', although again I'd be wary of arbitrary segration.
The question is where our project leaders fit in. At BJSS, delivery managers and delivery leads were influential, as the delivery projects are where the action is, but the roles felt more on the non-technical path. Technical ICs were valued, but weren't managers. Technical 'capability leads' had limited scope to really lead anything interesting, unfortunately. So, for those engineers looking to progress, there was tough choice between a path away from engineering, or a path away from substantial management and leadership (or a path out of the company). If we want to harness the benefits of engineering leadership in software consultancy, I think we might need to create some new options for progression.
My rough idea for consultancy is to adapt the 'engineering management' pattern of many software product companies, enhancing project leadership through a closeness to engineering, but also recognising the commercial nature of consultancy and carefully supporting and facilitating that side of the role in a consistent way.
On the business side: Our 'portfolio managers' (DLs at BJSS) could remain on the non-technical side, supporting multiple projects by managing the business concerns and high-level, long-term client relationships. There are already progression options here, handling bigger scopes, like bigger clients, whole offices, whole regions or whole internal business functions like finance, HR, sales, etc. The only difference is that we phase out the idea that an in-team project leader ('delivery manager') is strongly tied to this family of non-technical management roles.
On the engineering side: Delivery projects would be led by 'engineering delivery managers', similar to how modern tech companies lead teams, but still with the consultancy skills and commercial awareness. As discussed, a closeness to engineering doesn't need to replace existing aspects of delivery management that we value, rather it complements them. As EDMs grow in seniority, they would be hiring and coaching other EDMs and managing senior ICs. Along with ICs, they would be technical advisors to less-technical parts of the business. They would also be advisors to projects with complex, practical delivery challenges (hopefully avoiding the problem of senior, non-technical managers making bad calls when projects get difficult - see the section on team composition, for example). Their scope would grow: they would be setting organisational standards and strategies related to both the mechanics of software delivery and the fostering of the engineering community that executes it. The latter is something that BJSS 'capability leads' once did, but now it could be done with more influence and more of a connection to the actual delivery work that occupies most of their engineers' time. They could still keep a hand in the engineering, as they manage and potentially even contribute to whatever their senior ICs are delivering: accelerators, prototypes, discoveries, custom tooling, frameworks, AI orchestrations, white papers.
With that, people have a nice set of options for progression: business and commercial management, engineering and delivery management, or the non-managerial engineering IC track.
A key risk we would hopefully mitigate, by bringing engineering and delivery management together, is that engineering greatly affects the success of delivery, as discussed. Past separation of those overlapping concerns seems to be a common root of delivery problems, in my view.
Although the idea is intended to remove a problematic boundary, there might be a perception that another more distinct boundary has been created between the commercial and the technical, which is something we might worry about. I wouldn't quite see it that way, because I think the boundary always existed somewhere anyway and it can be seen as a valid interface between complementary functions - it's not necessarily an obstructive barrier. Optimising an existing interface doesn't sound so bad.
Leading figures on delivery projects always interface with other business functions that exist to facilitate projects' needs. One obvious example is the recruitment department, who provide a critical service. An senior engineer is still very much doing the recruitment of other engineers, but is guided through the parts of the process that strictly require their input, while much of the administrative overhead is streamlined for them. There's no obstructive barrier there, just efficient collaboration.
The same can apply to project leaders in their handling of commercial concerns, like contracts and budgets, in that they are very much involved, but with the guidance and facilitation of a business management function that is optimised for it. Anecdotally, even non-technical, managerial DMs make mistakes in these areas, so risk mitigations are sensible anyway. The main argument, in my view, is that the streamlining and derisking opens up cognitive capacity for the project leader to stay closer to the front-line delivery work, increasing their chances of leading it to success. As mentioned, my experience was always that I had exactly this support and it worked well, but I know that some delivery managers took more of the weight on their own shoulders, which I don't think was always optimal.
I'll be cautious about making assertions on this topic, as they often age quickly and badly.
Somewhat a draft, to be iterated:
In 2026, some competing arguments are not yet resolved.
On the one hand, the need to know a programming language in great depth has been decreasing over time for many years, as clever IDE features have increasingly helped us with syntax, accelerators and examples have become ever easier to find and cloud platforms have provided more managed building blocks so there's less to write from scratch. Now that LLMs are highly competent at writing code, it's fair to say that it's extremely easy to produce standard, familiar software without being much of a coder (putting aside, for now, the question of whether that software is any good). That might lead us to conclude that the technical, hands-on manager has less value.
Maybe we can imagine a situation, pretty soon, where most non-techy organisations have very little need for 'engineering' at all, because the LLMs and cloud providers can provide a suitable full-stack implementation for any software product other than the extremely innovative and cutting-edge. Realistically, most organisations don't work at the cutting edge. They need CRUD back-ends and UI apps with familiar features, sprinkling in some custom domain logic and a branded design. Maybe we need to focus on managing our clients and their requirements, while AI manages the engineering for us.
There are some counter-arguments, however.
Many people are worrying about what happens if we lose understanding of the code we produce, and therefore lose control and accountability. There is a risk of producing sub-optimal software that we then don't know how to fix. In safety-critical systems (like air traffic control) this could be a disaster. The rise in product quality issues experienced by big-tech AI adopters serves as a warning, and we don't know whether such problems are a temporary deficiency in LLM coding or a long-term risk, inherent to the technology. newsletter.pragmaticengineer.com/p/are-ai-agents-actually-slowing-us
There are also concerns about rising AI costs and even about access to AI, which could theoretically be withdrawn by companies or governments who control it. How much we mitigate against those risks probably depends on the context of the software project. In consultancy, we often work with government and major enterprises, who are likely to be risk-averse and may therefore wish to retain a certain amount of human engineering involvement and expertise, to rule out worst-case scenarios.
Not all of the projects we take on in consultancy are suitable for generic, boilerplate solutions, of the kind we might be more likely to trust AI with. Sometimes they are quite specialist or innovative - some examples that spring to mind involved air traffic control and space weather forecasting. I feel like significant human guidance and understanding of the engineering solutions would be desirable and probably necessary, even if AI would be very helpful along the way.
It's also a fact that in software engineering there are many ways of achieving roughly the same thing - different system design patters and tooling choices that offer different pros and cons, like cost, scalability, performance, maintainability, etc. Even if we use AI to help us make those decisions, I think there will continue to be cases where we greatly appreciate an accountable human doing the steering and evaluating the outcomes. Although things may change, the situation in 2026 is that AI can confidently lead you in the wrong direction, because of something you did or did not include in its prompts or context. Spotting its mistakes can be hard, amongst a convincing commentary. Weilding AI tools well, in the context of software engineering, remains quite an engineering task and may continue as such for some time - we'll see.
A point that feels important to me is that orchestrating a software project is really an engineering task in itself. We have a lot of moving parts: team, product, users, clients, tools, processes. These things form a complex system that we try to optimise for efficiency, reliability, sustainability and output quality. As described, I think a good understanding of the technical matters in that machine is important and I'm not sure that adding AI agents to the mix will completely remove that consideration. If anything, it probably challenges us to think more imaginatively and creatively about efficient process and quality controls, as existing ways of working will cease to apply. Designing agent orchestrations is a big topic in 2026 and there are various ideas emerging, some which look familiar, like teams of agents replicating human roles, and some more novel, like parallel developer agents using different models to produce competing implementations of the same feature, with additional agents then assessing which solution to keep. Yes, broadly-applicable orchestration patterns will probably emerge for followers to adopt, as they did from the agile and DevOps movements, but in those examples the implementation and optimisation is still a tricky job for project leaders, so perhaps a similar skillset is needed for the agentic age. This feels like a significant new chapter in the engineering of our development processes, rather than its end, at least for now.